Creating an all-caps font in Glyphs Mini

by Rainer Erich Scheichelbauer
en es fr

28 July 2022 Published on 25 June 2018

In an all-cap font, the same capital letter should appear whether the user types the key for the lowercase or the uppercase. Read the following easy step-by-step tutorial to make this happen with Glyphs Mini.

A computer differentiates between letters (and thus, also between upper- and lowercase) by means of Unicode values. For example, uppercase K has the Unicode value U+004B while the corresponding lowercase k is represented by U+006B.

In case you were wondering what the U+ means: it is the marker for a Unicode hexadecimal code. The most important codes, the codes in the so-called ‘Basic Multilingual Plane’ (BMP) have four digits and can be represented with 4 hexadecimal digits, from U+0000 to U+FFFF, in total 65,536 code points, containing the characters for all modern writing systems. Read more in the Unicode tutorial.

A glyph in your font is either accessed by its Unicode value, or, typically the glyphs with a dot suffix, through an OpenType substitution feature, which substitutes a glyph carrying a Unicode value with a glyph that has no Unicode value associated with it. The glyphs with a Unicode value can often be typed (that is, if you have the appropriate keyboard layout), or copied and pasted as text.

Double Unicodes

Luckily, since Glyphs Mini 2.0.2 (91), you can assign not only one, but several Unicode values to a glyph. You can even have Glyphs assign them automatically in one go:

  1. In Font View (Cmd-Opt-1), go to the left sidebar and select Categories > Letter > Lowercase.
  2. Select all glyphs (Edit > Select All, Cmd-A).
  3. Click the minus button in the lower left corner in order to remove the glyphs. A confirmation dialog will pop up:

Now, when you export, all uppercase letters that do not have a corresponding lowercase letter, should also get the lowercase Unicode value assigned on export. The change is not reflected in the user interface, but you can test your font with the Adobe Fonts folder or into a separate folder and test your font with TextPreview.

Dilemma of the dotted i

The relationship between uppercase and lowercase is not the same for all languages though. Turk languages, including Turkish, Azeri and Tartar, relate the lowercase (dotless) ı to the uppercase (dotless) I, and the lowercase (dotted) i to the uppercase (dotted) İ, whereas non-Turk languages, including French, English, Spanish and German, relate the lowercase (dotted) i to the uppercase (dotless) I.

The logical problem is now: Which uppercase glyph should receive the Unicode value for the lowercase (dotted) i? If your answer is I, then your font is incompatible with Turk languages. If it is Idotaccent, it is incompatible with all non-Turk languages using the Latin script. A dilemma.

But fear not, there is a viable workaround. In order to support both Turk and non-Turk languages (at least in OpenType- and language-aware applications like Adobe apps), we need to keep these three lowercase glyphs around:


Design i and idotless as an uppercase I without a dot, and idotaccent as an uppercase I with a dot.

Then Glyphs Mini can insert an OpenType feature that swaps i with idotaccent if the language is set to Turkish, Azeri, Crimean Tartar, etc. And the proper relationships between lowercase and uppercase are preserved.

Vertical metrics

In File > Font Info… (Cmd-I), you can probably get rid of the Alignment Zones for x-height, ascender and descender. Your Standard Stems only need to match the uppercase stems.

Do keep the Ascender and Descender values around, though, since they will be used to derive the vertical metric values written into the respective OpenType font tables OS/2 and hhea (see the Vertical Metrics tutorial for details). It is best to keep these values around the font master’s highest and lowest bounding box values, typically found in diacritics like Ccedilla and Ohungarumlaut.

Problems with double encodings

As much as double encodings can cut down on file size, there is also one problem with certain PDF workflows. Copying selected text from a PDF can result in garbled casing of the character stream inside the clipboard, i.e., coPiED tExt caN END uP looKiNg liKE tHiS, unless the PDF was created in a certain way (hint: not with Acrobat Distiller) and the text extraction is also done in a certain way. Don’t worry, this just affects the text in the clipboard, the representation in the PDF will be fine. Then again, text extraction from PDF is flawed anyway, and if this is not much of a concern for you, you’re good.

Update 2018-04-24: added Problems section. Thanks to Aaron Bell, Khaled Hosny, and John Hudson.
Update 2018-06-29: Added Dilemma of the Dotted i section. Thanks to Mark Richardson (@superfried).
Update 2020-11-13: updated for Glyphs 3 website.
Update 2022-07-27: updated title, related articles, minor formatting.