UFO import places custom lib.plist data and other items within userData{UFO.lib}

When Glyphs imports a UFO it saves certain lib.plist data within its internal userData. That’s not a problem, however some of the data is placed within yet another {} called UFO.lib. In particular these are placed there:

  • com.schriftgestaltung.font.Disable Last Change
  • custom keys (such as org.sil.altLineMetrics)
  • public.postscriptNames

The problem is that when glyphsLib reads this data and writes out a UFO, these keys - that should be at the root of lib.plist - are stuck inside an unnecessary UFO.lib key. All of these should be at the root level of userData, not within UFO.lib.

This also causes problems with keys that are already in the lib.plist root (com.schriftgestaltung.font.Disable Last Change, public.postscriptNames). These end up with duplicated and potentially conflicting data.

There are a couple of glyphsLib bugs that this triggers. I’ll report those in the github repo, but this unnecessary UFO.lib container is something that should be fixed in the Glyphs file on UFO import.

The current implementation puts all keys that it doesn’t understand into the UFO.lib key. Otherwise I had the problem that some keys would spill into the lib.plist that people would complain about. There shouldn’t be conflicts. Please check if the file doesn’t contain some keys from older versions of Glyphs (com.schriftgestaltung.font.Disable Last Change should be be com.schriftgestaltung.disablesLastChange).

Thanks. I’ll be sure to get rid of the old Disable Last Change. However public.postscriptNames is almost universally recognized. I’ll try to get glyphsLib to change. Otherwise, we’ll just normalize it ourselves.

The public.postscriptNames should be written into the root of lib.plist on export to UFO. So it should be fine. glyphsLib needs to know about the UFO.lib.