Write designspace v5 STAT labels
kontur opened this issue · 9 comments
It does not seem that glyphsLib writes any kind of STAT table information to extracted designspaces (see googlefonts/ufo2ft#723). With support for designspace v5 <labels> being available in fonttools (docs), glyphsLib should probably write, at the very least, labels for axes and defined instances.
labels for axes and defined instances
the problem is figuring how exactly where/how these are specified in the .glyphs source
https://glyphsapp.com/learn/creating-a-variable-font which contains some info in the "Not really optional: STAT table" paragraph
Usually, Glyphs takes care of this pretty smartly by analyzing the names of your predefined instances. If however, you find that in the STAT table entries, the display strings are not properly stored in the file, you can take control with these two parameters in File > Font Info > Exports:
The automatic part (my emphasis) should be a fairly low hanging fruit after some crosschecking with fonts exported with Glyphs defaults.
Style Name as STAT entry: Takes the instance style name as combinable display string for an axis range. As value, use the four-letter axis tag to which the display string applies. Use this only in instances that are non-normal on one axis and normal on all others. That is because the normal attributes have elidable names and do not appear in the style name (e.g., ‘Semibold’ or ‘Condensed’). Example: In the Light instance, use this parameter with the value wght, because Light is a value on the weight axis.
Elidable STAT Axis Value Name: Declares the instance style name as elidable for the axis specified in the parameter value. As value, use the four-letter tag of the respective axis. Typically, you will add this parameter in the regular style, and you will add one for each axis for which the name is an elidable display string. Example: An instance called Regular has two Elidable… parameters, one with wght and one with wdth as parameter values.
These are custom parameters on the exports, literally named Style Name as STAT entry and Elidable STAT Axis Value Name.
should be a fairly low hanging fruit
yeah, that's what most of us think before setting out to touch glyphsLib code 😅
(especially when so-called "smart" features are involved)
@schriftgestalt could you provide us with an abstract description of the STAT name generation algorithm as used in GlyphsApp? Or a sample file you consider following naming conventions such as GlyphsApp ideally expects to find them?
The algorithm was greatly improved in version 3.2.
The basic idea is to go through all instances and checks if any full instance name is part of another instances name. Each time it finds a match, that removed part is a particle for the STAT table. You have to be careful with the order of the names when you go through them. I can get into more detail if needed. Who will work on this. Maybe we can have a call to discuss this?
The new algorithm doesn't need those parameters for most fonts any more.
thanks Georg for the offer to help, but I can't commit to work on this right now. Maybe @kontur would be interested to take this on?
Yes, but can't commit time to this, not really before April/May.
If we assume a glyphs file with three axes (weight with Regular, Medium and Bold, width with Condensed, Normal and Expanded, and optical size with Caption, Normal and Display) and matching italics, and "Normal" is assumed elidable in all of those, how would the algorithm work on the matrix of those style names?
Something along the lines of:
- Split all styles' name fragments
- Find names which are exact matches minus one fragment (find an elided term)
- Find names which differ by one fragment (find terms of the same axis)
How do you determine the axis order you mention should be paid attention to? Do you take the style linking checkbox into consideration?
Split all styles' name fragments
No. There might be particles that include spaces.
When you find some time, please call me to discuss this.