[css-text-4] `text-spacing` and OpenType halt/vhal/chws/vchw features

[kojiishi]

Related with #8292 but I think this part is easier to discuss by splitting into a separate issue, so here it is.

When the text-spacing property makes some assumption on how glyphs are designed, such as specific parts of the glyph spaces are empty, it's great if font designers can override the behavior when they need.

To do this, I'd like to suggest that:

1. For the adjacent trimming, if the font has chws or vchw, the trimming should be deferred to the feature.
2. For other trimming, or for the adjacent trimming with the font without chws nor vchw, if the font has halt or vhal, the trimming should use the feature.
3. For other cases, if UA wants to synthesize the trimming, [css-text-4] Glyphs may collide by "Fullwidth Punctuation Collapsing" #8292 can discuss more.

Thoughts? /cc @litherum @fantasai @frivoal @MurakamiShinyu @macnmm

[macnmm]

I think this is one way the font designer could have control over mojikumi tsume (and therefore to some extent aki), but I still have concerns. The tsume amount (e.g. -50%) and aki amount (e.g. +50%) should normally be equal, but the purpose of the tsume amount is to normalize punctuation widths to the JIS X 4051 spec, so then added aki can be consistently applied between all class combinations, resulting in line compression or expansion. This is fine in the case of full width monospaced text, but what of punctuation whose design is not half-and-half? What about proportional typesetting? This is where the JIS spec lacks detail, and where one would hope the font could guide what happens with features. I feel these narrowing features are only part of the solution and defined in such a way as being more generalized than to solve JIS X 4051 (and beyond) spacing issues specifically.

[fantasai]

Last time I discussed internally with Nat and Ken, this is where we landed:

• If the font supports halt applied to the relevant codepoint that we want to trim, apply that.
• Otherwise, if the font supports hwid applied to the relevant codepoint and the glyph bounds are identical with/without hwid (which is a heuristic for “is it the same glyph?”), apply that.
• Otherwise, use the regular glyph but synthesize halt by adjusting the metrics.
  • For some glyphs, this will be cutting off the left or right half.
  • For others (e.g. middle punctuation) it will be cutting off 1/4 on each side.
  • In all cases, don't forget to adjust the glyph overflow metrics if the glyph overflows its bounds.

The last two are essentially “synthesize the missing halt” glyphs in fonts that don't have them.

We didn't discuss chws/vchw specifically, but they don't seem appropriate because for text-spacing we want the browser deciding which characters get trimmed, not the font. (Nat was very against using a font feature that makes the decisions about which glyphs to affect, both iirc because the layout engine should maintain control and also because it doesn't work properly across font changes.)

So I think CSS Text 4 should specify the use of halt, not hwid or chws; and we can add some suggested synthesis heuristics (we can discuss further also in #8292) for when the font doesn't support halt. CC @macnmm @kojiishi

[frivoal]

We didn't discuss chws/vchw specifically, but they don't seem appropriate because for text-spacing we want the browser deciding which characters get trimmed, not the font.

I'd agree with that. The fact that this feature uses context detection at the font level means that it'll fail when there are multiple fonts (or multiple font-sizes…).

Also, the documentation for that feature does say this:

Application interface: If a layout engine supports advanced layout for CJK text as described in CLREQ, JLREQ or KLREQ, this feature should not be used.

An engine with support for text-spacing is exactly that, that's one more point in the direction of not using this feature.

[kojiishi]

we want the browser deciding which characters get trimmed, not the font.

Fonts can control the kerning amount including disabling for specific glyphs/pairs with the method you described by adjusting halt, so the chws isn't much different. For fonts that have chws but without halt, chws is more reliable to know font designers' intentions than glyph bounds.

Also, the documentation for that feature does say this:

It means if the rendering engine/shaping engine applied kerning by halt or by other methods, chws shouldn't be enabled. It doesn't mean the rendering engine/shaping engine shouldn't utilize the data in chws to do the advanced layout.

[css-meeting-bot]

The CSS Working Group just discussed [css-text-4] `text-spacing` and OpenType halt/vhal/chws/vchw features, and agreed to the following:

• RESOLVED: Use H-ALT when available and need a half-width glyph, continue discussion wrt synthesis

The full IRC log of that discussion

<frances> Alan: next is spacing and open-type
<frances> fantasai: Several features in open type from full width to half width: HALT uses alternate metrics for the same glyph to set half-width, HWID allows for glyph substitution, CHWS does half-width or not depending on context. Is that correct Jonathan?
<frances> Johnathan: Not an expert, not sure.
<frances> fantasai: text-spaced-trim specify to trim the blank space, and trim properly without changing the shape of the glyph. HWID could substitute the glyph.
<frances> fantasai: Done in some, check the HWID feature and check the glyph substitution for the same shape and size, assume that HWID did not replace the glyph and apply if it behaves the same, depends on context
<frances> Alan: Resolve today or discuss more?
<frances> Florian: There is a disagreement on using H-ALT, what can you do when you can't use it?
<frances> fantasai: Use when it is available
<frances> PROPOSAL: Use H-ALT whenever you need a half-width glyph and H-ALT is available
<frances> fantasai: designed to use both, there are closing parentheses, need to change the spacing around it, why we don't want to use H-WID. Might be a reasonable proxy. If using glyph substitution, don't want to do it and better to substitute.
<frances> Johnathan: Can be used to substitute and replace. If it changes the shape, and affects the half-width of the glyph.
<frances> Florian: Remove the white-space. If half remove half. If not half, then remove. Get rid of the blank part if it does not fit.
<frances> Florian: Not sure on the rest
<frances> Alan: Can resolve on using H-ALT
<frances> PROPOSAL: Use H-ALT when available and need a half-width glyph
<frances> RESOLVED: Use H-ALT when available and need a half-width glyph

[fantasai]

Fonts can control the kerning amount including disabling for specific glyphs/pairs with the method you described by adjusting halt, so the chws isn't much different.

They can, but they aren't expected to. Afaict, HALT should be trimming glyphs unconditionally, whereas for CHWS they're supposed to be context-dependent (that's the point of the feature).

I think it's OK to use CHWS information to synthesize the HALT metrics, but if you just rely on CHWS you won't necessarily get the right behavior, because it might not trim where you need it to (or trim where it's not supposed to).

[kojiishi]

I think you misunderstood me. Let me try to clarify.

Fonts shoud be able to exclude specific glyphs from being trimmed, when font designers want to do so. They can do it by chws as you pointed out, but they can also do it by halt. Some existing fonts already do it. So when you wrote:

They can, but they aren't expected to. Afaict, HALT should be trimming glyphs unconditionally, whereas for CHWS they're supposed to be context-dependent (that's the point of the feature).

and:

we want the browser deciding which characters get trimmed, not the font.

and:

it might not trim where you need it to (or trim where it's not supposed to).

Either with chws or halt, fonts can override the browsers' decision. Both chws and halt (and all other font features) tell font designers' intentions to the layout engine, and the layout engine should honor them. There's no difference between the features in this regard.

[yisibl]

Some existing fonts already do it

Yes, in my fonts I will try to add them.

Either with chws or halt, fonts can override the browsers' decision

I agree.