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 Export.py (https://github.com/schriftgestalt) 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.
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).
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.
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.
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.
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.
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.
The conclusions I’ve come to are that the Glyphs Export.py 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.
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.
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.