Problems with lib.plist in UFO export

1

Opening a UFO, making changes, then exporting as UFO now causes custom keys to be placed inside a dict within a com.schriftgestaltung.font.userData key. That shouldn’t happen. Custom keys are just that - and shouldn’t be altered by Glyphs. That’s not your data, so you shouldn’t be messing with it. Other tools depend on these keys, and you’ve broken them!

I’ve also noticed that you are now storing within that key some of your own fields. That is also unnecessary, though you are welcome to do that. The problem is that you continue to export the same keys outside your new dict, so that a number of your keys get duplicated. This bloats the lib.plist (especially with thousands of items in .glyphOrder!) and it’s not clear which version of the keys is authoritative or maintained.

Please be consistent in where place your keys, delete your keys from places that are no longer current, and stop moving other people’s keys around!

1 Like
2

Could you send me some sample data? That would help a lot.

3

Take a look at the lib.plist in the source/Andika-Regular.ufo font in https://github.com/silnrsi/font-andika. That file has been imported/exported through Glyphs many times now. We have done some basic normalization on it, and also manually moved our custom data keys (org.sil.keyname) out of your userData key so that our tools can access them. Thanks!

4

I have fixed that in an upcoming version already. I don’t like to change things to much for the 2.4 version because I like to release it soon.

5

Excellent - thanks! Fine to wait until the next version.

6

With the above changes/bugfixes in mind, which lib.plist key should we use set the display order, com.schriftgestaltung.glyphOrder or com.schriftgestaltung.font.glyphOrder ?

7

The second one shouldn’t be there. And ‘com.schriftgestaltung.glyphOrder’ will only contain the content of the glyphOrder parameter, not the actual full ordering of the glyphs. That you find in public.glyphOrder.

8

Thanks.

9

Seems to still be a problem in 1060 – Any ETA for this fix?

10

I’m trying to get the beta for version 2.5 into a releasable shape really right now. Should be out this week.

11

Progress! In 2.5b (1066) I no longer see a com.schriftgestaltung.font.userData key created, and our custom keys remain in tact. So Victor’s original concern seems to have been addressed. Thanks!

I am still seeing both com.schriftgestaltung.glyphOrder and com.schriftgestaltung.font.glyphOrder keys in exported UFOs – do these serve different purposes and if so can you describe the uses?

12

Fixed the duplicate.