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
I’m building some fonts that require abbreviated names in Name 1, in order to render Thai glyphs in MS Word on Windows (which fails if Name 1 exceeds a length limit).
However, I’m having unexpected trouble making this happen.
Glyphs has a naming parameter for "Full Names," and its description seems to indicate that it should set Name 4:
UI Text of the Full Names parameter (Click to expand)
postscriptFullNames
Name to be used for the FullName field in CFF table as well as for name table ID 4 (full font name). This is the complete name of the font as it is supposed to appear to the user, and is thus allowed to contain spaces, e.g., ‘My Font Bold Condensed Italic’. Do not confuse with postscriptFontName (see above).
Some systems match the family name ‘against the FullName for sorting into family groups.’ Therefore, the family name ‘must match the corresponding portion of the FullName, and be suitable for display in font menus. All fonts that are stylistic variations of a unified design should share the same FamilyName. […] The FullName begins with a copy of the FamilyName and is completed by adding style attributes — generally in this sequence: weight, width, slope, optical size’ (Adobe Technote #5088). The full name ‘would typically be a combination of name IDs 16 and 17’ (typographic family and subfamily names), ‘without needing any additional qualifications regarding “Regular”’. OpenType spec: name ID 4
This seems pretty clear-cut, and other names are settable from this area, such as the Style Map Family Name (Name 1).
If it’s important context, the sources I received (made in an earlier version of Glyphs) have the field filled as "Full Name", whereas the current version of Glyphs (3.2.2) only offers Full Names. However, FontMake wasn’t building Name 4 from the previous version of this field, either.
Or, am I perhaps missing something?
One more note: I’m not entirely sure if this is the best place for this issue. Initially, I thought it might be in glyphsLib, but I see that glyphs2ufo does carry the Full Name value into the instance lib of the designspace, under com.schriftgestaltung.customParameters > com.schriftgestaltung.properties > postscriptFullName. So, maybe it’s a ufo2ft issue, or something else? Happy to move this issue if it’s better to file elsewhere!
Thanks for your time!
The text was updated successfully, but these errors were encountered:
I’m building some fonts that require abbreviated names in Name 1, in order to render Thai glyphs in MS Word on Windows (which fails if Name 1 exceeds a length limit).
However, FontBakery also tells me that the Full Name (Name 4) must start with the Style Map Family Name (Name 1), in com.google.fonts/check/name/match_familyname_fullfont.
However, I’m having unexpected trouble making this happen.
Glyphs has a naming parameter for "Full Names," and its description seems to indicate that it should set Name 4:
UI Text of the Full Names parameter (Click to expand)
This seems pretty clear-cut, and other names are settable from this area, such as the Style Map Family Name (Name 1).
If it’s important context, the sources I received (made in an earlier version of Glyphs) have the field filled as "Full Name", whereas the current version of Glyphs (3.2.2) only offers Full Names. However, FontMake wasn’t building Name 4 from the previous version of this field, either.
Or, am I perhaps missing something?
One more note: I’m not entirely sure if this is the best place for this issue. Initially, I thought it might be in glyphsLib, but I see that glyphs2ufo does carry the Full Name value into the instance lib of the designspace, under com.schriftgestaltung.customParameters > com.schriftgestaltung.properties > postscriptFullName. So, maybe it’s a ufo2ft issue, or something else? Happy to move this issue if it’s better to file elsewhere!
Thanks for your time!
The text was updated successfully, but these errors were encountered: