ufo2ft: Font generation fails: Glyph names must not be longer than 63 characters
I’m working on an extensive commercial VF. After I’ve added bracket and brace layers to composite glyphs whose base glyphs show either interpolation or substitution variations, some of the glyph names are getting pretty wild. File is available on request.
I’ve already manually set shorter production names in the Glyphs source for all the critical glyphs, yet the font generator fails anyway.
Here’s proof of the production name making it into lib.plist
in the public.postscriptNames
list:
<key>lamThreedotsabove_alefHamzaabove-ar.fina.conn-mf-2.ss16.BRACKET.130</key>
<string>uni06B70623.fina.conn-mf-2.ss16.BRACKET.130</string>
(despite the production name not being read into the GSGlyph object, which I really can’t understand: https://github.com/googlefonts/glyphsLib/blob/57e66d21b71676a4e05b6ab02cb6204aad0ef81a/Lib/glyphsLib/classes.py#L3987)
So then the error message says:
ERROR:ufo2ft.featureCompiler:Compilation failed! Inspect temporary file: '/var/folders/hn/dpv0mmmn7jb_65xyqgr3ww280000gn/T/tmpgclw0pzh'
fontmake: Error: In 'sources/OodleSans.glyphs' -> 'master_ufo/OodleSans.designspace': Generating fonts from Designspace failed: <features>:2440:7100: Glyph names must not be longer than 63 characters: lamThreedotsabove_alefHamzaabove-ar.fina.conn-mf-2.ss16.BRACKET.130
In the referenced temporary file, the glyph name shows up as part of a kerning class definition.
I added the printing of the glyph name in the above printout myself. However, I’ve lost track of the open files in my editor and now I can’t even find the place anymore where the line is printed.
So it’s possible that the error is not in ufo2ft
, but as usual, I can’t really figure out the toolchain.
Where do I continue to look for the error? Where is the production name not getting used as it’s supposed to?
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 19 (9 by maintainers)
Commits related to this issue
- Increase glyphs name character limit to 127 As discussed here: https://github.com/googlefonts/ufo2ft/issues/588 — committed to eliheuer/fonttools by eliheuer 10 months ago
- feaLib: Drop glyph and class names length limit These were implemented to follow FEA spec, but makeotf does not seem to have a length limit on class names, and the glyph names limit (if it still has ... — committed to fonttools/fonttools by khaledhosny 5 months ago
- feaLib: Drop glyph and class names length limit These were implemented to follow FEA spec, but makeotf does not seem to have a name length limit any more (or it has a very large one, I tested a 600-c... — committed to fonttools/fonttools by khaledhosny 5 months ago
- feaLib: Drop glyph and class names length limit These were implemented to follow FEA spec, but makeotf does not seem to have a name length limit any more (or it has a very large one, I tested a 600-c... — committed to fonttools/fonttools by khaledhosny 5 months ago
I’d do away with the check, we are not working with fixed length char arrays in C or something, and should not be imposing arbitrary limits, and the glyph names we sea during feature file compilations might never make it to the final font.
@eliheuer try to temporarily use this fonttools branch where I disable the check: https://github.com/fonttools/fonttools/compare/feaLib-63-long-names?expand=1
can the font be compiled successfully then?
Another option we have is to ask the maintainers of the FEA spec to raise the limit from 63 to … 127? Apparently in 2016 the limit was already raised once from 31 to 63.
it’d still be nice to be able to workaround the 63-char limit, maybe keep this open once somebody finds the interest/time in making this work