Open Lorp opened 3 years ago
Should we create a format 5 table for maximum compatibility?
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?
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.
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:
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]
andmaxValues[axisCount]
(bothFixed
format), are appended to the record immediately after theaxisValues[axisCount]
, which is retained. A participating axis that is intended for an axis location, rather than an axis range, must recordminValue = 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
andAXIS_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.