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

Wed Feb 7 02:41:52 CET 2024

On Tue, Feb 6, 2024, 6:37 PM Hin-Tak Leung <htl10 at users.sourceforge.net>
wrote:

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

Search for GET in:
https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview


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 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
>
> _______________________________________________
> 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/cc5d0bf3/attachment-0001.htm>