I’m working with some fonts that were produced in Glyphs app, and am finding glyphs made of composites and contours in a single glyph.
This is non-conformant to the OT specification, which I think calls for -1 to flag a glyph with composites, 0 for an empty glyph, and 1-… to indicate the number of contours in a glyph.
So I’m wondering if you app corrects this in font generation, and if so, how?
The design source should not be limited by the technical capabilities of one of the final output format. The components will be decomposed on export. And transformed components are decomposed, too (otherwise instructions are not working corrects; and you can disable this).
The tool is allowing glyphs to be constructed without consideration of the format’s inability to store them as the source was created, then bloats the file size to ‘correct‘ it, (for all formats, not any one), and then creates a font that does not match the source.
People using glyphs for variable fonts, where file size matters, might have to make another path. But I’m pretty sure Glyphs is smart enough to create composites in the output font, as well as destroy them as it does now, isn’t it?
The source can do so much more than the final format allows.
file size does matter for all web fonts.