I’m converting some Mac PostScript Type 1 fonts to OTF. The sign company I work for has a huge library of fonts that we’ve given internal codes for to keep track of which ones are being used for specific projects. I’m converting these and putting our company codes in the style menu to make it easier to spot that these were PS1 converted, but also to help people make sure they are using the correct coded font.
In this instance I’m converting Futura-Bold. Examples of our internal company code would be Futura-Bold (FB) and Futura-BoldItalic (FBI). The issue I’m having is that Glyphs keeps renaming the font after I export to OTF.
I type in Family Name: Futura Style: Bold (FB). What it changes it to is Family Name: Futura Bold (FB) Style: Regular.
I’m using Glyphs Mini. My work computer has Catalina, but my home computer has High Sierra (working from home today). I could swear this was working properly on my work computer, but doing these on my machine at home gives me the modified naming that I don’t want. Does anybody have any idea what is going on here?
Quick answer and solution: Put the addition into the family name, not the style name. Suggestion: make it even a prefix, not a suffix. And keep the style names ‘clean’ (‘Bold’, ‘Regular’, etc.).
Long answer: What happens when you export the font is a complex calculation f the various entries in the so-called ‘name table’ inside the font which stores all the naming infos. To cut an even longer story short, the family+style names are stored at least six times, in various (re)combinations, adhering to different app needs and methods. One of the style name entries only takes so-called ‘RIBBI’ names: Regular, Italic, Bold and Bold Italic. That has to do with style linking (think the B and I buttons in office software). In effect, if the style name you enter is none of these four (and ‘Bold (FB)’ is none of these four), the style name will be written as ‘Regular’ and the actual style name will be added to the family name. Otherwise style linking in office apps is broken.
And opening a compiled font file in Glyphs is reverse-engineering including some guesswork, so that is not a good idea for verifying fonts. The process I described above is hard to reverse, because it is not reliably possible to tell which part of the family name was originally meant as style name. For inspecting compiled fonts, I suggest tools like OTMaster, Font Table Viewer, or online tools like FontDrop.
Thanks for the feedback and detailed information about what’s happening internally. Sorry for not responding sooner. I had a lot on my plate this past weekend.
One issue with putting the internal company font code as a prefix is that the styles for that family will be scattered all throughout the font list. We already had that problem with a bunch of Font Company fonts that always put a letter in front of the name from the style. For instance Avant Garde Condensed Bold would actually show up as BCAVGarde in the list.
Putting the company code at the end of the family name would work, but then the fonts wouldn’t be seen as part of the same family. So ideally, I would still like to put the code we use in the style name. I understand about the style linking, but I thought if I unchecked those boxes, that it would circumvent those options. I don’t need these to work that way in any app other than Illustrator (and maybe Photoshop very rarely). So the style linking isn’t something I need.
I did do a mass conversation using a trial of TransType 4 and now I’m going back through and adjusting the naming conventions with Glyphs Mini 2. I do have FontForge also, but it has a bunch of issues in Big Sur with saving the converted files. Plus I just prefer the cleaner and easier to use interface of Glyphs.
I’ll check out some of the other applications you mentioned so see if they might work for what I need also.
Adding the suffix to the style name messes up the style linking and compatibility between apps (if you open a formatted document in different apps, the font selection may be different). And you end up with two very similar styles in the family. The can confuse the user.
So I recommend to add the suffix to family name.
Again, I strongly recommend to add any suffixes and prefixes to the family name, not the style name.
And why would that be an issue?
On the contrary, you may run into legal issues because if you create modified versions of the font, the license usually stipulates that the family name must be different. It is probably best to double check in the original font EULA.
And if both (old and new) families are installed, you can simply change the family name, and the whole document is updated.
You can and it will probably work that way in PS and AI already, and probably, break in other apps.
You said you are doing this for a company, so I assume it is not entirely unthinkable that somebody else will use the fonts in a different setup than yours, and then they may run into problems.
So, name ID 2 should adhere to the RIBBI limitation (which is the style name you see after you reverse engineer a compiled font file in Glyphs Mini).
Thank you both for the feedback!
I talked to one of the other graphic designers here and we decided to compromise by putting the font code at the end of the font family name as suggested. It will make the font list pull down longer, but at least the code will be part of the font name.
We discussed putting the code as a classification in FontExplorer X Pro, but that will be harder to maintain consistency across different users and won’t show up in the font list in any of the apps.