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
Since #977, glyphsLib creates <variable-font> elements in a DesignSpace v5 document, for each Variable Font Settings (special "instance" of type variable). It sets the name attribute to whatever the instance.name was. This normally only contains the style name of an exported (static or variable) font and is used by Glyphs.app for naming the exported fonts by concatenating to the font's family name, and also appending a "VF" suffix at the end of the file name (see https://docu.glyphsapp.com/#GSInstance.name).
fontmake uses the the <variable-font> name attribute as is for naming the output path (unless the "filename" attribute is also set which takes priority, this corresponds to the fileName custom parameter in Glyphs.app, which we do support already).
Thus fontmake won't prepend the family name to it, but will treat it as a full descriptive name of that variable font and simply add the file extension: e.g. you get things like "Regular.ttf" for a Variable Font Setting where the default "Regular" name that it gets when first created has not been modified.
Previously when these Variable Font Settings were ignored and not exported into the designspace, fontmake would make up the VF filename by using the designspace's filename (which glyphsLib sets to the font family name) plus the file extension suffix: so for the test font in glyphsLib/tests/data/VariableInstance.glyph, fontmake would name the output path of the VF as "Cairo-VF.ttf" which is arguably more specific and correct than "Regular.ttf" or "Variable.ttf".
I think here it is glyphsLib which has to adapt to the existing conventions whereby a DSv5 variable-font name contains not just the style name but a full name, also stripped of whitespaces in most examples that I have seen e.g. in the designspaceLib test suite; so instead of merely passing on the Variable Font Setting's Name field and set it as the variable-font's name attribute as is, it should concatenate it to font's family name and strip spaces: e.g. in the test example above, instead of <variable-font name="Variable"/> it will set it to <variable-font name="CairoVariable"/>, and then fontmake will use it for the output filename "CairoVariable.ttf".
The text was updated successfully, but these errors were encountered:
May be we can use here whatever algorithm GlyphsApp uses to construct VF file name and set the fileName to it if it is not set, and leave the <variable-font> name as it is now.
Since #977, glyphsLib creates
<variable-font>
elements in a DesignSpace v5 document, for each Variable Font Settings (special "instance" of type variable). It sets thename
attribute to whatever the instance.name was. This normally only contains the style name of an exported (static or variable) font and is used by Glyphs.app for naming the exported fonts by concatenating to the font's family name, and also appending a "VF" suffix at the end of the file name (see https://docu.glyphsapp.com/#GSInstance.name).fontmake uses the the
<variable-font>
name attribute as is for naming the output path (unless the"filename"
attribute is also set which takes priority, this corresponds to thefileName
custom parameter in Glyphs.app, which we do support already).Thus fontmake won't prepend the family name to it, but will treat it as a full descriptive name of that variable font and simply add the file extension: e.g. you get things like "Regular.ttf" for a Variable Font Setting where the default "Regular" name that it gets when first created has not been modified.
Previously when these Variable Font Settings were ignored and not exported into the designspace, fontmake would make up the VF filename by using the designspace's filename (which glyphsLib sets to the font family name) plus the file extension suffix: so for the test font in glyphsLib/tests/data/VariableInstance.glyph, fontmake would name the output path of the VF as "Cairo-VF.ttf" which is arguably more specific and correct than "Regular.ttf" or "Variable.ttf".
I think here it is glyphsLib which has to adapt to the existing conventions whereby a DSv5 variable-font name contains not just the style name but a full name, also stripped of whitespaces in most examples that I have seen e.g. in the designspaceLib test suite; so instead of merely passing on the Variable Font Setting's Name field and set it as the variable-font's name attribute as is, it should concatenate it to font's family name and strip spaces: e.g. in the test example above, instead of
<variable-font name="Variable"/>
it will set it to<variable-font name="CairoVariable"/>
, and then fontmake will use it for the output filename "CairoVariable.ttf".The text was updated successfully, but these errors were encountered: