inclusion of empty glyphs (.null, space, CR)

[cmyr]

Investigating another diff, this time for Afacad, and noticing that our glyph orders differ significantly, and this is due to the fact that fonttools is assigning glyph ids to a number of 'empty' glyphs like .null, CR, etc.

I suspect someone here will have more insight into this than I do, so opening an issue before I dig too deeply.

looks like there was some loosely related discussion in #185?

[anthrotype]

as far as I am aware, fontmake (or ufo2ft rather) only adds the .notdef glyph. The .null and CR are legacy glyphs recommended in the old TrueType spec but they are no longer required nowadays. If the source font contains those, of couse we build them, otherwise we don't.

looks like there was some loosely related discussion in #185?

hm I don't think these are related.

[anthrotype]

I see what's going on. the source fontains a glyphOrder custom parameter which is marked as disabled:

fontc is duly ignoring the parameter as if it wasn't there. However fontmake, or actually glyphsLib is ignoring the disabled flag and applying the custom glyphOrder.

I searched glyphsLib issue tracker and it appears to be a long-standing issue:
googlefonts/glyphsLib#809
googlefonts/glyphsLib#905

Basically glyphsLib (hence fontmake) doesn't bother checking the disabled flag most of the time, which is of course wrong.
So this an instance where fontc is correct and fontmake has a bug.

Ideally we'd fix fontmake in this case if it's not too much trouble. But as always, making even relatively small changes to glyphsLib is always a risk of getting sucked in deep rabbit holes..

[anthrotype]

with googlefonts/glyphsLib#1036 applied, the GlyphOrder of Afacad is now reported as identical b/w fontc and fontmake (glyphOrder param gets ignored by both)

[cmyr]

okay let's close this, since it looks like our behaviour is correct, and we'll get a match when that patch is merged.