[css-fonts-5] advance-override details

[fantasai]

We resolved to add an advance-override descriptor in #5533 but didn't define quite what it means. Here are some fun questions:

• How are we increasing/decreasing the advance width? Are we increasing the font size? Stretching in the X axis? Adding space around each glyph? Something else?
• If you're adding space around glyphs, is it applied at the start/end of the line also? On Arabic and Mongolian as well? etc.

[xiaochengh]

• How are we increasing/decreasing the advance width? Are we increasing the font size? Stretching in the X axis? Adding space around each glyph? Something else?

In Chrome's implementation, there's no font size changes or stretches. It shares quite a lot of code with letter-spacing, so it ends up adding space after each glyph.

IMO this seems better than adding spacing around each glyph. Otherwise, the first character may look misaligned with the start of the line.

Anyway, all these choices have no difference for the purpose of reducing layout shift...

• If you're adding space around glyphs, is it applied at the start/end of the line also?

This is one of the topics that apply to letter-spacing but not to advance-override, since we are modifying the advances of the glyphs instead of adding spacing in between. I don't see a reason why we should leave the start/end of line unmodified.

• On Arabic and Mongolian as well? etc.

Maybe we should recommend NO for complex scripts and fonts. Reasons:

• The legibility really depends on whether the text shaper supports changing glyph widths, which is case by case different.
• In some cases, different fonts can shape the same text with different numbers of glyphs. Then advance-override won't work as good as, e.g., Latin.
  • Note: I can't read these languages, so I don't know if this is a common case, or due to the generated gibberish text

[chrishtr]

+1 to skipping scripts with cursive representations. I think this is in accord with the F2F discussion also, and is what letter-spacing does (*)

(*) Spec text: "if the UA cannot expand text from a cursive script without breaking its cursive connections, it must not apply spacing between any pair of that script’s typographic letter units at all" https://drafts.csswg.org/css-text-3/#cursive-tracking

[r12a]

Note: I can't read these languages, so I don't know if this is a common case, or due to the generated gibberish text

It is indeed a common case for complex scripts to use different letter shapes, font styles, and ligating or conjoining approaches from font to font. It is also common that the text is formed from clusters of glyphs, with complex relative offsets and rule-base variants, rather than a simple succession of isolated letter glyphs. These things are so common, in fact, that they are what lead to them being called 'complex scripts'.

But even where there is little to no interaction between glyphs, other than placement of diacritics, such as for Thai, differences between individual letter shapes can vary. Going from one font to another, some letters are thinner, others wider.

Actually i'd have thought that would also be problematic for Latin text unless you choose quite similar fonts. Would it be fair to say that advance-override is really most suitable for monospaced, non-complex fonts such as CJK?

[xiaochengh]

But even where there is little to no interaction between glyphs, other than placement of diacritics, such as for Thai, differences between individual letter shapes can vary. Going from one font to another, some letters are thinner, others wider.

Yeah, for this reason advance-override cannot accurate match the text width between fonts.

We never intend to do that accurately, though. Our goal is just to reduce layout shift. Given that web developers are already using letter-spacing to reduce layout shift, and our proposed version works better for the same purpose, I think it should be good enough.

[svgeesus]

It sounds like the description for this should point out the limitations, and thus avoid over-promising

[xiaochengh]

Here are some topics and my proposals for the next meeting. Please add more if needed.

1. Are characters stretched/resized/etc when advance-override is applied?

Proposal: no. It has no effect for the purpose of reducing layout shift, but adds a lot of complexity to spec and implementation. If using advance-override severely affects legibility, then it's better to just use a more similar fallback font.

2. How is spacing added to each character?

Proposal: spacing is added after each character, for the reasons I gave in #5983 (comment) for reasons.

3. What's the default value of the second parameter, and what's the exact syntax?

Proposal: Use two descriptors advance-width-override and advance-height-override separately. This seems the cleanest among all the ideas I came up with.

Other ideas:

• normal | [ <percentage> <percentage> ] as currently specified. In other words, second parameter is the same as the first if unspecified.
• [normal | <percentage>] [normal | percentage]?. In other words, it has no override to upright vertical text if the second parameter is not explicitly given.

4. Add spec text to avoid over-promising. This includes:
   • It can't fully eliminate layout shift, unless the font is monospaced
   • It may not work on certain cursive/complex scripts, similar to letter-spacing
   • (Add more here...)

[r12a]

It may not work on certain cursive/complex scripts, similar to letter-spacing

Just a nit:

It's similar to letter-spacing for cursive scripts (although there's still a remote possibility that someone might come up with a use case that makes sense, esp. for non-Arabic scripts).

I don't think however that it's similar to letter-spacing wrt complex scripts in general, because letter-spacing is expected to handle those (albeit that some additional functionality needs to be specified/implemented*).

hth

• If you're curious about the details, see the latter part of the article we currently have out for review https://w3c.github.io/i18n-drafts/questions/qa-indic-graphemes.en.html.

[jfkthame]

Here are some topics and my proposals for the next meeting. Please add more if needed.

1. Are characters stretched/resized/etc when `advance-override` is applied?

Proposal: no. It has no effect for the purpose of reducing layout shift, but adds a lot of complexity to spec and implementation. If using advance-override severely affects legibility, then it's better to just use a more similar fallback font.

Agreed, no. advance-override doesn't touch glyph images, only spacing.

(I think there should be a separate font-size-override that can apply a scale factor to the used font size; I suspect this would often be the better tool to use.)

1. How is spacing added to each character?

Proposal: spacing is added after each character, for the reasons I gave in #5983 (comment) for reasons.

Disagree; I think spacing should be added equally on both sides of each glyph. Adding it asymmetrically (as some current letter-spacing implementations do) is often visually inferior IMO, particularly at run boundaries.

In general this feature should not be used to insert (or remove) more than a small percentage of the glyph width -- if you need more than that, you're using a bad choice of fallback font, or should be using font-size-override (see above) to completely re-scale it rather than just munging the spacing.

1. What's the default value of the second parameter, and what's the exact syntax?

Proposal: Use two descriptors advance-width-override and advance-height-override separately. This seems the cleanest among all the ideas I came up with.

Other ideas:

* `normal | [ <percentage> <percentage> ]` as [currently specified](https://drafts.csswg.org/css-fonts-5/#descdef-font-face-advance-override). In other words, second parameter is the same as the first if unspecified.

* `[normal | <percentage>] [normal | percentage]?`. In other words, it has no override to upright vertical text if the second parameter is not explicitly given.

I don't have a strong preference among these options. I think I'd lean towards either the first (separate width/height descriptors) or the third (second param defaults to normal, so no height override unless explicitly given), as most authors won't be thinking about vertical layout at all unless it's their primary focus, and there's little reason to expect that the same amount of override will make sense for both axes.

1. Add spec text to avoid over-promising. This includes:
   
   * It can't fully eliminate layout shift, unless the font is monospaced
   * It may not work on certain cursive/complex scripts, [similar to `letter-spacing`](https://drafts.csswg.org/css-text-3/#cursive-tracking)

+1 to mentioning that it may not work well with cursive/complex scripts.

However, I think we should not have spec text (like for letter-spacing) saying this doesn't apply to joined scripts, or anything "sophisticated" like that. This is equivalent to loading the font resource into a font editor and adding/removing sidebearings on each glyph to change its advance by a given percentage. Whether/how those glyphs interact with each other is not our concern here. This is an operation at the level of glyphs, not Unicode scripts/characters.

By all means include a warning for authors about applying this to glyphs that are supposed to visually join, but if an author nevertheless chooses to do so, they can. (I have seen old printed examples from lead-type days of letter-spacing-like effects in what would usually be joined scripts. Whether it's a good idea is not for us to say.)

If an author wants to (for example) use Arial as a fallback, with advance-override applied to its Latin letters but not to Arabic, they can do that by using unicode-range to spread it across a couple of @font-face rules, applying different descriptors to the different blocks of characters.