On type & fonts

Type design notes      Font production notes      Type & font tweets

The conceptual side of font production & type design

6 June 2007

Designing a typeface is more than drawing a handful of letter forms and filling in the slots offered in the main window of one's favorite font editor. Even a designer who abhors technology and all that happens behind the graphic surface needs to make up his mind about fundamental questions like:
Which glyph set do I want to cover? The slots to fill in with drawings.
How do I name glyphs? This is not an issue for the 200-something standard glyphs which require standard names, but is as soon as alternate glyph forms are involved. Which suffixes to use?
To which Unicode codepoints do I assign each glyph? Do I follow Adobe and map a glyph to one Unicode codepoint only,[1] or do I take advantage of OpenType which allows mapping a glyph to multiple codepoints, as practiced by Microsoft?
Font naming is an issue I will not even touch here.
Of course one can use a font editor 'out of the box', and stick to its defaults, e.g. use FontLab Studio's auto buttons. These however rely on plain text mapping files which may be updated along with the application. Advantage of this: Things get updated if errors are found in these files. Disadvantage of this: Designing and generating a font today, then adding glyphs to and auto-Unicoding the font a few months later with a new version of the font editor may result in different fonts – Unicode codepoints of existing glyphs may change because of possible corrections to the file which maps glyph names to Unicode codepoints. This may even have an impact on documents if created with an older font version but edited with the new one. Improvements are nice, including corrected glyph names, Unicode codepoints or feature code, but are not so nice if they go unnoticed. An important issue in font production is control.
With this in mind, it makes sense to set up ones own versions of the font editor's mapping files. Tree examples:
In FontLab Studio, some of the most important files are those ending with .nam (glyph name to Unicode mapping, used with glyph name or Unicode auto buttons), .enc (the glyph set, used to display glyphs in desired order in the font window and to determine the glyph order in OpenType fonts), alias.dat (determines composition rules for accented glyphs). The original FontLab versions of these files can be found in the 'Application Support' (Mac OSX) or 'Common Files' (Windows) folders located in the system's main path. This structure of FontLab data folders is mirrored in the user path. A first step would be to copy the relevant files into the user path and, if desired, modify their content. Except for the alias.dat which must be named like this, copies of the other files should be renamed.
In DTL FontMaster, a .cha file maps glyph IDs to glyph names, Unicode codepoints and positions in codepages. What looks like an inconvenience at first glance – Damn, I have to learn that 101 means uppercase A! – in fact adds flexibility: If a type designer or foundry decides to change glyph naming conventions for the entire library, the change must be done in one file only. When generating fonts next time, the new glyph names will be used. As an aside, one does not need to stick to DTL/URW's numbering system but is free to set up ones own. However, kerning and OT feature files relate to glyph names, so these must match the according .cha file.[2]
In Adobe's font development kit for OpenType fonts (AFDKO), a GOADB file maps production glyph names to final names and Unicode codepoints. Moreover, the order of entries determines the glyph order in the final font.
Editing these files can be quite demanding. Most likely, the result will undergo changes with every new typeface whose design may introduce new technical requirements. But if done, typeface design will become – at least a bit – more of the desired 'filling in glyph slots with drawings'. Moreover, it helps to ensure that the type designer, not the font editor, controls font production.
I want to close this first entry with an example. For my personal use I decided to extend an .enc file a little. Since FLS5's .enc file may also determine the glyph order in the final font, I order glyph names nicely. And for every glyph name, the file holds additional information:
1. glyph name [the file's usual content]
2. Unicode codepoint(s)
3. a final name in case the glyph shall be renamed in the generated font, or a tag indicating that it shall be renamed in 'uniXXXX' fashion where XXXX is the (first) Unicode codepoint
4. information about components in case it is an accented glyph
5. a tag indicating whether a glyph is to be deleted upon font generation
6. punctuation spacing class to which this glyph belongs (more about this in a future note)
7. etc ...
The first three entries reflect the AFDKO's GOADB file, their implementation is a bit different though. In addition, I added tags which split the glyph set into sections for uppercase, lowercase, smallcaps, different kinds of numerals, punctuation marks, and others – useful for some scripts. Here an excerpt:
FontLab Studio only reads out the glyph names. All other information are invisible to it. Yet the file helps me organize all information at one place. To update the other files required in FLS5, after changing the .enc file I run a little script to update .nam and alias.dat files. (Restart of FLS5 required.)

[1] This addresses the fact that the PDF format only knows about glyph names, not Unicode codepoints, and assigning only one Unicode value per glyph makes it easier for Acrobat to guess at the Unicode value. This is relevant only if PDFs are generated by way of first printing to PS files, but not if generating PDFs e.g. from InDesign directly.
[2] This addresses the fact that the PDF format only knows about glyph names, not Unicode codepoints, and assigning only one Unicode value per glyph makes it easier for Acrobat to guess at the Unicode value. This is relevant only if PDFs are generated by way of first printing to PS files, but not if generating PDFs e.g. from InDesign directly.


All texts & images, unless noted otherwise:
Copyright © Karsten Luecke
All rights reserved.
All product and company names mentioned may be trademarks or registered trademarks of their respective companies.