If you have bad glyph names (geeks even call them ‘illegal’), then your font may not compile correctly. So, make sure your glyph names adhere to the glyph naming convention.
Actually, Glyphs will check what you enter into a glyph’s name field and prevent you from causing trouble in the first place. Still, if you open a font that was created in another software that does not check glyph names, you may still end up with illegal names in your Glyphs file. If that happens, then this blog post is for you.
Update Glyph Info
A good first step to fix glyph name problems is the Update Glyph Info command in the Font menu. This will try and synchronize Unicode values and glyph names.
Built-in database of glyph names
In some cases, Glyphs follows its own naming convention, especially in non-Latin scripts like Cyrillic or Arabic. That’s because we do believe that
Zhe-cy are more descriptive than
uni0416. Take a look at the Glyph Info palette for a list of descriptive glyph names. You can access it via the Window menu.
Sometimes, you want your glyph to correspond to a certain Unicode character for which there is no entry in the Glyph Info. A typical example will be a character in the Private Use Area (PUA). In this case, you start your glyph name with
uni, followed by the hex code (with uppercase letters), e.g.
For glyphs that correspond to Unicodes outside the Basic Multilingual Plane (BMP), the name starts with a
u, followed by the 5-digit code. For instance, the glyph for
U+10102 AEGEAN CHECK MARK would be called
Roll your own
If, however, you have to make up your own glyph names, it is a very good idea to stick to the following naming scheme. The first character in a custom glyph name should always be one of these:
That’s it. If your first character does not appear up there, your glyph name is most likely illegal and the font police will come, lock you up and, even worse, prevent your font from compiling correctly. So, read my lips: no umlauts, no accents, no funky Hangul sign, just plain ASCII letters. That’s letters, so no figures either. And especially no space, no comma, no dash or any other punctuation. Just plain old A to Z or a to z.
For the rest of the glyph name, you can also use one of these:
1234567890 (figures) _ (underscore) . (period) - (dash)
That’s it. Again, no space, no accents, no fancy-schmancy anything. But behold, some of these have a special meaning.
The underscore (_) is used for ligatures. The underscore connects the names of the glyphs that are connected by the ligature. So, the parts between the underscores should, again, be valid glyph names as they appear in the Glyph Info palette.
Sounds complicated, I know, but it’s easy. Imagine you have a ligature of
h, then your ligature is called
f_h. Want a ligature of
adieresis (ä)? Then your ligature is called, you guessed it,
f_adieresis. Wanna put your name in as a ligature? Make that
P_e_t_e_r or whatever your name is. If you stick to this convention, Glyphs can even build the respective ligature features for you.
The period (.) is used to add a descriptive extension to the glyph name. In many cases, this will be the name of the feature in which the glyph is supposed to appear, e.g.
e.ss01 for your alternative
e. If the part before the period is a valid glyph name from the Glyph Info palette, then your font will work better in certain situations such as copying text from a PDF in which your font is used.
Since the automatic feature generation places most ligatures into
dlig (discretionary ligatures), you can use the
.liga extension to force your ligature into
liga (standard ligatures) instead, e.g.
Also, you can make a localized version of a glyph with a
.loclXXX extension where XXX is the Language System Tag, e.g.
adieresis.loclSVE for a Swedish ä or
eacute.loclPLK for a Polish é. Glyphs will take care of the locl feature automatically.
Glyphs uses the dash (-) for appending a script system, e.g.
-cy for Cyrillic,
-ar for Arabic,
-deva for Davanagari and so on. Open your Glyph Info palette and type a dash in the search field. You get the idea.
[Update 21 Sep 2012:] Added the paragraph about non-BMP Unicodes.