Font editing is an important, albeit infrequent, task in most localization companies. Corporate “look and feel” is often expressed in part through the use of specific fonts in published documentation, and a large industry has developed around providing the right font for any given job. Larger companies often have developed their own fonts to better express their corporate identity, but these fonts were seldom designed with any markets besides Western European ones in mind. As companies expand into newer markets they do not want to abandon their corporate look and feel because their chosen fonts do not include the needed characters for languages such as Hungarian, Polish, or Lithuanian (not to mention Greek or Cyrilic).

The ability to unify the look and feel of localized materials in Roman-script languages (at the least), or in the historically-related Roman, Greek and Cyrilic scripts, is an important consideration for many corporations. (While the same considerations exist for other scripts as well, the letter characteristics of these other scripts is such that their fonts cannot be matched to Roman fonts in any meaningful way, while the three scripts cited above can be closely matched.)

In order to facilitate localization into non-Western scripts, localization firms traditionally had to make use of various code-pages and fonts designed to go with those code pages (such as CE fonts, for Central/Eastern European languages). When CE variations of fonts were not available companies often created their own, most often in Macromedia Fontographer, a capable but somewhat limited font editor. To complicate matters further, it was fairly common practice for international-language fonts to be encoded in the Western European code space by substituting non-Western glyphs in place of Western glyphs not used in the language in question (e.g., the Russian letter я (ja) might be put in the place of the "q" character in a Roman-script font).

The result was that many companies had legacy material in a variety of recognized code pages, as well as in a large number of ad hoc code pages created for hacked fonts. Such non-standard encodings were surprisingly common, especially when localizers had to make use of non-internationalized tools for publishing that simply couldn’t handle the real code pages properly. (Of course when the primary concern was simply trying to get international text to appear at all, one can guess where such textual aspects as correct sorting and hyphenation ended up…)

Fontographer was, for most localizers, the only practical tool for font production, but it has not been updated since 1996 and, significantly, does not support OpenType, which has emerged as the de facto standard for Unicode font rendering on both Mac and PC. Until recently there were no tools aimed at the consumer market for working with OpenType fonts, but the release of FontLab 4.5 changed this. FontLab’s capabilities go beyond Fontographer’s in a number of significant ways, including native support for both PostScript and TrueType font data (Fontographer supported only PostScript natively), and support for OpenType features (such as glyph substitution).

FontLab can open and work with both single- and double-byte fonts, but is limited to approximately 5000 characters per font, so another tool (such as FontLab Ltd.’s AsiaFont Studio) must be used for serious CJK font development. Asian font development is, however, not a task that most localizers are likely to undertake, so I do not consider this a serious limitation for most users.

Figure 1. FontLab’s Glyph window. This window is used to edit the outlines of individual characters in a font.

Users of Fontographer will find the interface of FontLab superficially quite similar to Fontographer, but there are a number of differences in how tools operate that require getting used to. One complaint with earlier versions of FontLab was that the drawing tools were not like those of mainstream drawing applications (such as Adobe Illustrator), and were difficult to learn. FontLab’s developers clearly took this feedback into account as the drawing tools are, by and large, straightforward. I feel that FontLab has even improved on other drawing tools in one instance - it makes a very useful distinction between points and lines that other programs I have used do not make, and this in turn makes some common editing tasks much simpler than they would be in Illustrator.

Another welcome feature of FontLab is that its support of Unicode is pervasive and meaningful - ranges of characters can be selected by their Unicode names and indices, and if a character is not defined FontLab displays a grayed-out glyph representing the character. In most cases this glyph is sufficient to identify a character without resorting to code charts or look-up tables. In addition to Unicode, FontLab supports virtually every known standard code page and can be used to generate fonts in these encodings.

FontLab is a powerful program, and can be made even more powerful through the use of Python scripts. (Knowledge of Python is not required to use FontLab by any means, but knowing it would certainly allow a user to make much more efficient use of FontLab.) That said, FontLab’s power makes it a much more complex application than Fontographer and FontLab’s interface therefore more complex than Fontographer’s. In my trials it took me a while to figure out how to do a number of common tasks, like create a blank glyph slot, that should have been obvious without reading a manual, so some simplification of the user interface may be in order.

Real World Tasks

To evaluate FontLab I tried three different typical real-world tasks: creating a new font from scratch, editing a font previously created in Fontographer, and building a single OpenType font with complex typographical features from existing regular and “expert” fonts. These tasks were chosen in order to evaluate FontLab’s suitability for tasks which multilingual computing professionals might likely use FontLab to complete.

1. Creating a New Font

In this trial I created an OpenType font containing characters of the International Phonetic Alphabet (IPA), a standard set of characters used to indicate sounds in speech transcription. (The actual characters were built from bits of characters in an existing font rather than made from scratch.) This task proved to be simple and straightforward and resulted in a font that I was able to access in Adobe InDesign 2.0, one of the few applications on the market that truly can take advantage of OpenType at this time. The only difficulty was in automatically setting appropriate font metrics, which seemed a needlessly complex process, but this was really a minor problem since quality fonts would require manual tweaking of metrics anyway.

Figure 2. FontLab’s Font window. This window is used to access the characters of a font (in this case part of the International Phonetic Alphabet [IPA]). Characters in gray squares are empty, whereas those in white squares contain actual font data.

One limitation I found during this test was that while I could copy outline data from FontLab and paste it into Adobe Illustrator (a typical approach when a user might need more robust or familiar tools to edit an outline), I was not able to paste outlines back into FontLab - they appeared as uneditable guides when pasted back in, and I could find no way to convert them to actual character outlines. While there may be some way to get outlines back into FontLab, I was not able to find it, and FontLab’s behavior in this case was counter-intuitive.

2. Modifying a Font Created in Fontographer

In this trial I modified a font sent to me by a colleague that contained Ogam characters (formerly used to write Gaelic and Pictish in the British isles). Importing the font into FontLab was straightforward, but the font had a number of problems characteristic of amateur fonts designed in Fontographer, including improperly defined metrics. I was unable to fix these problems in the font itself without introducing yet other problems, so I had to create a new font and copy the glyphs one by one into open glyph windows and resize them. The task screamed out for automation, and I suspect that if I knew Python I could have easily scripted the task, but without Python the task was tedious and unproductive.

I also wanted to reassign the glyphs to their appropriate Unicode code points (the original font was encoded entirely in the US-ASCII code space because the creator was interested in having a font that anyone could use). This task seemed like it should have been possible, as FontLab allows for the creation of Unicode Ogam fonts, but I could not find any way to actually access the Ogam code space in the font editing windows. I finally gave up and left the font in its original (but improper) code space.

There was also no intuitive way that I found to take blocks of improperly coded glyphs and change the encoding - the only available method was manually typing in the Unicode code points for each character. Changing encodings and moving characters is a common task in updating legacy fonts, and this is a task that should be easily accomplished, either in a batch or through a drag and drop window that allows moving characters from one code point to another. However the methods I was able to find were not intuitive and were needlessly labor-intensive. (A Python script for renaming glyphs is available on the FontLab website, but setting up the script for a one-time use would likely take longer than manually renaming the series of glyphs. The script would only be truly useful if a user were converting more than one font from a legacy encoding into a current encoding, in which case it could save significant amounts of time.)

3. Building a Complex OpenType Font

One of the greatest promises of OpenType for creative users is its rich typographic capabilities, and combining special characters (such as small caps or “old-style” numerals) into a single font to take advantage of this capability is a task that would interest many users. This task goes beyond simply combining fonts (a simple task) - it involves setting up a font so that an OpenType-aware application knows how various glyphs are related, e.g., that a small caps A glyph is a substitution for the underlying character a.

Generating an OpenType font with advanced typographic features proved to be the hardest of the three tests because the task itself is complex and requires considerable knowledge of how OpenType fonts are constructed. FontLab’s manual contains an overview of the OpenType feature definition language, but building the feature tables requires a lot of work. The current method requires typing in a lot of code manually, as shown below.

Figure 3. FontLab’s OpenType features definition window. Defining OpenType features is a fairly complex task. This illustration shows part of the code that enables an OpenType font to automatically substitute single ligature glyphs for sequences of multiple characters.

As with moving characters between code points, this is another area where simple drag and drop automation would be ideal - it would be much easier for the end user to have a window where an OpenType feature (like small-caps substitution) could be selected and the appropriate characters dropped into some sort of grid. Short of that some simple wizards that would walk users through building common OpenType features would be nice. While some complex OpenType features would not be amenable to the drag and drop or wizard approaches, a lot of them would be, and such assistance would make using FontLab much more productive and straightforward. Even a simple ability to read in feature definitions from one font and apply them to another font would be a welcome capability. This sort of capability could be scripted, but really should be added in a future update of FontLab.

Summary

For GILT users there is no other affordable cross-platform type editor available that even comes close to FontLab’s capabilities. The program is extremely powerful and most users will never come close to using all its capabilities (the PDF manual’s 716 pages provide some idea of the complexity of the program). It will do almost anything the typical GILT user is likely to even consider doing, and for working with complex script languages (such as Arabic) there is no realistic and affordable competition to speak of. Fontographer is increasingly out of date and cannot even open many current fonts, much less edit them, so FontLab represents the clear choice for linguistically savvy users at this time. FontLab’s encyclopedic capabilities are a real strength, but also a weakness - it is not a program suitable for casual or infrequent use, and the interface is not as intuitive as it could be. It is really a tool aimed at a professional audience, not at users who only occasionally need to tweak fonts.

FontLab, despite any quibbles I may have with it, is clearly the best product of its sort on the market, and at $549 US ($299 for competitive upgrades from Fontographer) it is reasonably priced. Support from the developers via e-mail was quite good (I had answers to all questions within 24 hours). FontLab, however, lacks on-line help, so the only help resource available on a local machine is the PDF manual (a paper manual costs $39.95 extra), which is inconvenient on-screen. On-line help should be a priority for future updates, and I would strongly suggest purchasing the manual if FontLab is to be used very often.

Despite its complex interface and the need for simplification of common tasks, I would highly recommend FontLab to any users who need to generate fonts for use in multilingual workflows. The program was clearly designed from the ground up with international needs in mind, and this is where the program truly shines.

More information about FontLab can be found at the FontLab website.