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

Skef Iterum skef at skef.org
Sat Jan 27 00:59:26 CET 2024


Alright, it's sounding like the idea may be "the instruction set itself 
has enough
functionality to handle the cases, so we can let glyf VARC hinting 
practices
evolve on that basis." I'd be worried that people who seem to be towards 
the upper
levels of typical expertise with TT instructions are fuzzy on the 
relevant functionality,
but that isn't my battle.

That would still leave 6 from my earlier list:

    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?)

I suppose one could also just add a record type that inlines the 
composite-level
instructions directly.

This has to do with this line from the glyf composite spec ( 
https://learn.microsoft.com/en-us/typography/opentype/spec/glyf#composite-glyph-description 
):

    A parent composite glyph description can include instructions that
    apply to the composite as a whole, after instructions for each child
    have been performed.

This possibility appears to be missing from VARC as specified. (I 
believe it was also
missing from the earlier drafts but maybe there was a different way of 
tucking
those instructions into the composite record.)

Skef

On 1/26/24 13:04, Greg Hitchcock wrote:
>
> 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.
>
> GregH
>
> *From:*mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> *On Behalf Of 
> *Skef Iterum via mpeg-otspec
> *Sent:* Friday, January 26, 2024 11:33 AM
> *To:* Laurence Penney <lorp at lorp.org>
> *Cc:* mpeg-otspec <mpeg-otspec at lists.aau.at>
> *Subject:* Re: [MPEG-OTSPEC] VARC, glyf, and TT-instructions
>
>
> 	
>
> You don't often get email from mpeg-otspec at lists.aau.at. Learn why 
> this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> 	
>
> On 1/24/24 23:47, Laurence Penney wrote:
>
>         On 25 Jan 2024, at 01:25, Skef Iterum via mpeg-otspec
>         <mpeg-otspec at lists.aau.at> <mailto:mpeg-otspec at lists.aau.at>
>         wrote:
>
>         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.
>
>     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.
>
> Josh Hadley on our team got curious about this and did an experiment 
> or two
> in VTT. As far as we can tell there is no automatic disabling of hints 
> when using
> "not nice" transformations, at least in that tool. We can provide a 
> specific
> example or two if anyone needs them.
>
> It's possible that the "client side" implementations work differently 
> than the
> development tools but designers are likely to take the guidance of 
> those tools
> unless there is very strong conventional wisdom pointing in a different
> direction.
>
> Skef
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240126/5781a8c8/attachment.html>


More information about the mpeg-otspec mailing list