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
Set stylename, postscriptfontname, and stylemapfamilyname DS attributes based on Localized Family Names and Localized Style Names Export properties
#1028
Open
arrowtype opened this issue
Aug 29, 2024
· 0 comments
I’m hoping to use FontMake to build from a single Glyphs source to multiple subfamilies in a superfamily, as is a typical need for many retail foundries. For example, it should be possible to create a Glyphs source containing Width and Weight axes, then build to families like Familyname Condensed and Familyname Wide, each with weights inside such as Regular and Bold, and also use that Glyphs source to build a variable font with all styles correctly labeled in the fvar table. This is currently possible to build directly from Glyphs, but it would be ideal to be able to build with FontMake.
I’ve investigated what is blocking this, and I’ve narrowed it down to two main factors that hopefully come close to clarifying the issue and possible solution. I have documented my testing in the repo arrowtype/test-fontmake-glyphs-build-naming.
If these two things happened when going from Glyphs to UFO/designspace, I believe build outcome described above would be possible:
Set stylename, postscriptfontname, and stylemapfamilyname attributes based on Localized Family Names and Localized Style Names Export properties. It seems that Localized Family Names is already being used, to an extent, which hopefully gives a head start on this set of improvements. This is the primary purpose of filing this issue.
It seems that the second item would require collaboration/leadership from the Glyphs team.
The first item is also essential, at least with the current way FontMake builds from a v5 Designspace.
I’m not sure I have the knowledge to implement either of the above changes, but I’ve done my best to test and document this thoroughly, to hopefully provide a first step in the effort. If anyone has any insight into what area of the library might have to change to implement change 1, I’d love for any insights to be shared in this issue!
The text was updated successfully, but these errors were encountered:
I’m hoping to use FontMake to build from a single Glyphs source to multiple subfamilies in a superfamily, as is a typical need for many retail foundries. For example, it should be possible to create a Glyphs source containing Width and Weight axes, then build to families like
Familyname Condensed
andFamilyname Wide
, each with weights inside such asRegular
andBold
, and also use that Glyphs source to build a variable font with all styles correctly labeled in thefvar
table. This is currently possible to build directly from Glyphs, but it would be ideal to be able to build with FontMake.I’ve investigated what is blocking this, and I’ve narrowed it down to two main factors that hopefully come close to clarifying the issue and possible solution. I have documented my testing in the repo arrowtype/test-fontmake-glyphs-build-naming.
If these two things happened when going from Glyphs to UFO/designspace, I believe build outcome described above would be possible:
stylename
,postscriptfontname
, andstylemapfamilyname
attributes based onLocalized Family Names
andLocalized Style Names
Export properties. It seems thatLocalized Family Names
is already being used, to an extent, which hopefully gives a head start on this set of improvements. This is the primary purpose of filing this issue.label
elements for axes in a designspace. This is covered by Write designspace v5 STAT labels #876.It seems that the second item would require collaboration/leadership from the Glyphs team.
The first item is also essential, at least with the current way FontMake builds from a v5 Designspace.
I’m not sure I have the knowledge to implement either of the above changes, but I’ve done my best to test and document this thoroughly, to hopefully provide a first step in the effort. If anyone has any insight into what area of the library might have to change to implement change 1, I’d love for any insights to be shared in this issue!
The text was updated successfully, but these errors were encountered: