MPEGGroup / OpenFontFormat

Official MPEG repository to discuss issues on Open Font Format (ISO/IEC 14496-22)
31 stars 6 forks source link

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

Open Lorp opened 3 years ago

Lorp commented 3 years ago

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:

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 commented 3 years ago

Should we create a format 5 table for maximum compatibility?

Lorp commented 3 years ago

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 commented 3 years ago

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.