<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cordia New";
panose-1:2 11 3 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">I’d like to clarify something regarding <span style="background:aqua;mso-highlight:aqua">
my questions below</span>. As the OTL feature tag registry was set up _<i>as a registry</i>_, 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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks<o:p></o:p></p>
<p class="MsoNormal">Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> mpeg-otspec <mpeg-otspec-bounces@lists.aau.at> <b>
On Behalf Of </b>Peter Constable<br>
<b>Sent:</b> Wednesday, August 19, 2020 8:56 AM<br>
<b>To:</b> MPEG OT Spec list (mpeg-otspec@lists.aau.at) <mpeg-otspec@lists.aau.at><br>
<b>Subject:</b> [MPEG-OTSPEC] lookup processing and 'chws', 'vchw'<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="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">https://lists.aau.at/pipermail/mpeg-otspec/2018-December/000060.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<pre>“<span style="color:black">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.<o:p></o:p></span></pre>
<pre><span style="color:black">“As usual, silence is treated as approval so please speak up!</span>”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><a href="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">https://lists.aau.at/pipermail/mpeg-otspec/2019-January/000066.html</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Now, in the descriptions for ‘chws’ and ‘vchw’, I noticed this:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<pre>“<span style="color:black">When using the [GPOS] type 2 lookup on a run of glyphs, it’s critical to remember <span style="background:yellow;mso-highlight:yellow">to not consume the last glyph</span>, but to keep it available as the first glyph in a subsequent run (this is a departure from normal lookup behavior).</span>”<span style="color:black"><o:p></o:p></span></pre>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">“<span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#171717;background:white">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).</span>”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="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">https://docs.microsoft.com/en-us/typography/opentype/spec/chapter2#lookupTbl</a><o:p></o:p></p>
<p class="MsoNormal">See also ISO/IEC 14496-22:2019, clause 6.2.5.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So, the “not consume” clause in the description of ‘chws’ and ‘vchw’ would seem to be consistent with the rest of the spec _<i>provided that the GPOS type 2 lookups do not act on the second glyph</i>_. However, the descriptions for these
features don’t give any indication that that constraint should be followed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="background:aqua;mso-highlight:aqua">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 _<i>exceptionally</i>_ not consume the second glyph in this case?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="background:aqua;mso-highlight:aqua"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="background:aqua;mso-highlight:aqua">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…?</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks<o:p></o:p></p>
<p class="MsoNormal">Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>