This is related to #224, #18656, and #35897, but for a specific purpose. It is also a followup from this medium post.

Need

To be able to perform custom text layout beyond the currently supported ltr and rtl multiline paragraph layout.

Example use cases

• Vertical layouts like Mongolian and vertical CJK
• Writing text on non-linear paths (see also Support drawing text along a curved path and on a mesh #16477)
• Filling a non-rectangular shape with text (examples here and here)
• Doing custom text flow around objects (see Specifying Exclusion Paths here)

Current problem

The ui.Paragraph class is about all we have to work with. This class assumes you are doing multi-line, linear, horizontal layout within a rectangular shape. It seems probable that using a ui.ParagraphBuilder to measure every single glyph in a long string would be slow (but I haven't tested that yet). Many of the metrics related to the paragraph (like line heights and text) are not provided. As far as I know, there is no access to tools like the Minikin LineBreaker.

Feature request

Expose just enough of the low level LibTxt API to make custom layout possible and practical. Based on my experience with custom text layout in Android, these are the features I think would be necessary to do custom text layout:

• Get font metrics: ascent, descent, baseline, leading, line height
• Have access to a line/word breaker
• Be able to measure text runs (including single characters/glyphs) efficiently
• Be able to measure substrings, similar to Android's Paint.breakText (see example). This is helpful for breaking a word that is longer than the max allowed length for the line. A character measured in the context of a word may have a different size than when it is measured individually. This is true for Mongolian, which like Arabic, has initial, medial, and final forms. Thus, when soft breaking a long word unnaturally across lines, it should render (and measure) the medial form at both sides of the break. Having something like Android's Paint.breakText helps with that. This one may be optional, though. I'd like to know if there is a better way to do it.
• Be able to paint short text runs efficiently

Note that this is not a feature request of any of the specific example use case I listed in the section above.