Glyphs 3 destroys UFO + why can't edit designspace file?

Glyphs
1

Why Glyph 3 changes so many things in UFO?
Also think that being able opening .designspace file and edit the ufos that it opened and save it would be a great feature!

2

The internal changes in Glyphs 3 fit even less to the structure of .ufo files so it is difficult round trip everything.

Can you send me some example .ufo files?

3

UFOs.zip (48.2 KB)

there is original UFO made using RF, then one normalized using ufonormalizer (just indentation changed) and one that I opened in Glyphs and saved. Some files were removed and some changed the indentation too, which is fine. What was removed was empty background, which is Ok I guess, but it shows some vulnerability and makes me a bit scared what can happen next. When exploring further how background layers are translated into glyphs I found this → layer Screen Recording 2021-07-15 at 15.24.12.mov.zip (917.9 KB) Original UFO had a layer called foreground containing rough F and a layer called background containing rough B. Now they are a bit weirdly mixed up and the B is not accessible.

4

Thanks for the file. One problem with .ufo is, that everyone writes them out differently. No clear guidelines on how to indent, style of empty elements …

One thing I really dont understand is whey empty elements are saved at all. e.g.:

<key>org.unifiedfontobject.normalizer.imageReferences</key>
<dict>
</dict>

If there is no data, why the hell write that?

5

I had a look at the file and the differences:

  • Fixed the import of the “foreground” layer into an extra
  • the background layer doesn’t contain anything so Glyphs doesn’t write it out. The folder name for the background layer is glyph.background. But the spec suggests to use glyphs.public.background and that’s what Glyphs would use.
  • The public.glyphOrder is tricky. It serves multiple roles. On reading, it is used to actually sort the glyphs. But to make that stick, it needs the glyphOrder parameter. But on writing, the original public.glyphOrder list is not preserved as there is no sane way to store that. So it is computed from the actual order of the glyphs (in this example, the public.glyphOrder contains a lot glyph names but the .ufo only has one glyph. So the public order is reduced to 1 entry and the full list ends up in com.schriftgestaltung.glyphOrder.
  • fontinfo is another tricky area. writing the data, it is not clear what to write. There is no special mode for round tripping. So I don’t know what data might have been in an .ufo what was loaded some time before (and maybe saved as a .glyphs file in the meantime) or if it was an .ufo at all. So I write out a standard set of names. That contains a lot redundant data that could be easily computed from higher level info. But that can’t be relied upon.
6

Thanks a lot! Am really appreciating smoother UFO workflow for Glyphs users.

Please, consider also this feature that opening .designspace will allow writing too. To me it seems like cool idea as it would allow Glyphs users work with RoboFont users at the same project (This is the case at a place where I am now). The Glyphs users here felt a bit uncomfortable to be not able to work on both masters at the same time (being able to switch between them easily). It seems like it can’t be that far from doable, am I wrong?

7

For me it sounds a bit better to make the ufo export from glyphsLib work in Glyphs. Making that work in Glyphs 3 is will be some work.