Noticed that the value for GSLayer.vertOrigin is discarded in a .glif file when saved as a UFO on both Glyphs 2 and Glyphs 3. Is this intentional?
As mentioned on GitHub, GSLayer.vertOrigin is designed to be a delta to the default origin, thus the value for public.verticalOrigin should be re-calculated using GSFontMaster.ascender or GSLayer.vertWidth, but I think it’s technically feasible.
The current UFO 3 spec defines advance.height of .glif must be 0 if omitted, but in the future version we might be better to fix it to prefer None over 0. For round-tripping a UFO within Glyphs, I see it’s completely okay not to write out the advance height and expect to be treated as None if the glyph has the default height. Doing so in Glyphs makes total sense to me. Unfortunately that’s not the way glyphsLib works, thus importing UFOs exported by glyphsLib to Glyphs will require another strategy to treat 0 as font.upm for interoperability. While it’s not elegant, it is possible (but somewhat unreliable) to distinguish the creator of a UFO file according to metainfo.plist – but I think it is completely your choice to add such a circumvention to Glyphs.
Apart from that, I assume the vertOrigin can be round-tripped without much ambiguity regardless in which direction the vertWidth discussion goes. It looks to me that how the public.verticalOrigin value should be treated in the end is not super clear in the UFO spec, but it is natural to think it’s the place to put the value in the VORG sense, like glyphsLib handles it currently.