Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STAT: modify definition of Format 4 to include functionality of Format 2 and Format 3 #15

Open
Lorp opened this issue Sep 18, 2020 · 3 comments

Comments

@Lorp
Copy link

Lorp commented Sep 18, 2020

The STAT table should be improved so that Format 4 (multi-axis axisValueTable) is able to represent the axis range and linkedValue features of Format 2 and Format 3 respectively, as well as Format 1 which it can already handle. Here follows a backwards-compatible proposal.

When you’ve been immersed in visualizing variable fonts for a while, you start to notice similarities in abstract data structures that are not necessarily apparent from the specification. One repeated abstract structure is the use of n-dimensional cuboids (n = number of axes) within a font’s designspace. These cuboids appear in:

  • Feature Variations
  • gvar tuples
  • STAT

Apart from Feature Variations, the structures also nominate a single point within the cuboid with special properties: maximum effect (gvar) and nominal value (STAT). Now, STAT’s cuboids are not as flexible as Feature Variations and gvar cuboids: the lack of ranges in Format 4 mean STAT cuboids are defined with Format 2, thus are effectively the full designspace truncated on one axis at (in general) both ends. Yet it seems wrong to have a STAT spec that is limited in its cuboids, compared to gvar and FeatureVariations. Why allow a glyph to switch to another shape entirely in freely defined designspace zones (Feature Variations), but not allow a glyph to take an arbitrary name in similarly defined zones?

Recall that Format 4 is already a full superset of Format 1. It doesn’t take much to extend it to become a full superset of Formats 2 and 3 as well.

I therefore propose, as a STAT minorVersion dot release, two new flag bits are defined for Format 4 axisValueTables:

0x0004 AXIS_VALUE_RANGES
0x0008 AXIS_VALUE_LINKED

When flag bit 0x0004 is set to 1, the axisValue records a set of axis ranges in each axis that defines where it takes effect, as well as a set of axis locations. Two new arrays, minValues[axisCount] and maxValues[axisCount] (both Fixed format), are appended to the record immediately after the axisValues[axisCount], which is retained. A participating axis that is intended for an axis location, rather than an axis range, must record minValue = maxValue = axisValue.

When flag bit 0x0008 is set to 1, a linkedValue (Fixed format) is appended to the record.

Given that style linking is about to be defined as point-to-point, there seems little purpose in specifying the format for when both AXIS_VALUE_RANGES and AXIS_VALUE_LINKED, but should that happen we might as well say the linkedValue is after the minValues and maxValues arrays.

With these modest changes, Format 4 is capable of recording anything possible with Formats 1, 2 or 3, including the combination of Formats 2 and 3.

Based on how the axisValueTable offsets are defined I believe existing implementations are safe with this change. They will simply use the axis locations rather than the axis ranges, and will ignore any linked value.

@reli-msft
Copy link

Should we create a format 5 table for maximum compatibility?

@Lorp
Copy link
Author

Lorp commented Sep 18, 2020

Maybe that makes sense. This proposal is about making Format 4 “how it should have been from the start”. If it is not useful for existing implementations to parse the point (non-range, non-link) values from the revised Format 4, then indeed a new format should be proposed. Is there something else you’d like STAT to do?

@simoncozens
Copy link

simoncozens commented Sep 23, 2020

If you're going to create a new format to fix up an old one, please deprecate the old one at least for font producers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants