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

Most upvoted comments

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