<div dir="ltr"><div dir="ltr">On Fri, Jan 26, 2024 at 3:59 PM Skef Iterum via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>> wrote:<br></div><div class="gmail_quote"><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>Alright, it's sounding like the idea may be "the instruction set
itself has enough <br>
functionality to handle the cases, so we can let glyf VARC hinting
practices <br>
evolve on that basis." I'd be worried that people who seem to be
towards the upper<br>
levels of typical expertise with TT instructions are fuzzy on the
relevant functionality,<br>
but that isn't my battle.</p>
<p>That would still leave 6 from my earlier list:</p>
<p> </p>
<blockquote>Should there be a VARC-component flag indicating that
what is being loaded is not an individual component but the
(limited) composite-level TT instructions for this glyph? (The
natural home for those instructions being in the glyph with the
same GID, as same-GID-loading is already supported by the spec?)<br>
</blockquote>
<p>I suppose one could also just add a record type that inlines the
composite-level<br>
instructions directly.<br>
</p>
<p>This has to do with this line from the glyf composite spec (
<a href="https://learn.microsoft.com/en-us/typography/opentype/spec/glyf#composite-glyph-description" target="_blank">https://learn.microsoft.com/en-us/typography/opentype/spec/glyf#composite-glyph-description</a>
):</p>
<blockquote>
<p>A parent composite glyph description can include instructions
that apply to the composite as a whole, after instructions for
each child have been performed.<br>
</p>
</blockquote>
<p>This possibility appears to be missing from VARC as specified. (I
believe it was also<br>
missing from the earlier drafts but maybe there was a different
way of tucking<br>
those instructions into the composite record.)<br></p></div></blockquote><div><br></div><div>Hi Skef,</div><div><br></div><div>It's definitely possible to add a "HAVE_MORE" flag to the VARC component records, and use whatever remaining bytes at the end of the composite glyph description as hinting data, like the classic components. But since we decided to make VARC outline-table-agnostic, I didn't go in that direction.</div><div><br></div><div>Putting the hinting data in the same-gid glyph is also not ideal. Most authoring tools allow for mixing outline and components. In my current design, one can put the outline in the same-gid and refer to it as a regular VARC component. I like this design. That said, there's room at the end of a simple glyph, which we can declare as VARC instructions. It's a bit rough to reach it out and not the most elegant design.</div><div><br></div><div>Another complexity is to declare what data gets exposed to the hinting instructions. I suppose these should be the same as whatever the VARC flags declare as available. Though an alternative would be to expose the full transform components. I'm not sure if hinting should be able to modify the axis locations or not.</div><div><br></div><div>Just my 0.02CAD for now,</div><div>behdad</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</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></div>