Will it be simpler to actually specify that the inheritance logic should be the same for public.skipExportGlyphs and public.fontInfo?

However, I think this arrangement probably makes sense, assuming others agree that an empty lib key should be treated as significant data.

Yes, for an optional key in a dictionary-like data structure, the absence of this key should be analyzed as having a different meaning from the value being falsy ([] in this case).

Will it be simpler to actually specify that the inheritance logic should be the same for public.skipExportGlyphs and public.fontInfo?

that's actually a good idea. E.g. one may want to define different skipExportGlyphs for different VF or instance targets.

Will it be simpler to actually specify that the inheritance logic should be the same for public.skipExportGlyphs and public.fontInfo?

Is there specific language you might suggest adding/adjusting in this PR?

I’m not super familiar with the inheritance logic of public.fontInfo, offhand. I suppose you mean that it treats some fields as applying to everything, but lets other fields apply on to individual instances? Is there a record of what goes where? There must be...

E.g. one may want to define different skipExportGlyphs for different VF or instance targets.

YES, this would be handy. It’s pretty frequent that static exports end up with unreachable glyphs that are there simply because they are required for the variable font’s font variations glyph substitution, such as an alt /Q or barless /dollar.

Would this automatically be covered by specifying that “the inheritance logic should be the same for public.skipExportGlyphs and public.fontInfo”?

that's actually a good idea. E.g. one may want to define different skipExportGlyphs for different VF or instance targets.

To be clear, my intention is more about reducing special cases in the spec rather than expanding the functionality.

Is there specific language you might suggest adding/adjusting in this PR?

I’m still pondering over this idea. I’m not familiar with this spec either (I didn’t even know about its existence before, as I thought everything was in the source code…), but will try drafting something later.

I suppose you mean that it treats some fields as applying to everything, but lets other fields apply on to individual instances?

Oh I meant the inheritance chain specified for public.fontInfo, for example:

InstanceDescriptor.lib["public.fontInfo"]["familyName"]  # Only applicable to `InstanceDescriptor` and `VariableFontDescriptor`
InstanceDescriptor.familyName  # Only applicable to `InstanceDescriptor`
DesignSpaceDocument.lib["public.fontInfo"]["familyName"]
DesignSpaceDocument.default.font.info.familyName

Conceptually I guess public.skipExportGlyphs should actually be treated as one of the font info keys instead of the whole public.fontInfo, as each key of the latter has its value inherited separately.

Oh I meant the inheritance chain specified for public.fontInfo, for example:

I wasn’t familiar with / hadn’t remembered this explicit hierarchy, but that is so helpful to see again. Thanks!

I wonder if we might specify something like...

With a hierarchy similar to public.fontInfo, skipExportGlyphs should be inherited using the following order, in order of descending priority::

1. The public.skipExportGlyphs key in the <lib> element of the <variable-font> or <instance> elements.

2. The public.skipExportGlyphs key found in the <lib> element of the designspace document’s root.

3 The lib.plist in the UFO source at the origin of the interpolation space.

Would item 1 be a reasonable way to specify functionality to “define different skipExportGlyphs for different VF or instance targets”? Is this something we can reasonably add to the spec?

@arrowtype yes, sounds good to me

Okay, added! The previous information still seemed to provide useful detail, but felt a bit hard to easily read, especially when placed before the hierarchy. So, I moved the previous information to bullets that follow.

It’s possible that this now provides more information than needed, but I do think it helps clarify potential areas of uncertainty.

@anthrotype what are your thoughts on this?

(I’ve just rebased this branch to update it.)

@lianghai Thanks so much for your edits!

consider adding cross-references ... from all the affected .lib’s

Seems like a good idea. I’ll have to come back to this aspect, hopefully over the weekend.

@arrowtype would you like to also work on updating ufo2ft to match this? 😛

@lianghai I’ve implemented you specific example, but I’m not familiar enough with this library’s structure to know where all affected libs would be, and why it might make sense to link from InstanceDescriptor.familyName and .styleName docstrings. (I guess for those, it’s because public.fontInfo can override them?) How might I best determine a full list of docstrings which should have the cross reference?

@anthrotype I would like to help further if I can, but I’d have to ask how this might fit into the priorities at The Type Founders. Also, I probably wouldn’t be particularly efficient at making such changes. Of course, I also understand if this isn’t a high priority on anyone’s docket, and I very much appreciate the expertise being lent in this PR, even just as a way I’m learning more about the designspaceLib.

@lianghai I’ve implemented you specific example, but I’m not familiar enough with this library’s structure to know where all affected libs would be, …

How might I best determine a full list of docstrings which should have the cross reference?

Uh I thought the spec itself you’re editing now is supposed to explain which exactly attributes across the DesignSpaceDoc hierarchy participate in this inheritance logic? Then I expect all participating Python attributes need to also point back to the spec, otherwise whoever using the Python API doesn’t know how to interpret the attributes properly. I, for one, didn’t realize there was explicitly documented inheritance logic that has no reference in designspaceLib/init.py‎.

But I’m quite confused by how https://fonttools.readthedocs.io/en/latest/designspaceLib/ is organized, with the Python API and XML API documented separately… @anthrotype, who’s supposed to be the owner of this chapter of documentation https://fonttools.readthedocs.io/en/latest/designspaceLib/? We need the owner to make a decision about how to document such info properly.

…, and why it might make sense to link from InstanceDescriptor.familyName and .styleName docstrings. (I guess for those, it’s because public.fontInfo can override them?)

If docstrings of .lib attributes should be updated to cross-reference to the spec, InstanceDescriptor.familyName, etc, should too, because otherwise it’s unclear how it affects those font info values. The key is not the concept of a lib, but how font info values should be interpreted given various values in the libs and other attributes.

Now I’m thinking such an inheritance logic should actually captured in a function…

Btw, if you add me as a collaborator, I can try drafting something.

@lianghai Thanks, sounds good! Done: https://github.com/arrowtype/fonttools/invitations