Common scenario

public.skipExportGlyphs gets set in UFOs, with the intention and expectation that these glyphs won’t be built into output fonts. This is behavior that is useful and common in font editors like RoboFont and GlyphsApp. I use it for two main things:

1. Marking glyphs that are only used as components, such as the /caron.alt, but which don’t have Unicodes to make them accesible. I want these components to decompose on build, and for the parent glyph to be removed.
2. Marking alternate glyphs that were made as "draft" or experimental designs, but not intended for inclusion in output fonts. But, I want to leave them in the source, in case I return to that idea later.

When building directly from a UFO, public.skipExportGlyphs works exactly as expected – those glyphs don’t appear in the output font.

Problem:

As stated, the output from a single UFO is as expected. However, when building from a designspace – even if this lib item is set in all UFO sources – this lib key is completely disregarded. It only works if the lib key is set within the designspace itself. I would argue this is highly unintuitive.

Yet, this counter-intuitive requirement is very explicitly clearly specified in the DS spec:

If the lib key is empty or not present in the Designspace, all glyphs should be exported, regardless of what the same lib key in any of the UFOs says.

This requirement was put in place for good reasons – namely, trying to avoid complexity and out-of-sync data, but I’m hoping that this is something we might consider again.

Proposal

• If a designspace does have its own lib item public.skipExportGlyphs, this is used as the single record to be used.
• If a designspace does not have its own lib item public.skipExportGlyphs, it would refer to the origin/default source UFO. For simplicity’s sake, this should be the case whether the fonts being exported are variable or static interpolations.

I’ll make a PR for this, next.

Reasoning

If I had to give a reason of the logic of why it is unintuitive, I would argue that (almost) nothing else about glyph-level data is set up in a designspace. We don’t set up glyph names, or outlines, or spacing, or kerning, or kern groups, or anchors, etc etc, in the designspace. That data is all set up along with the glyphs themselves, within the source documents.

This is discussed further in a ufo2ft issue: googlefonts/ufo2ft#854, with several good points made. A couple of highlights:

• @lianghai pointed out that, despite the good intentions here of avoid confusion when things get out of sync between UFOs, “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 pointed out that this couldn’t work on a per-layer level, e.g. excluding certain UFOs/layers from interpolation, unless this lib key were introduced into layers. This is a response to an earlier idea I tossed out, that perhaps this lib key could exclude specific sources from the interpolation of specified glyphs (while leaving those glyphs in place, from other sources).

Okay, I’m submitting this issue to organize and record my thoughts, but will now go and try to make a more specific PR for the actual change.