Best practice for FontLab / Fontographer file conversion in 2019

I’ve got some old FOG files that I want to convert, mainly for archiving. I understand that the only way to do this is via FontLab. After doing some tests it turns out that FontLab’s FOG import is much better than Fontographer 5’s VFB export, as the header data gets mangled along the way.

What’s the best practice for this in 2019? I have a demo of FontLab VI and also a full version of FontLab 5 so I can import the FOG file into either, but I’m unsure which will give better results. From there I can use FontLab’s UFO export or schriftgestalt Glyphs ( to get the file into Glyphs. I read a post on the Glyphs blog that suggests that FontLab UFO export isn’t as good as the Glyphs Export script, as it loses too much info. Has anything improved with FontLab VI or is it still better to use the script?

I’ve done a number of tests and data seems to easily get corrupted or lost when passing files between apps and formats. Every method seems to have a problem of some sort. Isn’t this what UFO was designed for? Perhaps the script also imports data that UFO doesn’t support? Thanks.

FLVI can export .glyphs files. That will probably be your best option. I believe it can also import .fog. So that would be your best option for getting Fontographer data into Glyphs.

If you have a functioning version of FLS5 around, the scripts will be the best option.

In the very worst case, you can export an OTF without overlap removal and import that.

There is a tool called vfb2ufo. It can convert .vfb file to .ufo files that can be opened in Glyphs

Georg, that script is not on FontLab’s server anymore. Probably removed because FL can export UFO natively now.

It is best to export to .glyphs from FL VI, but be sure to check the files, sometimes funny things happen (like some, not all metrics set to zero. Exporting an .afm and importing back to Glyphs helps).

You also could export a designspace file and import that in Glyphs.

The FOG file has to be opened in either FL5 or FL6. After that it’s which is the best way to export and import into Glyphs, which is either as a UFO file or using the script.

This blog post suggests that UFO isn’t the best way to convert from FontLab to Glyphs. Is this still the case?

If you want to move your font project between Glyphs and FontLab Studio, however, it is a bad idea to use UFO as exchange format, because too many things may get lost on the way. In this case, it is better to use the Glyphs Import and Glyphs Export macros for FontLab Studio, provided by Georg on his GitHub repository.

Did vfb2ufo do a better job than FontLab IV’s UFO export? The attempts I’ve made so far don’t give great results. FontLab VI looks good but it seems that some of the import / export is pretty janky, so I’m not sure if I should trust anything that uses FontLab code.

Does Designspace offer any advantages over UFO for single font conversion? I literally only heard about this format yesterday when I was exporting files from FontLab VI.

I found another script called

I think I’ll give this a go also and see how all these things compare.

Some gotcha’s with vfb2ufo:

  • Some known bugs in vfb2ufo:
  • glyphs with overlapping components are decomposed
  • unnamed guidelines get corrupted
  • ghost hints are reversed
  • OT classes are not written into features (remain as groups)

More bugs here:

vfb2ufo was made with all the knowledge taken from the old RoboFab macros but also new developments (UFO 2 and 3) and in collaboration with Tal, Frederik and other UFO gurus. The same code will be used in FontLab VI and TransType, and we will be actively improving it as the UFO format evolves.

According to this post, vfb2ufo is essentially the same as FontLab VI’s UFO export. So bugs might still be present, unless they have been fixed since the post was made.

If you have FL5 around, use the “Glyphs” script.

Seems like it’s worth a shot to open the .fog files with FontLab VI and then move them to Glyphs with the “Export Font As Glyphs” feature. I tested it with some old .fog files and most of them seemed to export fine. I don’t have a way to test them in Fontographer anymore, and I’ve come a long way since I made those .fog files, so I’m not sure if anything was missing.

1 Like

Conversion isn’t as straightforward as I first thought, so I think others will be searching for this in the future also. I’ve found a few threads and blog posts on conversion but it would be good to have something that identifies the best way to do this in 2019. I’m going to do some comparisons of the Python script and FL VI’s export feature as these are the two main options. vfb2ufo has been taken offline and appears to have been incorporated into FL VI, along with any bug fixes that might have been made. On the subject of UFO, it seems that direct conversion to Glyphs is preferred. I’d be interested to hear more detail from Rainer Erich Scheichelbauer on why UFO isn’t as good as the Convert to Glyphs Python script, not just for myself, but for anyone else looking for advice on this subject.

I’ve done a few tests. The source file was created as a VFB file in FontLab Studio 5. It’s a single weight font with a few OpenType features.

The points below focus on the differences shown in the Font Info window. Where info is missing or differs I have noted it. My tests weren’t extensive or very scientific, but I’m sharing my findings here for others anyway.

1. Open VFB in FontLab Studio 5
2. Python Script export

Font Info - Font

  • glyphOrder: .notdef excluded from list.

Font Info - Masters

  • Custom Parameters: underlineThickness/Position, strikeout/Size, TTFZone/Stems, subscript(x4), superscript(x4) parameters are missing

Font Info - Features

  • Features: kern is missing. The kerning has imported but not as an OpenType class.

1. Open VFB in FontLab VI
2. Export as Glyphs

Font Info - Font

  • Date: Updates to date of the conversion
  • Custom Parameters: Panose parameter is missing
  • Custom Parameters: openTypeOS2VendorID is missing
  • Glyph order differs from Python script order

Font Info - Masters

  • Vertical Stems: There is an additional entry that does not appear in the original FL5 VFB source file, although it does import also as a Custom Parameter.

1. Open VFB in FontLab VI
2. Export as UFO Package (‘legacy’ UFO2)
3. Import UFO into Glyphs

Font Info - Masters

  • Custom Parameters: Generally this is much more complete than the other two methods. However strikeout/Size, TTFZone/Stems, subscript(x4), superscript(x4) parameters are missing. Many parameters are greyed out. I’m unsure if these are unsupported or depreciated?

Font Info - Instances

  • Custom Parameters: postscriptFontName, postscriptFullName, styleMapFamilyName are included. Other methods don’t show anything here.

Font Info - Features

  • Prefix: Languagesystems is present, omitted from other methods.
  • Classes: Lots of duplication here.
  • Features: kern is present but disabled.

The conclusions I’ve come to are that the Glyphs script is the best way to make conversions. Some data isn’t imported, which may be a problem for some. Perhaps some of the Custom parameters that the Python script misses relate to TrueType publishing or publishing to legacy OSes, but for my use I think I don’t need this as I only publish OpenTypePS.

Yes it does. They are called groups to differentiate from other OT classes. See the kerning tutorial.

This has been interesting. I found some sample .fog files that came with Fontographer 4.7, dated September 1994. One is Goudy Hundred. I brought it through FLS5 and converted to Glyphs with the python export script. I also tried opening it with FLVI and exporting to Glyphs from within the app. Both ways kept kerning intact. There were differences in custom parameters. The direct from FLVI export has glyphOrder only. The python export from .vfb has panose, openTypeOS2Type, and glyphOrder. I was impressed that 25 year-old files can be opened so easily.

1 Like

The grey custom parameters are not supported by Glyphs.
And a lot of the parameters that are imported from the .ufo are superfluous as Glyphs would calculate those values automatically. So more data is not necessarily a good thing here as it just adds room for errors.

1 Like