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

[Peter Constable]

I guess there’s another question I can ask: When using GPOS type 2 lookups for ‘kern’ (or ‘vkrn’, ‘chws’, ‘vchw’), do font developers / font development tools usually make adjustments to the first glyph only?

Per the currently spec’d processing, if valueFormat2 in GPOS type 2 lookups is 0, then the second glyph is not consumed. If that is typically the way kerning lookups are implemented (which seems reasonable), then indeed the intent of the wording all along may have been a recommendation to font developers, not a requirement on shaping engine implementations — which is how it currently comes across (at least, to me). And if that is the intent, then I think the wording should be revised to make that clear.


Peter

From: Koji Ishii <kojii at chromium.org>
Sent: Wednesday, August 19, 2020 11:31 PM
To: Ken Lunde <ken.lunde at gmail.com>
Cc: Peter Constable <pgcon6 at msn.com>; MPEG OT Spec list (mpeg-otspec at lists.aau.at) <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] lookup processing and 'chws', 'vchw'

> On Aug 19, 2020, at 08:55, Peter Constable <pgcon6 at msn.com<mailto:pgcon6 at msn.com>> wrote:
>  :
> 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?

Ken knows the text best but I think the answer is the former; there's no intention to add an exceptional behavior. The intention is to use existing code without modifications. Ken and I were testing this feature using existing browsers:
https://kojiishi.github.io/cspc/test.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkojiishi.github.io%2Fcspc%2Ftest.html&data=02%7C01%7C%7C82e2d555f0bd428da5ad08d844d2a574%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637335018787421525&sdata=ad7rwtAnH03qhHAEEilsFOFL5oXOHybxJq%2FNy2pTfco%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200820/77515d4f/attachment.html>