FontLab and Glyphs — Round-trip font development (July 2021)

Igor Petrovic

What a team of type designers should know about FontLab and Glyphs relationship if both apps are used in the type production process?

Looking at the latest FL release notes seems that export-import of .glyphs files works just fine with a few limitations:

- FontLab 7.2 does not read or export custom parameters for instances (there is a suggested workaround to define instances again)

- When you export variable components to .glyphs, FontLab replaces them with components that point to the current layer. This is a known limitation. (because FL has the option for variable components to point to "other than the current" layer)

Is there anything else to consider and adjust the workflow accordingly. How about metrics, kerning, hinting, alignment zones, masters, interpolation, open type features, classes...does everything works smoothly?

Thanks

John Hudson

We’ve been pretty happy with a Glyphs-to-FontLab workflow, but mostly in that direction. Some of our collaborators use Glyphs as a design tool, but we tend to make FL7 our master source tool, and integrate glyphs and some other data from Glyphs sources into FL7 files. Sometimes I prep files for collaborators in FL7, and then export to a Glyphs file to send to them to work on.

Some things I have noted:

• Glyphs variable design space info tends to get a bit garbled when read into FL7. I am not sure whether this is due to some incompatibility in the data models or just the way in which the Glyphs data has been entered by collaborators. I get the impression that there are some ways of working in Glyphs that are easier when things are set up in a certain way, so users may do things that differ from how I set things up in FL7. So when I open a Glyphs file in FL7, I usually need to do some renaming of layers and masters before copying into my FL7 master sources.

• Glyphs apparently has no way to select zero-width glyphs in the edit window, so common practice is to give mark glyphs an advance width and rely on Glyphs to collapse to zero-width during output. This means our collaborators tend to give mark glyphs a width, and I need to remember to collapse to zero-width and check mark and anchor offsets after copying into my FL7 master sources.

• Glyphs uses a glyphdata.xml file for Unicode mapping and various other things that Glyphs automates. FL7 uses a variety of data files for name mapping, encoding, and glyph ordering. Since we use our own naming system for glyphs, I sometimes need to prep custom versions of the Glyphs glyphdata.xml file for collaborators.

• CRITICAL : FL7 has a bug importing glyphs/layers that include colour stickers/annotations such as arrows pointing to outlines, comments etc. This is a really nasty bug, because when you import the glyphs/layers you will not see anything wrong: it is only when you save, close, and reopen the font that you find that all the glyphs are displaying as transparent and cannot be fixed. The workaround for this is either to delete all such stickers in Glyphs before opening the file in FL7, or after opening/importing in FL7—but before saving—use the Properties/Colored filter to identify glyphs that may contain colour stickers in one or more layers, then go in and delete those stickers (bearing in mind that that may be transparent and hence invisible until you do Command+A to select all elements. As a final note, even after doing this and saving, a VFC may still display with transparent glyphs when reopened. So always set Preferences to save both VFC and VFJ so that you can open the VFJ—which should display the glyphs correctly—and save as to overwrite the corrupted VFC.

Igor Petrovic

@John Hudson Many thanks John, this is very helpful!

I forgot to ask, I guess that exchanging .glyphs files is a better option than .ufo?

John Hudson

Since some of our collaborators are using Glyphs, and FL7 can read and write Glyphs files*, I prefer to use this workflow just to avoid the extra step of converting from Glyphs or FL7 to UFO. We use UFO for some other things, notably as part of our build process.

* We’ve only done this with Glyphs 2.x files; none of our collaborators are on Glyphs 3.x yet, I think.

Chris Lozos

Thanks @John Hudson  ! I have been doing the dance from the other direction, FL7 to Glyphs 3, for several months now and I appreciate your description! I think the type World works best when you can interoperate between tools and find what works best for you!  Bless you, John!

Thomas Phinney

I would strongly second avoiding using additional conversion steps if they are unnecessary.

I know of a couple of issues in my current FontLab>UFO>Fontmake workflow that are specific to the UFO export from FontLab.

John Hudson

I know of a couple of issues in my current FontLab>UFO>Fontmake workflow that are specific to the UFO export from FontLab.

Details please.

Thomas Phinney

If I use notes on glyph cells in FontLab 7.2, and export UFO variable font from FontLab, Fontmake fails to compile the UFOs. (Just filed this one with FontLab, #6106)

If we use colors other than FL-standard ones to to flag glyph cells in the FontLab font window, those glyphs get left out from processing by UFOprocessor. We just discovered this one in the last couple of days.

For both of these, it is not completely clear where the bug lies, whether with FontLab or the UFO-consumer. FL seems more likely, but I make no assumptions.

Adam Twardoch

@Thomas Phinney — as a rule, presence of glyph notes does not interfere with DesignSpace+UFO export and subsequent fontmake use (I just verified this). I think there is something specific to your project, please kindly submit an attachment to us. 

Thomas Phinney

It is entirely plausible that there are multiple factors involved, and the issue is peculiar to our project for some reason. It’s a 4-axis font with ~ 2000 glyphs* and a complex build workflow, so… I am not assuming finding the answer will be simple or easy. That’s actually why we were slow to report this one—neither Vassil nor I wanted to have to really dig into it.  :P

Thomas Phinney

Apologies for thread drift. We’ll do this off-forum (though may report back later).