ValueError: The features already contain a table GDEF {...} statement

[fabiangreffrath]

Hi there,

fontmake currently fails to build the Angular variant of the comic-sans font from the glyphs-format into OTF files.

The font can be found here:
https://github.com/crozynski/comicneue

The command I use to compile the font is:

fontmake -o otf -g Sources/Glyphs/Files-from-UFO/Angular-from-UFO/ComicNeue-Angular-Regular.glyphs 

However, it fails with the following error message:

ValueError: The features already contain a `table GDEF {...}` statement. Either delete it or set generate_GDEF to False.

I mean, if the GDEF table is already there, fine, why not keep it? So, how do I set generate_GDEF to False or, alternatively, how do I tell fontmake to delete and re-generate the table and why isn't this done by default?

This is on Debian testing/unstable with the following packages installed:

fontmake 2.1.4-1
python3-cu2qu 1.6.7-1+b2
python3-fontmath 0.6.0-1
python3-fonttools 4.16.1-1
python3-glyphslib 5.2.0+ds1-1
python3-ufo2ft 2.14.1-1
python3-ufolib2 0.8.0+dfsg1-1
ttfautohint 1.8.3-2+b1

[anthrotype]

The expectation in fontmake is that .glyphs sources do not contain a table GDEF {...} definition in the features text, because that is usually auto-generated on export based on other metadata by Glyphs.app, or by glyphsLib.
The glyphs2ufo script (part of glyphsLib) has an option to enable/disable this auto-generation of GDEF, but we didn't bother adding that option to fontmake as well because we didn't think the use case was frequent enough.
You need to verify that this GDEF table is not human-written, and if so you can delete it in the sources and let fontmake/glyphsLib recreate it for you.
If it was deliberately written by a human and would like to keep intact, then you could use the glyphs2ufo script (part of glyphsLib) to first export .glyphs sources into a designspace+set of master UFOs (do not pass --generate-GDEF option, I belive it's disabled by default in glyphs2ufo), then proceed to build the fonts from the designspace just exported.
If somebody wants to help adding that --no-generate-GDEF flag to fontmake (and have fontmake pass it down to the glyphsLib function which builds the designspace + UFOs), you're welcome to send a PR.

[fabiangreffrath]

I am afraid I am really not familiar enough with the code to provide a PR.

However, if the presence of a GDEF table in a glyphs source file is unexpected, it might indeed be better to remove it (I know that it has been auto-generated). How is the best way to do this? Search for regex "table.*GDEF" and delete the entire line?

[madig]

> glyphs2ufo ComicNeue-Angular-Regular.glyphs
> fontmake -u ComicNeueAngular-Regular.ufo -o otf

[fabiangreffrath]

Thank you @madig !

So, there is currently no way around explicitly creating intermediate UFO files?

[madig]

I haven't thought about it, but probably not.

[moyogo]

@fabiangreffrath It seems to me ComicNeueAngular shouldn’t have a GDEF definition among other things. The kern feature lookups probably probably shouldn’t be there either as there is kerning data that they may be out of sync with.

[anthrotype]

I suspect the .glyphs source might have been imported (either directly in Glyphs.app or using glyphsLib) from a designspace+master UFOs that was in turn generated via fontmake/glyphsLib (with generated_GDEF=True). Hence the reason it contains a GDEF definition in its features. @fabiangreffrath is that the case?

[anthrotype]

@moyogo do you know if there's ever a need to write one's own GDEF definition in a .glyphs source file, instead of letting Glyphs.app/glyphsLib generate one for you? Do people actually want to be able to do that?

[moyogo]

Within Glyphs.app it makes more sense to use a custom GlyphsData.xml or change the glyph’s category.

[punchcutter]

I usually just update the glyph categories to make sure they are what I want because both Glyphs and fontmake will then use those.