<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 6, 2024, 6:37 PM Hin-Tak Leung <<a href="mailto:htl10@users.sourceforge.net">htl10@users.sourceforge.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div></div>
        <div>Apparently GETINFO bit 10 returns GX variation font support (this is undocumented AFAIK, and also what GETINFO does for the higher bits 10 onwards are undocumented), and there is an undocumented truetype instruction GETVARIATION for obtaining GX variation axes.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Search for GET in:</div><div dir="auto"><a href="https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview">https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview</a><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div>Might be interesting to "overload" that bit 10 and that instruction with new meanings for opentype variable fonts.</div><div><br></div>
        
        <div id="m_661767353195172008ydp3a2382a5yahoo_quoted_7514842844">
            <div style="font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;color:#26282a">
                
                <div>
                    On Tuesday, 6 February 2024 at 20:36:58 GMT, Greg Hitchcock via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" rel="noreferrer">mpeg-otspec@lists.aau.at</a>> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div id="m_661767353195172008ydp3a2382a5yiv8322253383"><div>
<div>
<p><span style="font-size:11.0pt">Behdad is correct that CVT values are calculated once per font at the parent transform.</span></p> 
<p><span style="font-size:11.0pt">  </span></p> 
<p><span style="font-size:11.0pt">The full component transform is not available to the bytecode.</span></p> 
<p><span style="font-size:11.0pt">  </span></p> 
<p><span style="font-size:11.0pt">The GETINFO instruction returns Bit 8 equal to 1 if the current glyph has been rotated, and bit 9 equal to 1 if the current glyph has been stretched.</span></p> 
<p><span style="font-size:11.0pt">  </span></p> 
<p><span style="font-size:11.0pt">GregH</span></p> 
<p><span style="font-size:11.0pt">  </span></p> 
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<div id="m_661767353195172008ydp3a2382a5yiv8322253383yqtfd78910"><p><b><span style="font-size:11.0pt;font-family:sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:sans-serif"> Behdad Esfahbod <<a href="mailto:behdad@behdad.org" target="_blank" rel="noreferrer">behdad@behdad.org</a>> Tuesday, February 6, 2024 8:56 AM<br clear="none">
<br clear="none">
</span></p> 
</div></div><div id="m_661767353195172008ydp3a2382a5yiv8322253383yqtfd36803">
<p>  </p> 
<div>
<p>Hi Skef,</p> 
<div>
<p>  </p> 
</div>
<div>
<p>* Indeed, CVT values are only calculated once per font, not per transformed components.</p> 
</div>
<div>
<p>  </p> 
</div>
<div>
<p>* Is the full component transformation available to the bytecode? If yes, we can spec that the VARC components are hinted post-transformation.</p> 
</div>
<div>
<p>  </p> 
</div>
<div>
<p>* What transformations are safe to hint can be left to the font. It can have a function to determine that. It can even be in the `prep` code which is run once, and set a CVT value to disable hinting fontwide if necessary.</p> 
</div>
<div>
<p>  </p> 
</div>
<div>
<p>b</p> 
</div>
<div>
<p>  </p> 
</div>
<div>
<p><br clear="all">
</p> 
<div>
<div>
<p>behdad<br clear="none">
<a shape="rect" href="http://behdad.org/" rel="nofollow noreferrer" target="_blank">http://behdad.org/</a></p> 
</div>
</div>
<p>  </p> 
</div>
</div>
<p>  </p> 
<div>
<div>
<p>On Mon, Feb 5, 2024 at 5:04<span style="font-family:sans-serif"> </span>PM Skef Iterum via mpeg-otspec <<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a>> wrote:</p> 
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p>Coming back to this subject --</p> 
<p>We just did a couple explicit tests and it appears that the developing understanding is still conflating two distinct things: whether and how the
<i>context</i> that the font is being rendered in is transformed, and whether and how a component of a composite glyph is transformed.
</p> 
<p>One might imagine a rasterizer that does something like the following:</p> 
<ol start="1" type="1"><li>
Each component is given access to CVT-derived values that take into account the total transformation of the component (any "external" transformation plus any transformation at the composite level).</li><li>
Whether grid-fitting is active depends on those component-specific CVT values. If there is rotation or skew the fitting might always be off. If there is just scaling maybe it is left on.</li><li>
If the instructions are on, they apply to the points of the component <i>post-</i>tranformation.
</li></ol> 
<p>What our experiments imply is:</p> 
<ol start="1" type="1"><li>
The CVT values only vary by "external" transformation, not component transformation. Therefore if there is no "external" skew or rotation, instructions will generally be turned on for every component.</li><li>
Grid-fitting of the component occurs <i>pre-</i>transformation. The points of the component are transformed to their final locations in a later step.
</li></ol> 
<p>So if this is accurate the typical result of rendering a component with a skew and/or rotation in a context that does not have skew and/or rotation will be to grid-fit the "original" component using its hint data and then transforming the result. This will
 yield a glyph that is distorted (due to the grid-fitting) but not hinted according to the pixel grid it is rendered against.
</p> 
<p>So, one thing the VARC specification could, well, <i>specify</i> is that VARC components extracted from the glyf table are hinted more like the first list above than the second -- with further details presumably to be worked out. That way, with an appropriate
 header, grid fitting could be on or off depending on the total transformation of the component. Whether the existing instruction set is rich enough to handle non-uniform scaling when grid-fitting isn't cancelled by skew or rotation still seems like an open
 question, given that that's not how things seem to work in practice now. But such a change would be a start.
</p> 
<p>However, the VARC spec being added to the working draft says <i>nothing</i> about hinting, apparently leaving the question of how hinting is supposed to be managed in the face of component transformation -- the latter being a central part of VARC -- unresolved.
</p> 
<p>Skef</p> 
<div>
<p>On 1/26/24 13:04, Greg Hitchcock wrote:</p> 
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p><span style="font-size:11.0pt">Through a combination of the GETINFO instruction and the INSTCTRL instruction, glyphs or fonts can make educated decisions
 about whether to apply instructions under different circumstances such as rotations, stretching, &c. Typically we recommend in the pre-program to disable hints under rotation, but if someone comes up with a clever algorithm for handling this, that is an option.</span></p> 
<p><span style="font-size:11.0pt"> </span></p> 
<p><span style="font-size:11.0pt">GregH</span></p> 
<p><span style="font-size:11.0pt"> </span></p> 
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p><b><span style="font-size:11.0pt;font-family:sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:sans-serif"> mpeg-otspec
<a shape="rect" href="mailto:mpeg-otspec-bounces@lists.aau.at" rel="nofollow noreferrer" target="_blank"><mpeg-otspec-bounces@lists.aau.at></a>
<b>On Behalf Of </b>Skef Iterum via mpeg-otspec<br clear="none">
<b>Sent:</b> Friday, January 26, 2024 11:33 AM<br clear="none">
<b>To:</b> Laurence Penney <a shape="rect" href="mailto:lorp@lorp.org" rel="nofollow noreferrer" target="_blank"><lorp@lorp.org></a><br clear="none">
<b>Cc:</b> mpeg-otspec <a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">
<mpeg-otspec@lists.aau.at></a><br clear="none">
<b>Subject:</b> Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions</span></p> 
</div>
</div>
<p> </p> 
<table align="left" border="0" cellspacing="0" cellpadding="0" width="100%" style="width:100.0%"><tbody><tr><td colspan="1" rowspan="1" style="background:#a6a6a6;padding:5.25pt 1.5pt 5.25pt 1.5pt"></td><td colspan="1" rowspan="1" width="100%" style="width:100.0%;background:#eaeaea;padding:5.25pt 3.75pt 5.25pt 11.25pt">
<div>
<p>
<span style="font-size:9.0pt;font-family:sans-serif;color:#212121">You don't often get email from
<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a>.
<a shape="rect" href="https://aka.ms/LearnAboutSenderIdentification" rel="nofollow noreferrer" target="_blank">Learn why this is important</a></span></p> 
</div>
</td><td colspan="1" rowspan="1" width="75" style="width:56.25pt;background:#eaeaea;padding:5.25pt 3.75pt 5.25pt 3.75pt">
</td></tr></tbody></table>
<div>
<p> </p> 
<div>
<p>On 1/24/24 23:47, Laurence Penney wrote:</p> 
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p>On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec
<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank"><mpeg-otspec@lists.aau.at></a> wrote:</p> 
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p>There is a distinction between whether the text path itself is skewed or<br clear="none">
rotated and whether a component in a composite is skewed or rotated.<br clear="none">
Asking around it seems as though with the existing glyf components<br clear="none">
instructions are <i>not</i> automatically turned off when "compositing", but<br clear="none">
perhaps that info is wrong. </p> 
<p>Either way, though, that seems like something the specification should<br clear="none">
clarify.</p> 
</blockquote>
</div>
<div>
<p>I asked similar questions when I was getting my head around TT hinting, and recall being told that skewed or rotated components were not hinted. The person I asked would most likely
 have been Greg Hitchcock.</p> 
</div>
<div>
<p> </p> 
</div>
</blockquote>
<p>Josh Hadley on our team got curious about this and did an experiment or two<br clear="none">
in VTT. As far as we can tell there is no automatic disabling of hints when using<br clear="none">
"not nice" transformations, at least in that tool. We can provide a specific<br clear="none">
example or two if anyone needs them.<br clear="none">
<br clear="none">
It's possible that the "client side" implementations work differently than the <br clear="none">
development tools but designers are likely to take the guidance of those tools<br clear="none">
unless there is very strong conventional wisdom pointing in a different<br clear="none">
direction.</p> 
<p>Skef</p> 
</div>
</div>
</blockquote>
</div>
<p>_______________________________________________<br clear="none">
mpeg-otspec mailing list<br clear="none">
<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a><br clear="none">
<a shape="rect" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="nofollow noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a></p> 
</blockquote>
</div>
</div></div><div id="m_661767353195172008ydp3a2382a5yiv8322253383yqtfd53283">
</div></div></div><div id="m_661767353195172008ydp3a2382a5yqtfd47045">_______________________________________________<br clear="none">mpeg-otspec mailing list<br clear="none"><a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a><br clear="none"><a shape="rect" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="nofollow noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br clear="none"></div></div>
            </div>
        </div></div></div></blockquote></div></div></div>