UFO and designspace import ignores Glyphs-specific keys in lib.plist

1

I was very glad to discover that Glyphs now opens designspace files. Wonderful!

However it seems that in doing so it ignores three important Glyphs-specific lib.plist keys. Then as a result the Glyphs file (and any UFOs built from it using glyphsLib), may have incorrect settings. I’ve also noticed that this happens even if you open a UFO directly. That has been working properly for a long time, and so this seems to be a recent regression.

Unfortunately this breaks our whole workflow!

com.schriftgestaltung.useNiceNames is set to True, even if the original UFO(s) have it set intentionally to False.

com.schriftgestaltung.disablesLastChange is ignored and not present in the Glyphs file. As a result not only the exported lib.plist has the setting missing, but every .glif then has a com.schriftgestaltung.Glyphs.lastChange key, making version control useless.

com.schriftgestaltung.disablesAutomaticAlignment is set to False. I haven’t confirmed this, but I assume that means that the font is being imported according to local user settings, meaning that the import is inconsistent. This can easily spoil all the alignment in the font without the user realizing what happened.

We can work around the first two key problems (painfully), but the third may mess up our fonts with no workaround.

2

Sorry - this problem seems to be isolated to UFOs opened by opening a designspace file. Still a problem, but not as widespread as originally thought.

3

Do you have a sample file that you could send me?

5

Thanks for the file. I fixed it. The usual problem: if the info in the .ufos doesn’t agree, you don’t really know who wins.

6

Thanks! As for the problem - Designspace has the concept of a primary UFO (containing , etc.). So if there is any disagreement in the UFOs that primary UFO should be considered the correct one.

7

Hm, this might be a candidate for a UFO lint check.

8

I see that in your examples. I’ll check that.