[MPEG-OTSPEC] VARC, glyf, and TT-instructions

[Skef Iterum]

On 1/24/24 16:39, Liam R. E. Quin wrote:
> On Wed, 2024-01-24 at 14:50 -0800, Skef Iterum via mpeg-otspec wrote:
>>   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.
> 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.
There is a distinction between whether the text path itself is skewed or
rotated and whether a component in a composite is skewed or rotated.
Asking around it seems as though with the existing glyf components
instructions are /not/ automatically turned off when "compositing", but
perhaps that info is wrong.

Either way, though, that seems like something the specification should
clarify.

>>     1. Should there not be a VARC component flag that, when pulling
>> components from a glyf table suppresses the instructions of that
>> component?
> i belive no, because if someone finds a way to make it work usefully,
> they shouldn't be prohibited from doing so.
I'm not sure what this means -- presumably such a flag would be
off when the instructions should be applied and on when they
shouldn't be, leaving it up to the designer or font engineer whether
the instructions are valid in the compositing context (relative to the
transformation being applied -- this would, or could, leave it up to
the designer whether the set of instructions on the glyph would work
relative to the transformation being applied, at least at that level of
nesting).
>>     2. Should applications of that flag cancel the instructions of
>> nested composites as well?
> that sounds like an implementation issue.
See above -- this would be part of the documented behavior of such
a flag.
>>     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?
> this also sounds like an implementation issue.
Doesn't the designer/engineer need to know specifically when
instructions will or will not be applied in order to know how to
build the font? E.g. when to include a component using a
transformation vs copy the component partially or fully
transformed and re-hint that version?
>>     4. What are those problematic transformations -- anything but
>> translation? Anything but translation and scaling?
> rotation by 90 or 180 degrees may be well-defined.
Maybe! Do we know? Does it depend on the particular instructions one is
using?
>>     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?
> 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.
Really? A given set of instructions may "work" in that they modify the
positions of well-defined points, but they may leave those points at
undesirable positions. Are we saying that what happens with a given
set of instructions would be implementation-specific?
>>     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,
> 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.
I think I would agree with this as long as what "will work" is well-defined
enough in the spec, either directly or by implication.

As far as I can tell from what's written, if one is going to hint the glyphs
the only entirely safe thing to do is to copy and rehint components whenever
their rotation, skew, or perhaps even scale changes and then only use
design space position, translation, and perhaps scale as component
adjustments.

If, for example, I have a glyph of "a" and I want to use it translated 20
times and rotated once, I need two components for that because even
if I don't care if the rotated case is hinted, there's no indication in the
spec of whether the instructions will be applied in that case, and no
control over whether they are, so the instructions I've included for the
20 translated composites will screw up the rotated composite. (And if 
it's up
to the implementation then I need to copy because it will be wrong on
whatever implementation does apply the instructions.)

Maybe this is what was intended -- maybe much of this new stuff is only
meant for non-hinted fonts. That's what I was wondering months ago
when I asked if this was a "post-hinting" proposal. But it was suggested
that it wasn't, in which case the spec should be specific enough so that the
designer can determine how their font should be hinted (perhaps in most
cases via a separate document that describes the /implications/ of the
requirements and features of the specification).

Skef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240124/c240c799/attachment.html>