Font escape sequence for nametags

[cx384]

Goal of the PR

• This is a probably better solution than Allow nametags to support formatted text #14866
• It resolves Allow nametags to support formatted text #13673, and paves the way for Add minetest.{bold|italic}(text:string):strrng like minetest.colorize() for tooltips via node.description #14913 and similar.

How does the PR work?

• It adds font escape sequences, which for now can only be used for nametags. (Future PRs could use them for the chat, hud, tooltips, ...)
• Nametags now also support color escape sequences, because of the use of enriched strings. The nametag_color basically acts like as a prefixed color escape sequence.
• The font escape sequences act like the color escape sequences, meaning that everything after them is drawn differently. (mods could always introduce their own system on top)
• Some design decisions:
  • A font escape sequence only changes one aspect at once. This should be the most convenient.
  • The font specs did not become a part of the EnrichedString like the colors, because internally the way how text is drawn is coupled very closely together with the used font (see GUITTFont or CGUITTFont), so it makes no sense to draw it as a single string without completely changing what a GUITTFont is and drawing it separately shouldn't make a big difference.
  • StaticText can't be reused for this feature, because it works with only one BrokenText per line.
  • I know the enriched string situation is not optimal, but formspec texts and nametag/chat texts are used very different anyway. It could be improved by refactorung large parts of the irrlicht and formspec code, but I think it should also be fine this way, at least for now.

To do

This PR is Ready for Review.

How to test

• Start devtest and spawn some testentities:nametag, testentities:nametag_enriched_text, and testentities:nametag_ascii_art.
• See that normal nametags still look the same, the enriched text looks fine, and that mono text is useful.

[Zughy]

@cx384 rebase needed

[jingkaimori]

Why creating another DSL? Could we use hypertext directly here?

[cx384]

rebased

Hm, I haven't really considered it, since hypertext is currently only applicable for formspecs and the API still says that The markup language is currently unstable and subject to change. Use with caution.
I'm not sure what kind of features people need for nametags, usually it is only one small line of text, but it may even make sense to use entire formspecs as a nametag. Maybe this PR should wait for #14263.
However, font escape sequences may still be needed for item descriptions, chat massages and such. #14913
Or could those all be converted to hypertext?
I mainly introduced those font escape sequences, because appgurueu and Zughy requested them in the previous PR.

[wsor4035]

Why creating another DSL? Could we use hypertext directly here?

i concur that this should use hypertext

[appgurueu]

I'm afraid I disagree, or at the very least I don't see strong reasons to use hypertext here. About the only "pro" is that we get to "reuse" a (somewhat intuitive) DSL. There are multiple "cons" however (I vaguely remember stating (some of?) these already somewhere, in that case let me reiterate):

• This would imply a "stronger" breakage of backwards compatibility. Suddenly plain text (!) is rendered differently and needs to be escaped. You need to escape at least < somehow. Players may abuse this to get formatted text where there shouldn't be formatted text. In contrast, extending \27 escape sequences is quite natural - we already use them for colors and translations, both "rich text" features which are supposed to be pretty universal, and much less likely to break any current usage, especially as the behavior for plain text (printable ASCII) is fully preserved.
• You don't get full consistency with hypertext either: This would have to be a small subset of hypertext. In particular layouting, font size, images etc. can not and should not be supported here.
• You don't get full consistency with existing \27 escape sequences for colors; translations also use them. You'd additionally get redundancy if you introduce hypertext style colors.

What we want here is something that applies (or should eventually apply) to text rendering as universally as possible, as is the case for translations. I see little reason for this to be hypertext; in fact the \27 escape sequences were there before and it might have been a design mistake to add redundant features in hypertext, at a higher level, rather than first fleshing out lower level rich text.

Either way I think modders can definitely live with such font escape sequences. If you're not happy with it, it's easy to turn it into a DSL yourself, both via parsing and by just using Lua tables and syntactic sugar.

Arguably, if this is to be about nametags specifically, it could be considered to use hypertext, including the layouting features and all other bells and whistles, making it more powerful for nametags specifically (e.g. allowing alignment of text) but less powerful in general since we can't just put hypertext rendering in everywhere we render text (or can we?). I have not yet looked into how feasible that is from a development standpoint.

[Zughy]

@cx384 rebase needed