Why are public.skipExportGlyphs lib keys ignored in UFOs, when compiling from Designspace?

[arrowtype]

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 #318, public.skipExportGlyphs was added as a supported option for designspace documents, but also effectively removed as an option in UFO libs. From that PR:

If the Designspace does not have such a key, all glyphs are exported (the keys in the UFOs are ignored).

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:

• if the public.skipExportGlyphs lib key does exist in a designspace, that (and only that) should be respected
• if the public.skipExportGlyphs does not exist in a designspace, but does exist in UFOs, the item in the UFO marked <info copy="1"/> should be respected

I’ve read through unified-font-object/ufo-spec#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!

[madig]

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 ?

[arrowtype]

Thanks for the thoughtful response!

I do love that it’s possible to add the "skip export" list within a designspace file, but yeah, I would also find it handy if the settings in individual UFOs could be reflected in the build, because these are easier to mark on-the-fly, when drawing in RoboFont.

You have a good point about UFO sources easily getting out of sync. That almost makes me think that, perhaps, the variable font build should skip export on glyphs marked as "skip export" in any of the source UFOs. Presumably, if a glyph is experimental or problematic in one source, it won’t be desirable to include in the variable font, in any styles/areas.

In the immediate term, I might look again whether there is a RoboFont extension to better sync fonts within a designspace. If there were something analogous to the GlyphsApp "Font Info" panel, but for a designspace, that could potentially help here.

Still interested in whether @anthrotype has any thoughts here.

[madig]

Marking individual glyphs to not participate in interpolation sounds interesting, though I'm not sure varLib and the instantiator deal with that properly (what if the default source is marked not-export?). The original use-case was to exclude whole Glyphs.app glyphs (as in UFO glyphs from all UFO layers), not drop individual masters. That's actually also why the code only looks at DS or UFO, but not both.

[arrowtype]

Sorry, I’m not suggesting marking individual glyphs to not participate in interpolation. Rather, I’m suggesting that, if a glyph is marked as non-exporting in one UFO, the user probably doesn’t want that glyph to be in the final font, at all.

A common reason I mark a glyph as non-exporting is that, during the design process, I duplicate some glyphs to quickly test ideas. So, I end up with glyphs like /A.001, /A.002, etc. This will vary from master to master. I don’t actually want these in the final font, so I mark them as non-exporting. However, I also don’t want to have to separately go list all such glyphs in a designspace.

[anthrotype]

the variable font build should skip export on glyphs marked as "skip export" in any of the source UFOs

yeah, we could do that if it makes it easier for RoboFont users.
Of course, only when the same key is absent from the DS lib, because the latter should logically take precedence if present.

Note the DS spec would need changing as well here:
https://fonttools.readthedocs.io/en/latest/designspaceLib/index.html#public-skipexportglyphs

[lianghai]

Many fields in the UFO fontinfo that don’t make sense when they go out of sync between UFOs, yet the DS’s public.fontInfo has an inheritance logic. Ignoring public.skipExportGlyphs on UFOs introduces an unexpected and unnecessary inconsistency in how DS overrides UFO data.

[anthrotype]

yet the DS’s public.fontInfo has an inheritance logic.

fair point. But I wouldn't take the union of all the UFOs skipExportGlyphs; just the origin/default UFO source's, that's the skeleton which the VF is built upon.
Marking glyphs as non-export in non-default sources could have the effect of having them "not participate" for that glyph, but maybe that goes too far and is not the original intent of this lib key.
This setting is global for the entire VF, hence why the DS.lib takes priority. Allowing it to set on the default UFO lib would only be a convenience for RF users who already have a convenient UI for that.
Also note that the lib key is defined and read only from the UFO lib.plist, which means it applies to all of a UFO's layers; not currently on the layerinfo.plist's lib element, which applies per-layer.
In order to propertly support disabling individual glyphs from specific layers it would have to be defined at the layer level, given that DS (glyph) sources can be sourced from sparse UFO layers as well as whole UFOs (i.e. their default layer).

[anthrotype]

if you can PR a change to the DS spec, we can then work on updating ufo2ft to match the desired behavior.
fontc similarly only supports this key at the DS.lib level, so it would need an equivalent change.

[arrowtype]

I wouldn't take the union of all the UFOs skipExportGlyphs; just the origin/default UFO source's, that's the skeleton which the VF is built upon

This seems reasonable to me, for what it’s worth!