[Feature request] drawTextRun method

[X-Ryl669]

Currently, FastUIDraw is very low level concerning text rendering (which is a major requirement for a Canvas like API). It's storing a cache of Freetype's generated glyphs, and if I understand correctly, expect the user to provide the sequence of glyphs to render.

As a potential user of the library, the amount of work from "text" to glyph is a real nightmare to make right. One should take into account the language the text is in, the font's script to run to figure out which glyph to display at what position, and the glyph transformations. I'm not even speaking of font fallback when a glyph is missing in a font or a language.

The current best open source lifesaver is Harfbuzz that does the mapping from text run to glyphs run. However, having a working code with Harfbuzz is tricky, and I think it would be better if, instead of having all users implement their "something that work with harfbuzz but full of bug", the fastuidraw code implemented a working harfbuzz wrapper, so we could call rectangle Painter::draw_textRun(string, style, justification, double fontSize, rectangle src_rect) and also have a rectangle Painter::get_glyph_pos(string, style, justfication, double fontSize, size_t characterIndexInString) would be a real lifesaver and improve usability a lot.

[krogueintel]

Hi,

I am quite hesitant to make Harfbuzz a requirement to build the library; Perhaps I make (another) separate library, libFastUIDraw-Harfbuzz that has a class (or function) that has what you are looking for:

• Creates a PainterAttributeData from the arguments of a drawTextRun()
• provides the getGlyphPosition() above
• provide an interface to get a sequence of glyphs and positions from a drawTextRun() argument set
• and whatever else.

Note that Painter would NOT have a drawTextRun() routines; this is because if it did, every time it would be called would require glyph selection and layout which can be quite CPU intensive. Instead by having the PainterAttributeData object available, the layout and glyph selection computation would not need to be redone.

This is quite a bit of work, so it will take quite a bit of time to implement. I also need to work on rendering glyphs as well as the curve_pair renderer is not 100% robust.

[X-Ryl669]

Make sense. Thanks.

[krogueintel]

There is a very basic text layout thingy in demos:

https://github.com/01org/fastuidraw/blob/master/demos/common/text_helper.hpp

which one can copy into one's project and use; it is a very -basic- layout gizmo: it does not even do kerning(!)

[capr]

Text shaping is hard, but it's basically a solved problem if you put together harfbuzz, fribidi and libunibreak. OTOH what Kevin does is even harder, so I'm glad that his focus isn't wasted on that particular rabit hole.

Great to see the 1.0 release!