Add hypertext tile modifier(again)

[jingkaimori]

Add compact, short information about your PR for easier understanding:
Add text modifier for texture file. This pr replaces #12084 and could be squashed.

• Goal of the PR
  render a row of text on texture of object. The behavior of this api is the same as text displayed on formspec. Texture modifier is as similar as [fill modifier.

• How does the PR work?
  This pr render string with RTT (Render To Texture) strategy.
  Modifier schema can be one of following:

  • [text:hypertext encoded with base64
  • [text:hypertext encoded with base64:WxH
  • [text:hypertext encoded with base64:WxH:X,Y

  Hypertext here must be convert to base64 encoding. WxH and X,Y can be integer pairs, e.g. 100x50 and 60,0 respectively. <global> tag in hypertext can control alignment of text.

• Does it resolve any reported issue?

  • Text-rendering texture modifier #9946
  • Proper display of text on the surface of a node(box) #1367 partially

• Does this relate to a goal in the roadmap?
  not yet

• If not a bug fix, why is this PR needed? What using cases does it solve?
  Improve fps and reduce network traffic by render text directly at client instead of generate texture from "bitmap font" dynamically

• Why use base64 to encode Hypertext?
  Because some special characters([:^,) cannot appears as regular field value in texture spec, described in Some special char cannot be used in filename of texture #15185.

To do

This pr is ready for review.

• How to customlize font family of text? Default font is used currently, which may vary among clients. Waiting for Font media files #10416 solved
• What should happen if driver cannot render to target?

How to test

See games/devtest/mods/testnodes/textures.lua. This pr must be test locally, because integration test on ci does not have irrlicht driver that can render to texture.

[appgurueu]

I'm not sure how modders would use this feature in a reliable way when they don't know font dimensions, especially width. I think this needs an API which is reasonably "hard pixel"-independent. To use this properly, modders would also need [combine texture modifiers with some "layouting" capabilities beyond hard pixel coordinates.

[cx384]

Fonts are client side, the server doesn't know the actual size, so as appgurueu wrote you definitely need some kind of font size independent text size API.

I would prefer the texture modifier to use text escape sequences, to be consistent with other texts, but I'm not sure if they are compatible with the current texture modifier parsing.
(For fonts it could reuse the font escape sequence I introduced in #14968.)

[jingkaimori]

I think this needs an API which is reasonably "hard pixel"-independent. To use this properly, modders would also need [combine texture modifiers with some "layouting" capabilities beyond hard pixel coordinates.

Facilities for hypertext is extracted and used here.

[jingkaimori]

I would prefer the texture modifier to use text escape sequences, to be consistent with other texts, but I'm not sure if they are compatible with the current texture modifier parsing.

There are no "texts" in texture modifiers, only filenames, size specifications and several enumerated options. All of those is restricted to small set of character, thus the consistency requirements of texture modifier is more strict than formspec, name tags, etc.

(For fonts it could reuse the font escape sequence I introduced in #14968.)

This pr only provides font style selecter, no spec for font size and global alignment is provided, which is necessary for mods in display modpack.

[cx384]

Ok, I guess hypertext can be used here, and encoding it as a number solves all parsing problems.

If I'm not wrong, the main use case for this feature is to display text on signs and similar, but with the current solution you can't dynamically specify the texture of a node.
Maybe it would make more sense to introduce reference based texture modifier for proper RTT things. E.g. #9999
and not just static textures with text.
Having static textures with text may still be a useful feature, but this PR does not solve the issue.

[jingkaimori]

Text can also be rendered on entity, and texture of entity can be changed dynamically, thus signs can create an entity to carry texture, like display_modpack. If it is indeed necessary to dynamically render texture directly on node itself, #3528 should be finished, rather than a pass-by implement like #9999

[cx384]

Isn't the whole purpose of this that you don't have to use an entity anymore?
I mean with the current API you can already draw static text to a texture if you have a font as pngs and use the overlay texture modifier to assemble the texture yourself.

[jingkaimori]

Isn't the whole purpose of this that you don't have to use an entity anymore?

No, the purpose of this api is introduce text rendering in texture generation as modifier. Getting rid of entity is not the purpose of this pr.

I mean with the current API you can already draw static text to a texture if you have a font as pngs and use the overlay texture modifier to assemble the texture yourself.

That means font must be extract to bitmap first, and mod is responsible to typeset (assemble glyph). The pr can typeset text with mechanism from irrlicht, so typesetter is no longer need to be implemented by mod.

[jingkaimori]

Bump. @appgurueu @cx384 Are you interested in reviewing this PR?