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

[Peter Constable]

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

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


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
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/12d73d6d/attachment-0001.html>