[ufo] Merge libs from designspace and default master#1628
Conversation
This is a conservative merge; we only update dictionary objects, and we only add items from the child that are not present in the base. It is possible for there to be keys in the default master's lib that are not in the designspace lib, and which we want to have access to (the motivating example being the presence of the 'eraseOpenCorners' filter). In an earlier patch I had added special handling for the case where we were compiling a single ufo; this new approach lets us delete that special case. The decision to just look at the default master was arrived in conversation with cosimo. In general the keys that we care about are autogenerated by glyphsLib, and should be consistent between masters. We could try and verify that this is true but that feels like very low ROI at this point.
yes, currently glyphsLib stores its custom filter in the master UFOs' lib, not the designspace.lib: ... but that's because ufo2ft expects them to find filters in there. I don't think it looks for filters in the designspace.lib right now (also see googlefonts/ufo2ft#933) I wonder if this could introduce a potential difference if a DS-based project stores ufo2ft filters in the designspace.lib but only fontc looks for these, while ufo2ft doesn't... |
|
Okay so I think this approach actually doesn't work in the general case. Part of the motivation here was handling the case of compiling from UFO, where we synthesize the designspace, and we specifically wanted to copy over the I now have failures in several variable fonts that use designspace files, where we are copying over the Now I'm back to thinking that the best approach is going to be to just separately hold on to the lib for the default master? 🤦 |
Specifically we want to avoid merging 'public' keys in the case where we were explicitly passed a designspace file.
This is a conservative merge; we only update dictionary objects, and we only add items from the child that are not present in the base.
It is possible for there to be keys in the default master's lib that are not in the designspace lib, and which we want to have access to (the motivating example being the presence of the 'eraseOpenCorners' filter).
In an earlier patch I had added special handling for the case where we were compiling a single ufo; this new approach lets us delete that special case.
The decision to just look at the default master was arrived in conversation with cosimo. In general the keys that we care about are autogenerated by glyphsLib, and should be consistent between masters. We could try and verify that this is true but that feels like very low ROI at this point.