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

[Behdad Esfahbod]

Hi Skef,

* Indeed, CVT values are only calculated once per font, not per transformed
components.

* Is the full component transformation available to the bytecode? If yes,
we can spec that the VARC components are hinted post-transformation.

* What transformations are safe to hint can be left to the font. It can
have a function to determine that. It can even be in the `prep` code which
is run once, and set a CVT value to disable hinting fontwide if necessary.

b


behdad
http://behdad.org/


On Mon, Feb 5, 2024 at 5:04 PM Skef Iterum via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> Coming back to this subject --
>
> We just did a couple explicit tests and it appears that the developing
> understanding is still conflating two distinct things: whether and how the
> *context* that the font is being rendered in is transformed, and whether
> and how a component of a composite glyph is transformed.
>
> One might imagine a rasterizer that does something like the following:
>
>    1. Each component is given access to CVT-derived values that take into
>    account the total transformation of the component (any "external"
>    transformation plus any transformation at the composite level).
>    2. Whether grid-fitting is active depends on those component-specific
>    CVT values. If there is rotation or skew the fitting might always be off.
>    If there is just scaling maybe it is left on.
>    3. If the instructions are on, they apply to the points of the
>    component *post-*tranformation.
>
> What our experiments imply is:
>
>    1. The CVT values only vary by "external" transformation, not
>    component transformation. Therefore if there is no "external" skew or
>    rotation, instructions will generally be turned on for every component.
>    2. Grid-fitting of the component occurs *pre-*transformation. The
>    points of the component are transformed to their final locations in a later
>    step.
>
> So if this is accurate the typical result of rendering a component with a
> skew and/or rotation in a context that does not have skew and/or rotation
> will be to grid-fit the "original" component using its hint data and then
> transforming the result. This will yield a glyph that is distorted (due to
> the grid-fitting) but not hinted according to the pixel grid it is rendered
> against.
>
> So, one thing the VARC specification could, well, *specify* is that VARC
> components extracted from the glyf table are hinted more like the first
> list above than the second -- with further details presumably to be worked
> out. That way, with an appropriate header, grid fitting could be on or off
> depending on the total transformation of the component. Whether the
> existing instruction set is rich enough to handle non-uniform scaling when
> grid-fitting isn't cancelled by skew or rotation still seems like an open
> question, given that that's not how things seem to work in practice now.
> But such a change would be a start.
>
> However, the VARC spec being added to the working draft says *nothing*
> about hinting, apparently leaving the question of how hinting is supposed
> to be managed in the face of component transformation -- the latter being a
> central part of VARC -- unresolved.
>
> 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/20240206/1f8459b4/attachment-0001.htm>