<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/24/24 16:39, Liam R. E. Quin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c6a433b0e8ad9c8c84d19065f538554ff26ba109.camel@fromoldbooks.org">
<pre class="moz-quote-pre" wrap="">On Wed, 2024-01-24 at 14:50 -0800, Skef Iterum via mpeg-otspec wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> At the same time, component instructions are very unlikely to work
in the face of skews or rotations, and may not even work in the face
of scaling.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
My understanding has always been that renderers turn off hinting when
text is skewed or rotated (other than by a multiple of 90°). I think
the onlky font format i know of that defined hinting for rotated text
was Folio’s F3, later co-owned i think by Morisawa and Sun, which had
built-in drop-out hinting.
So i’d expect a renderer to do the same with variable components that
are skewed or rotated.
</pre>
</blockquote>
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.
<p>Either way, though, that seems like something the specification
should<br>
clarify.<br>
</p>
<blockquote type="cite"
cite="mid:c6a433b0e8ad9c8c84d19065f538554ff26ba109.camel@fromoldbooks.org">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 1. Should there not be a VARC component flag that, when pulling
components from a glyf table suppresses the instructions of that
component?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
i belive no, because if someone finds a way to make it work usefully,
they shouldn't be prohibited from doing so.
</pre>
</blockquote>
I'm not sure what this means -- presumably such a flag would be<br>
off when the instructions should be applied and on when they<br>
shouldn't be, leaving it up to the designer or font engineer whether<br>
the instructions are valid in the compositing context (relative to
the<br>
transformation being applied -- this would, or could, leave it up to<br>
the designer whether the set of instructions on the glyph would work<br>
relative to the transformation being applied, at least at that level
of<br>
nesting).<br>
<blockquote type="cite"
cite="mid:c6a433b0e8ad9c8c84d19065f538554ff26ba109.camel@fromoldbooks.org">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 2. Should applications of that flag cancel the instructions of
nested composites as well?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
that sounds like an implementation issue.
</pre>
</blockquote>
See above -- this would be part of the documented behavior of such<br>
a flag.<br>
<blockquote type="cite"
cite="mid:c6a433b0e8ad9c8c84d19065f538554ff26ba109.camel@fromoldbooks.org">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 3. If there is not such a flag, and perhaps if there is, should
instructions be cancelled when certain total (i.e. top-to-bottom)
transformations are in play? Or automatically cancelled for the
portions of the compositing tree in which they are in play?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
this also sounds like an implementation issue.
</pre>
</blockquote>
Doesn't the designer/engineer need to know specifically when <br>
instructions will or will not be applied in order to know how to<br>
build the font? E.g. when to include a component using a <br>
transformation vs copy the component partially or fully<br>
transformed and re-hint that version?<br>
<blockquote type="cite"
cite="mid:c6a433b0e8ad9c8c84d19065f538554ff26ba109.camel@fromoldbooks.org">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 4. What are those problematic transformations -- anything but
translation? Anything but translation and scaling?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
rotation by 90 or 180 degrees may be well-defined.
</pre>
</blockquote>
Maybe! Do we know? Does it depend on the particular instructions one
is<br>
using?<br>
<blockquote type="cite"
cite="mid:c6a433b0e8ad9c8c84d19065f538554ff26ba109.camel@fromoldbooks.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 5. Do there need to be flags to indicate what transformations a
set of instructions are "immune" to? Since those instructions will be
atom-level, where would those flags live?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
no, this is something an implementation must determine - the flag would
at best be advisory, and if things go wrong if the flag is set wrongly,
the implementation has to cope.</pre>
</blockquote>
Really? A given set of instructions may "work" in that they modify
the<br>
positions of well-defined points, but they may leave those points at<br>
undesirable positions. Are we saying that what happens with a given<br>
set of instructions would be implementation-specific? <br>
<blockquote type="cite"
cite="mid:c6a433b0e8ad9c8c84d19065f538554ff26ba109.camel@fromoldbooks.org"><span
style="white-space: pre-wrap">
</span>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> 7. Whether or not any of the above results in spec changes, should
there not be guidance about how to hint glyf-based VARC fonts,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yes, i believe that there should be, but it does not belong in the
spec. The reason i say that is because experience will evolve over time
at a different rate than the ISO spec gets revised, and because the
audience is somewhat different.</pre>
</blockquote>
I think I would agree with this as long as what "will work" is
well-defined<br>
enough in the spec, either directly or by implication. <br>
<br>
As far as I can tell from what's written, if one is going to hint
the glyphs<br>
the only entirely safe thing to do is to copy and rehint components
whenever<br>
their rotation, skew, or perhaps even scale changes and then only
use<br>
design space position, translation, and perhaps scale as component<br>
adjustments.
<p>If, for example, I have a glyph of "a" and I want to use it
translated 20 <br>
times and rotated once, I need two components for that because
even<br>
if I don't care if the rotated case is hinted, there's no
indication in the<br>
spec of whether the instructions will be applied in that case, and
no<br>
control over whether they are, so the instructions I've included
for the<br>
20 translated composites will screw up the rotated composite. (And
if it's up<br>
to the implementation then I need to copy because it will be wrong
on<br>
whatever implementation does apply the instructions.)<br>
<br>
Maybe this is what was intended -- maybe much of this new stuff is
only<br>
meant for non-hinted fonts. That's what I was wondering months ago<br>
when I asked if this was a "post-hinting" proposal. But it was
suggested<br>
that it wasn't, in which case the spec should be specific enough
so that the<br>
designer can determine how their font should be hinted (perhaps in
most<br>
cases via a separate document that describes the <i>implications</i>
of the<br>
requirements and features of the specification).</p>
<p>Skef<br>
</p>
</body>
</html>