madig
commented
1 week ago IIRC, this was done because we (or just I?) was thinking in terms of ufo2ft entry points, i.e. which function are you using to compile a font. The variable fonts functions would only consult the DS, the static fonts functions would only consult the UFO in question. I know from experience that data in sources gets out of sync fast when humans are involved, so we settled on a hard and fast rule. Your proposal might work. @anthrotype ?
CC @madig. First of all, I really appreciate all your work here, and this question is probably like 5 years late, lol. I hope this doesn’t come off as overly whiny – Ultimately, I’m hoping I might learn something from asking about something that was an unexpected UX thing for me.
It looks like, as of https://github.com/googlefonts/ufo2ft/pull/318,
public.skipExportGlyphswas added as a supported option for designspace documents, but also effectively removed as an option in UFO libs. From that PR:This is confusing to me... My expectation is that the lib key could be used as a convenience in a designspace, so that it could be set in one location by e.g. a developer building a font family from that designspace. RoboFont, for example, has a checkbox marked "Export," similar to Glyphs. I assume that, when this is unchecked in all UFOs (or in the main UFO of a designspace), that should skip the glyph in the export. But, that doesn’t happen when building from a designspace.
I don’t quite understand why the lib key would be totally ignored in UFO files. It is easy to run into the case where, as a robofont user, one might set glyphs to "skip export." Each UFO will generate as expected without those glyphs, as one would expect. However, if you then go to build a full variable font, those glyphs suddenly reappear. Here’s an issue where I initially ran into this confusion.
It seems that the main argument for this behavior was in avoiding conflicting sources of truth, but it seems like it could perhaps work like this:
public.skipExportGlyphslib key does exist in a designspace, that (and only that) should be respectedpublic.skipExportGlyphsdoes not exist in a designspace, but does exist in UFOs, the item in the UFO marked<info copy="1"/>should be respectedI’ve read through https://github.com/unified-font-object/ufo-spec/issues/68 to try to understand why the key doesn’t act as I expect, but I still don’t understand what benefit it provides to ignore the key in UFOs, even when it is unspecified in the designspace...
Is there some reason I am failing to see why the absence of the key in a designspace is treated as the absence of the key altogether?
If there isn’t a benefit to the exact current implementation, is there any hope of adjusting it now?
Thanks so much if anyone can help me understand this better!