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
0
Comments
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.
I forgot to ask, I guess that exchanging .glyphs files is a better option than .ufo?
* We’ve only done this with Glyphs 2.x files; none of our collaborators are on Glyphs 3.x yet, I think.
I know of a couple of issues in my current FontLab>UFO>Fontmake workflow that are specific to the UFO export from FontLab.
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.