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

[Behdad Esfahbod]

On Fri, Jan 26, 2024 at 3:59 PM Skef Iterum via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

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

Hi Skef,

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.

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.

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.

Just my 0.02CAD for now,
behdad


> 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>
> <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> <lorp at lorp.org>
> *Cc:* mpeg-otspec <mpeg-otspec at lists.aau.at> <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> <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
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240128/a30fd7af/attachment.html>