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

Wed Feb 7 02:37:12 CET 2024

 Apparently GETINFO bit 10 returns GX variation font support (this is undocumented AFAIK, and also what GETINFO does for the higher bits 10 onwards are undocumented), and there is an undocumented truetype instruction GETVARIATION for obtaining GX variation axes.
Might be interesting to "overload" that bit 10 and that instruction with new meanings for opentype variable fonts.
    On Tuesday, 6 February 2024 at 20:36:58 GMT, Greg Hitchcock via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  

Behdad is correct that CVT values are calculated once per font at the parent transform.

The full component transform is not available to the bytecode.

The GETINFO instruction returns Bit 8 equal to 1 if the current glyph has been rotated, and bit 9 equal to 1 if the current glyph has been stretched.

GregH

From: Behdad Esfahbod <behdad at behdad.org> Tuesday, February 6, 2024 8:56 AM

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 thecontext 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:

   - 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).
   - 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.
   - If the instructions are on, they apply to the points of the component post-tranformation.

What our experiments imply is:

   - 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.
   - 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>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 frommpeg-otspec at lists.aau.at.Learn why this is important
  |  |

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

_______________________________________________
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/20240207/74ee706d/attachment.htm>