How should I do text layout with allsorts?

[LoganDark]

The text shaper (allsorts) is an integral part of text rendering, but it's only one part. There are other elements needed for a robust, complete system:

• Composing runs of text containing multiple font weights, i.e. bold and non-bold, with proper kerning
• Bidirectionality
• Vertical scripts mixed with horizontal ones (bi-orientation?)
• Text wrapping (even in the face of multiple font weights, bidirectionality, or both)
• Caret positioning for text fields, selections, background colors, and so on (Tracking the correspondence between input text and output glyphs #31)

It's hard to find documentation on next steps online. There's Fonts and Layout for Global Scripts, Text Hates You, Text layout is a loose hierarchy of segmentation, and so on, but I can't clearly see where I should go next after I can render single calls to Font::shape onto the screen.

For example:

• How do I concatenate multiple calls to Font::shape? Should I concatenate the Vec<Info>s? What's the best way to do that? Should I kern between them, and if so, how?

• How should I mix multiple text directions?

  

  (That example is extremely contrived, but still - I want to know!)

• Is horizontal text always 1em tall and vertical text always 1em wide?

• How do I parse an input string for scripts / directions? There's some crate for this, right? Does allsorts include any algorithm for it?

• How should I wrap text without Tracking the correspondence between input text and output glyphs #31? How do I handle ligatures when wrapping? Split them up, treat them as single units, ..?

Text layout is out of scope for allsorts specifically, but I feel like this is still a good place to ask a question like this. Please let me know if there's somewhere else I should go instead!

[wezm]

There's a lot to unpack here but they are reasonable queries. The short answer is that I don't believe we have a great solution to this in the Rust ecosystem yet, you kind of have to do it yourself. For Prince these tasks are are all handled through the Mercury codebase, in which the bulk of Prince is implemented.

As general guidance, Unicode is involved in much of this. Understanding character properties and reading some of the annexes is probably useful. Also the r21a apps can be good for exploring Unicode properties and text https://r12a.github.io/applist

• How do I concatenate multiple calls to Font::shape? Should I concatenate the Vec<Info>s? What's the best way to do that? Should I kern between them, and if so, how?

I'll answer slightly out of order. Generally there shouldn't be a need to kern across groups of Info (and this isn't possible as far as the Allosorts API goes). The input text should be segmented by unicode script (see below) and each segment shaped alone. This will typically result in the code points being grouped by word (for languages like English) or line for CJK because white space belongs to a different script to other code points.

For each group of Info you can then obtain their positions with GlyphLayout. Then you can lay out the glyphs. This is a bit of science in itself as it's a packing problem: you presumably have a width constraint (for horizontal text) so you'll start laying out the glyphs and then have to decide how to handle that constraint. You might choose to move an entire chunk of infos to the next line but if it's wider than a line then you need to choose a break point. If you get really fancy you might use some hyphenation data to choose optimal break points to hyphenate.

All that is to say line packing is a complex problem in its own right. The Unicode Line Breaking Algorithm is probably a good place to start https://www.unicode.org/reports/tr14/

• How should I mix multiple text directions?

You probably want to read up on the Unicode bidirectional algorithm: https://www.unicode.org/reports/tr9/ There is a crate implementing this: https://crates.io/crates/unicode-bidi

• Is horizontal text always 1em tall and vertical text always 1em wide?

For a particular font there with be a nominal separation between lines described by hhea, vhea, and maybe OS/2, which isn't necessarily 1em. The glyphs themselves can be as big and positioned however they want relative to that baseline though. For a given font in a size, and style calculating the font metrics E.g. the bounding box that will actually encompass all that text typically requires actually laying it out.

• How do I parse an input string for scripts / directions? There's some crate for this, right? Does allsorts include any algorithm for it?

Allsorts does not include this. You need to lookup the Unicode script property of each input code point. unicode-script or another similar crate can help here. I'm sorry I'm not sure whether direction is handled before or after this.

• How should I wrap text without Tracking the correspondence between input text and output glyphs #31? How do I handle ligatures when wrapping? Split them up, treat them as single units, ..?

Not 100% sure about this, although I did cover a bit of it in the first part about line packing. Maybe @mikeday has some thoughts.

[LoganDark]

Generally there shouldn't be a need to kern across groups of Info (and this isn't possible as far as the Allosorts API goes). The input text should be segmented by unicode script (see below) and each segment shaped alone.

It'll also have to be segmented by things like font weight, and let's say there's a word where only one letter or half of it is bold/italic. How should I lay those out within a word? Just keep the caret position between them, no kerning required? (After all, the last position does happen to have a hori_advance...)

For a particular font there with be a nominal separation between lines described by hhea, vhea, and maybe OS/2, which isn't necessarily 1em. The glyphs themselves can be as big and positioned however they want relative to that baseline though. For a given font in a size, and style calculating the font metrics E.g. the bounding box that will actually encompass all that text typically requires actually laying it out.

I think it's important to clarify here that each glyph does have its own sort of "bounding box", at least for the purposes of layout. The actual outlines can poke outside of the box, or be wildly off in the distance, but in terms of text layout (like caret positioning), there is a box. You can get the width of the box from hori_advance, but since vert_advance is usually 0 for horizontal scripts, I have to assume that each box extends 1em upwards. For things like button padding I use cap-height (which works extremely well), but since I use pixels-per-em for font scaling, it makes sense for the boxes to be that many pixels tall.

Is that asssumption correct? I have an actual bounding box function that calls OutlineBuilder::visit to get the bounding box of the outlines (needed for rasterization), so I'm not concerned about that because it's a solved problem. Just concerned about layout (the topic of this discussion).

[wezm]

How should I lay those out within a word? Just keep the caret position between them, no kerning required?

This would be my guess. However, it should be noted that you're now working in a space that none of us have much experience with: for our needs it's a one way process with no editing so we've never had to dig into things like cursors much.

There is some caret related stuff in the GDEF table for handling ligatures too.

Is that asssumption correct?

Sorry I'm not following here. Are you asking if the "I have to assume that each box extends 1em upwards." assumption is correct? How would you make use of this glyph height?

[LoganDark]

for our needs it's a one way process with no editing so we've never had to dig into things like cursors much.

The caret is the name for what you update with hori_advance / vert_advance. Not a GUI caret.

Sorry I'm not following here. Are you asking if the "I have to assume that each box extends 1em upwards." assumption is correct? How would you make use of this glyph height?

Yes, that's what I'm asking. I'd use it for anything that needs the box, i.e. reverse-video text.

[wezm]

The caret is the name for what you update with hori_advance / vert_advance. Not a GUI caret.

OH! Well that explains a lot. I thought you were talking about a GUI caret, where did you see that position referred to as a caret? I've not come across that in my travels.

Anyway in the face of different collections of Infos I imagine you'd keep the caret between each collection but I'm not an expert on that matter.

Yes, that's what I'm asking. I'd use it for anything that needs the box, i.e. reverse-video text.

Hmm I suppose this would also be needed for drawing text selections. I would have thought this would be ascender - descender?

[LoganDark]

I would have thought this would be ascender - descender?

It appears browsers use line-height, which is usually based on the font's pixels-per-em. For example on the web with a line-height of 1.5, there's an extra 0.25em of space above and below the font and the selection reflects that... but there's actually a little more. I can't actually tell what metrics they use because even with a line-height of one, the selection still goes a bit outside the ascender/descender! But what I can tell is that the text stacking perfectly reflects whatever they are using:

so exactly what I use for the selection (or perhaps reverse video?) should probably also be linked to line gap / line height.

I find that browsers are a good reference when it comes to typography & font rendering (word processors too), as they tend to have the most advanced and accurate layout engines.

[mikeday]

Wrapping usually requires reshaping, for example if you were to hyphenate "difficult" as "dif-ficult" then you would shape it twice and get different results each time, the first might include an "ffi" ligature while the second would be shaping "dif-" and "ficult" as completely separate chunks as they appear on separate lines.

[LoganDark]

Ah yes, heard of this one: https://bugzilla.mozilla.org/show_bug.cgi?id=479829

Luckily, allsorts doesn't yet give you enough information to make a mistake like this. (#31)

Therefore, there's no way I could make this error. :)

[brendanzab]

The CSS writing modes spec might be useful to look at. While the implementation is left up to you, it might be helpful for framing your thoughts about this kind of thing. For example things can get a bit more complicated as you no longer talk about X and Y, width and height etc. and instead you need to think in terms of the inline axis and block axis, etc.