<div dir="ltr">Hi Skef,<div><br></div><div>* Indeed, CVT values are only calculated once per font, not per transformed components.</div><div><br></div><div>* Is the full component transformation available to the bytecode? If yes, we can spec that the VARC components are hinted post-transformation.</div><div><br></div><div>* 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.</div><div><br></div><div>b</div><div><br></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 5, 2024 at 5:04 PM Skef Iterum via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<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. <br>
</p>
<p>One might imagine a rasterizer that does something like the
following:</p>
<ol>
<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. <br>
</li>
</ol>
<p>What our experiments imply is:</p>
<ol>
<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. <br>
</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. <br>
</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. <br>
</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. <br>
</p>
<p>Skef<br>
</p>
<div>On 1/26/24 13:04, Greg Hitchcock wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Sitka Text"">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Sitka Text""><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Sitka Text"">GregH<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Sitka Text""><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif">
mpeg-otspec <a href="mailto:mpeg-otspec-bounces@lists.aau.at" target="_blank"><mpeg-otspec-bounces@lists.aau.at></a>
<b>On Behalf Of </b>Skef Iterum via mpeg-otspec<br>
<b>Sent:</b> Friday, January 26, 2024 11:33 AM<br>
<b>To:</b> Laurence Penney <a href="mailto:lorp@lorp.org" target="_blank"><lorp@lorp.org></a><br>
<b>Cc:</b> mpeg-otspec <a href="mailto:mpeg-otspec@lists.aau.at" target="_blank"><mpeg-otspec@lists.aau.at></a><br>
<b>Subject:</b> Re: [MPEG-OTSPEC] VARC, glyf, and
TT-instructions<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<table style="width:100%" width="100%" cellspacing="0" cellpadding="0" border="0" align="left">
<tbody>
<tr>
<td style="background:rgb(166,166,166);padding:5.25pt 1.5pt"><br>
</td>
<td style="width:100%;background:rgb(234,234,234);padding:5.25pt 3.75pt 5.25pt 11.25pt" width="100%">
<div>
<p class="MsoNormal">
<span style="font-size:9pt;font-family:"Segoe UI",sans-serif;color:rgb(33,33,33)">You
don't often get email from
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>.
<a href="https://aka.ms/LearnAboutSenderIdentification" target="_blank">
Learn why this is important</a><u></u><u></u></span></p>
</div>
</td>
<td style="width:56.25pt;background:rgb(234,234,234);padding:5.25pt 3.75pt" width="75">
<br>
</td>
</tr>
</tbody>
</table>
<div>
<p><u></u> <u></u></p>
<div>
<p class="MsoNormal">On 1/24/24 23:47, Laurence Penney
wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">On 25 Jan 2024, at 01:25, Skef
Iterum via mpeg-otspec <a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">
<mpeg-otspec@lists.aau.at></a> wrote:<u></u><u></u></p>
</blockquote>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">There is a distinction between
whether the text path itself is skewed or<br>
rotated and whether a component in a composite is
skewed or rotated.<br>
Asking around it seems as though with the existing
glyf components<br>
instructions are <i>not</i> automatically turned off
when "compositing", but<br>
perhaps that info is wrong. <u></u><u></u></p>
<p>Either way, though, that seems like something the
specification should<br>
clarify.<u></u><u></u></p>
</blockquote>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
<p class="MsoNormal">Josh Hadley on our team got curious about
this and did an experiment or two<br>
in VTT. As far as we can tell there is no automatic
disabling of hints when using<br>
"not nice" transformations, at least in that tool. We can
provide a specific<br>
example or two if anyone needs them.<br>
<br>
It's possible that the "client side" implementations work
differently than the <br>
development tools but designers are likely to take the
guidance of those tools<br>
unless there is very strong conventional wisdom pointing in
a different<br>
direction.<u></u><u></u></p>
<p>Skef<u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div>