[MPEG-OTSPEC] lookup processing and 'chws', 'vchw'

Wed Aug 19 22:43:27 CEST 2020

I'd like to clarify something regarding my questions below. As the OTL feature tag registry was set up _as a registry_, I have taken that to mean that new feature tag requests may be subject to technical review for refinement but, unless a requested tag is really not well formed or very obviously flawed, that it's not subject to any kind of veto: a registered tag might be implemented only by the party that registered it, and the registry serves the intended purpose of allowing others to create products that interop with that the registering party's products that (presumably) support it.

In other words, there's no question in my mind that the 'chws' and 'vchw' tags should get added to the OT feature tag registry.

But, as background information for general awareness, I would like to understand the status of implementations of these features. And if it does come to light that there are refinements that can or should be made in the feature descriptions, then I'd like to see that discussed so that improvements in OT and OFF can get made.

There's also an additional question I'd like to ask: These features were registered jointly by Adobe and by W3C. I'd like to understand what, if anything, might be implied by W3C requesting this tag? Are there W3C specs that depend on implementation of these features as described? Have browsers already implemented or are in process of implementing support for these features?

Thanks
Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Peter Constable
Sent: Wednesday, August 19, 2020 8:56 AM
To: MPEG OT Spec list (mpeg-otspec at lists.aau.at) <mpeg-otspec at lists.aau.at>
Subject: [MPEG-OTSPEC] lookup processing and 'chws', 'vchw'

While reviewing the content of Amendment 1 of ISO/IEC 14496-22:2019, I noticed the addition of the 'chws' and 'vchw' feature tags (which are not yet listed in the OT feature tag registry). This was proposed December 8, 2018 as Vlad was wrapping up content to go into Amendment 1.

https://lists.aau.at/pipermail/mpeg-otspec/2018-December/000060.html<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fpipermail%2Fmpeg-otspec%2F2018-December%2F000060.html&data=02%7C01%7C%7C373e19a980f14631c97c08d8445858e3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637334493531466621&sdata=dRU4%2BtJOhgJ4u0oC%2Bl5QZ7MmXRQYo86kuKxjltteqR0%3D&reserved=0>

December, of course, is not the best time of year to get eyes on things. On January 2, 2019, Vlad asked once more for comments.

"We need to finalize this and prepare an input contribution for the upcoming WG11 meeting (coming up on January 14-18, 2019); the submission deadline for input contribution is end of day Jan. 7, 2019 (Monday next week). If any of you have an objection to the proposed changes, or if you would like to suggest any additional changes - please respond on this email list no later than end of day Friday, January 4th.

"As usual, silence is treated as approval so please speak up!"

https://lists.aau.at/pipermail/mpeg-otspec/2019-January/000066.html<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fpipermail%2Fmpeg-otspec%2F2019-January%2F000066.html&data=02%7C01%7C%7C373e19a980f14631c97c08d8445858e3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637334493531476617&sdata=L%2BnFh0mO8jz54Q6dnUASIDZxgsNCxuVn11gClbx%2BboY%3D&reserved=0>

Then on January 4, Vlad circulated his updated draft of Amd 1 and again solicited comments. Rob McKaughan (MS) was the only one to comment, raising a concern regarding use of 'vert' in GPOS and asking for time to investigate. Ken Lunde gave a reply, and nothing further was said. The changes went in and were balloted in ISO process.

One shortcoming of the process is that none of us font nerdy engineer types (Dave, you're spot on!) are really engaged directly or through the various companies in the formal ISO balloting process. Effectively, I think that meant that the addition of 'chws' and 'vchw' went in without much review.

Now, in the descriptions for 'chws' and 'vchw', I noticed this:

"When using the [GPOS] type 2 lookup on a run of glyphs, it's critical to remember to not consume the last glyph, but to keep it available as the first glyph in a subsequent run (this is a departure from normal lookup behavior)."

Now, a GPOS type 2 evaluates pairs of glyphs and can make positioning adjustments on one or both. If only the first glyph is acted on (the second is still matched for context), then when processing of a lookup subtable is complete the second glyph with be the next glyph in lookup subtable processing. But if the left glyph's positioning is adjusted, then it is "consumed"-i.e., processing will advance to the following glyph. This is in accordance with the following:

"During text processing, a client applies a lookup to each glyph in the string before moving to the next lookup. A lookup is finished for a glyph after the client makes the substitution/positioning operation. To move to the "next" glyph, the client will typically skip all the glyphs that participated in the lookup operation: glyphs that were substituted/positioned as well as any other glyphs that formed a context for the operation. However, in the case of pair positioning operations (i.e., kerning), the "next" glyph in a sequence may be the second glyph of the positioned pair (see pair positioning lookup for details)."

https://docs.microsoft.com/en-us/typography/opentype/spec/chapter2#lookupTbl<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fchapter2%23lookupTbl&data=02%7C01%7C%7C373e19a980f14631c97c08d8445858e3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637334493531476617&sdata=pqGnYdMoIUMDs1L2oddTFQlOApOLbgb0vwTqPPaXbHc%3D&reserved=0>
See also ISO/IEC 14496-22:2019, clause 6.2.5.

So, the "not consume" clause in the description of 'chws' and 'vchw' would seem to be consistent with the rest of the spec _provided that the GPOS type 2 lookups do not act on the second glyph_. However, the descriptions for these features don't give any indication that that constraint should be followed.

Thus, I'd like to know if such a constraint on type 2 lookups used for 'chws'/'vchw' was intended but somehow left out of the descriptions (hence should be added)? Or was it really intended (as it appears on the surface) that type 2 lookups for 'chws'/'vchw' should be allowed to act on the second glyph but that clients should _exceptionally_ not consume the second glyph in this case?

If the latter, I'd like to know which products, or which text layout or shaping libraries supports this? Is this compatible with CoreText? With DWrite? With Harfbuzz? Other...?

Thanks
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200819/a24ca69e/attachment.html>