When trying to output a font, I got this err message:
Font Info > Features.
Thanks, Georg!
Maybe a suggestion would be for your err message to point to that location instead of the “Temp File” folder?
True. The OT functionality and especially the error reporting will be much better, soon.
That sounds promising! Hopefully a November surprise 
In the mean time, can I edit the code to add my own contextual features without fear of mucking up the works?
Sure. Font Info > Features > + > Feature, call it calt, and type your code in the top right pane.
Pressing the Compile button every now and then test runs your code.
Thanks, Erich!
Why doesn’t Glyphs import otf classes? I just converted one of my older fonts over to Glyphs. It brought everything over except the classes. It brought the feature code all in broken up in individual lines so that the number of code lines is 10 times larger than it was. As an example, I usually have classes for all cases like @lc is all lowercase so I can sub @lc by @CAPS instead of writing out every single glyph in its own line with single substitutions.
The representation of classes inside the binary font and especially the decompiling into feature code is not a 1:1 operation.
I find it easier to keep the code in sync when the substitutions are written out like this. Comparing two classes and making sure they are in sync is tedious.
Why would you replace lowercase with uppercase? Or do you mean small caps? In the first case, you shouldn’t do that, in the later case, just set the smcp feature to automatic and it will write all those lines for you.
Georg,
I had no intention of replacing uppercase with lowercase. That was just a simple example I used to explain my point. Yes, it would be {smcp} or {case} or {sups}, etc. But I am talking about pulling in existing code from a font begun in another software, not creating a feature from scratch with Glyphs. I have 16 years worth of work, hundreds of fonts, to switch over and am considering using Glyphs to do it. I am looking for a good way to do it.
You might get better results importing the documents from the editor that you used before instead of the .otf.
We have a script for Fontlab that can export the data to a .glyphs file: https://github.com/schriftgestalt/Glyphs-Scripts/blob/master/Glyphs%20Export.py
Chris,
When possible, it’s best to work from the font sources. Which font editor(s) were used?
There may be some helpful info in the Porting to Glyphs tutorial that also references Georg’s FontLab script. For VFB files, there’s also the vfb2ufo tool put out several years ago. I have not tested to see how the conversion compares to Georg’s FontLab script, though.
[Oops, got distracted and forgot to send this reply.]
I have been using FontLab 5.1 so all of my originals are FontLab vfb files. My dilemma is that I no-longer have a Mac that can run it. Mine died six months ago so I purchased a new one that is 64 bit and out of range for 5.1. From what I recall, for that FL script to work, I have to run it from FL5.1. Catch 22, no can do. Is there a way out of this?
FLS 5.1.6 is, I think, 64-bit. It was a free (and final) upgrade for FLS. Max OS is Mojave; will NOT work in Catalina.
Thanks, George! I tried it on my Catalina machine and it won’t load ;-(
Can you load Mojave in a virtual environment?
Thanks, George, I will give that a look.
Thanks, Jeff!
If you can’t get a version of FontLab to work for the conversion scripts, you could try vfb2ufo (free utility from FontLab) to convert to UFO2 format.
Once you load the UFOs into Glyphs, I’d recommend doing a File > Save As… and select Glyphs File for the file format. And do future work with the .glyphs files.
If that’s not successful, then a virtual environment for either macOS 10.14 or before, or Windows to run Georg’s FontLab scripts.
Other tutorial posts that may have useful info for bringing the fonts over include: Importing Existing Fonts and Working with UFO (though that one may not apply as much in this case).
Thanks, Jeff!
