Is it OK to ignore multi-axis fallback names? Or should them be also documented in the GFAxisRegistry? #3129
-
|
According to the OpenType spec, the STAT table can have Format 4 axis value tables which serve the purpose of giving a name to a combination of coordinates in some of the font variation axes. Here's an example of a font that has format-4 tables:
I'd be glad to hear from anyone who's got an opinion on this, of course. But I'm specially interested in hearing from @vv-monsalve, @davelab6, @RosaWagner, @m4rc1e or anyone else involved in building the GF Axis Registry. Note:This is related to the following recent bugfix:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Currently, the GF Axis Registry doesn't define any format 4 axis values. We only define axis values for individual axes only (formats 1,2,3). Perhaps in the future we may find certain axis combinations work well together and only then will we require format 4. I reckon we'll discover these combinations in families with tonnes of axes made by the likes of Type Network. Imo, skipping format 4 axis values for the time being is fine. |
Beta Was this translation helpful? Give feedback.
-
|
Lexend could need it and Commissioner would have had needed it too though |
Beta Was this translation helpful? Give feedback.
Currently, the GF Axis Registry doesn't define any format 4 axis values. We only define axis values for individual axes only (formats 1,2,3).
Perhaps in the future we may find certain axis combinations work well together and only then will we require format 4. I reckon we'll discover these combinations in families with tonnes of axes made by the likes of Type Network.
Imo, skipping format 4 axis values for the time being is fine.