You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The app will be improved by adding an avar v1 layer, so that an entire avar table can be created with both avar1 and avar2 sections active. This will be particularly useful for fonts where the designspace document uses designer units (e.g. Weight axis with values based on stem widths measured in font units) and its axes includes a <map> element.
The text was updated successfully, but these errors were encountered:
Note that when the avar1-based <map> elements for an axis map no more than min, default and max, then no avar1 data is necessary, since the relative placement of min, default and max is handled sufficiently by basic normalization math. However, the <map> element still serves as a mapping between designer calibration and OpenType calibration, allowing even avar2 mappings to be expressed in designer units rather than OpenType units.
@behdad please remind me if avar2 mappings can indeed be expressed in designer units, with the <map> mappings used to determine their values in the compiled font
@behdad please remind me if avar2 mappings can indeed be expressed in designer units, with the mappings used to determine their values in the compiled font
That's correct of the .designspace format, yes. The binary of course has no notion of designer units still.
The app will be improved by adding an avar v1 layer, so that an entire avar table can be created with both avar1 and avar2 sections active. This will be particularly useful for fonts where the designspace document uses designer units (e.g. Weight axis with values based on stem widths measured in font units) and its axes includes a <map> element.
The text was updated successfully, but these errors were encountered: