Experience with OpenType Font Production

Sivan Toledo∗and Zvika Rosenberg† 22nd January 2003

1Introduction in Hebrew fonts. For further information about the Hebrew script, see [1, 13, 14]. This article describes the production of a large The initial objective of the project was to convert number of Hebrew OpenType fonts. More specif- older fonts into the new OpenType format. This ically, we describe the production of OpenType was motivated by the concurrent development of fonts with TrueType glyph descriptions and with AdobeInDesign2.0ME(middleeastern),thefirst advanced typographic layout features. The project high-end page-layout program to support Hebrew was conducted by MasterFont Studio Rosenberg, a OpenType features. Microsoft’s Office XP also sup- large Hebrew digital font foundry in Tel-Aviv, with ports these features, so InDesign was not the only assistance from Sivan Toledo from the School of motivator.Butitquicklybecameevidentthatthe Computer Science in Tel-Aviv University. same tools that would be necessary to convert the Hebrew is a right-to-left script that is used in old fonts to the new format could also be used one of two ways: with or without . Most to streamline the entire font production process at Hebrew texts are printed almost without any dia- MasterFont. Therefore, the project had two objec- critics, but childern’s , poetry, and bibles are tives: to convert the old fonts to the new format, printed with diacritics. Even texts that are printed and to streamline the production process. without diacritics use them occasionally to disam- The rest of the paper is organized as follows. The biguate pronounciation and meaning. The diacrit- next section provides background on font formats. ics in children’s books and poetry are vowels and Section 3 describes how positioning in- consonant modifies, which are called nikud in He- formation is represented in MasterFont’s old fonts. brew (meaning “to add points”). Bibles also use a Section 4 describes the objectives of the project, third kind, cantillation marks, which are not treated and Section 5 describes the software tools that we in this article (but see [4, 5] for a thorough treat- used to achieve these objectives. The overall pro- ment). Hebrew diacritics are quite hard to support duction process is described in Section 6, and our in fonts, since there are 15 of them and 27 letters, conclusions from this development and production with up to 3 diacritics per letter. Even though not experience is described in Section 7. all the combinations are grammatically possible, there are too many combinations to support them conventiently using precomposed glyphs. In ad- 2FontsFormats dition, diacritics must be positioned relative to the base letter visually, rather than mathematically. For This section describes the OpenType font format example, the below-baseline diacritics must be set and other relevant font formats. Unfortunately, the below the visual axis of the letter [14], not below term OpenType is somewhat vague, so this section its mathematical center. This means that ligatures, also establishes a more precise nomeclature. pair kerning, and simple mathematical centering alone are insufficient for correct placement of dia- critics. In addition to diacritics, Hebrew fonts can Type 1, TrueType, and Early Extensions also benefit from pair kerning, although until re- The first widely-accepted device-indepenent font cently, pair kerning was not particularly common format was the PostScript Type 1 format [9]. Adobe

∗ started selling retail Type 1 fonts in 1986, and pub- School of Computer Science, Tel-Aviv University, Tel-Aviv lished the specification in the late 1980’s, after Bit- 69978, Israel. Email: [email protected]. †MasterFont Studio Rosenberg, 159 Yigal Alon Street, Tel- stream figured out how to produce Type 1 fonts Aviv 67443, Israel. Web address: www.masterfont.co.il. (prior to that the specification was proprietary and

1 only Adobe could produce Type 1 fonts). Type 1 none became widely used. Adobe introduced the fonts consist of two or three main parts: scal- Multiple Master font technology [10, 11], which al- able hinted glyph descriptions, metric information, lows users to interpolate between fonts in a family. which include glyph dimensions, advance widths, This enhancement transforms the font family from and pair kerning, and possibly bitmaps for screen a discrete set to a continuous spectrum. For ex- previewing. Today most systems can rasterize the ample, there aren’t just medium and bold fonts, for scalable glyph descriptions so the bitmaps are usu- example, but a continuous weight axis. Apple intro- ally no longer necessary; Adobe distributes freely duced GX fonts [6] (now called AAT fonts), which the Manager which is a Type 1 raster- are TrueType fonts with additional tables that al- izer for older Windows and computers low continuous interpolation, like Multiple Master without a built-in rasterizer. Type 1 fonts are rela- fonts, and which enable high-end typographic fea- tively easy to design and produce, and today there tures. In particualr, GX fonts can support multiple are tens of thousands of commercial Type 1 fonts. glyphs for a single character, such as swash, small The next widely-accepted device-indepenent caps, or old-style figures, they can reorder glyphs, font format was the TrueType format [6, 2], which and so on. Neither format became widely accepted was invented by Apple in the late 1980’s, as part of by font vendors, probably because the fonts were a collaboration between Apple and Microsoft, and toohardtoproduce.Nomajorfontfoundrybe- became the native scalable font format for both Ap- sides Adobe produced Multiple Master fonts, and ple Macintosh computers and Windows computers. only a few GX fonts were produced by Bitstream In a TrueType font, all the data associated with the and Linotype. font, such as glyph descriptions, metric informa- tion, administrative informaion (font name, for ex- OpenType ample), and possibly bitmaps, are placed in a single file, which is organized as a collection of tables. OpenType is a new font format [3] that Microsoft For example, one table contains glyph description, and Adobe specified collaboratively. The format another character-to-glyph mappings, yet another was first used, under the name TrueType Open, in table contains kerning pairs, and so on. theArabicversionofWindows95, whichwasintro- The kinds of data in a TrueType font are almost duced in 1996. Adobe later joined the specification identicaltothekindsofdatainaType1font, effort and the name was changed to OpenType. but they are organized differently and sometimes OpenType adds three capabilities to the True- represented differently. Most importantly, glyph Type format: advanced layout features, support for descriptions and hints for low-resolution rasteriza- Type 1 glyph descriptions, and digital signatures. tion are represented differently. In a Type 1 font, The advanced layout features are supported by five glyphs are represented using cubic-spline outlines new tables: , that define glyph properties and with declarative hints. In a TrueType font, glyphs glyph sets, , which defines glyph substitution are represented using quadratic-spline outlines and rules, , which speficies positioning informa- a low-level programmable hinting language. Type 1 tion, , which provides justification information, outlines are easier to design and hint, and most and , which provides baseline-adjustment in- designers use cubic splines when designing fonts. formation. These features were designed to support Well-hinted TrueType fonts are hard to produce, layout of text in complex scripts such as , He- but they can achieve pixel-perfect rasterization at brew, Indic, and east Asian scripts (Hebrew is by no low resolutions, something that Type 1 fonts can- means the most complex), and to support high-end not achieve. Virtually all font editors can convert typographic features such swash letters and deco- one type to the other. the conversion of TrueType rative ligatures, old-syle and proportional figures, outlines to Type 1 outlines is lossless, but the other and small capitals. direction only produces an approximation. How- The support for Type 1 glyph descriptions is de- ever, the approximation of a Type 1 outline by a signed to allow lossless conversion of Type 1 fonts TrueType outline can be made arbitrarily accurate to a TrueType-like table-based file format. Such and font editors produce approximations that are fonts use two new tables,  and , to store visually indistinguishable from the original. Hint- a losslessly-compressed Type 1 font. Technically, ing information is usually also converted, but not the format of the  table corresponds to that of as well. PostScript Type 2 fonts [12], also known as the Both Adobe and Apple introduced enhance- compactfontformat,buttheessenseofthefor- ments to these font formats during the 1990s, but mat is a lossless representation of Type 1 glyph

2 descriptions (outlines and hints). The need to sup- glyphs and with advanced layout tables, and  port two kinds of glyph descriptions and hints con- for fonts with TrueType glyphs but no advanced stained the design of the layout-related tables, in the layout tables. sense that positioning information in the  ta- Microsoft’s main interests in the OpenType for- blecouldnotbehintedusingthenormalTrueType mat lies in supporting complex scripts in Windows, or hinting language; a different hinting mechanism with initial emphasis on Arabic and later on Indic is used, which supports both Type 1 and TrueType scripts, and in tighter operating-system/font inte- glyphs. gration using digital signatures. Adobe’s main in- The support for digitally signing fonts, which terests in the format lies in exploiting TrueType’s uses the  table, is meant to allow users and font- advantages, mainly the support for non-latin char- using software to verify the authenticity of fonts. acter encodings and the convenient single-file for- For example, future operating systems might re- mat, and in providing its fonts and applications quire that certain system fonts are digitally signed easier access to so-called expert glyphs, such as by the operating-system’s vendor, thereby prevent- old-style figures and small capitals [8]. ing modified versions of these fonts from being used instead. For independent font vendors, there Windows and Macintosh Font Files is currently little benefit in digitally signing fonts, since users currently do not have means to verify Differences in the way font files are stored on dif- these signatures, and since fonts rarely pose secu- ferent platforms cause a few additional difficulties rity or stability problems to systems. during font production. OpenType fonts with TrueType outlines can be On Windows and Unix/Linux systems, a True- used by any TrueType-capable software, since ex- Type or OpenType font is stored in a single file. A cept for extra tables (which are allowed by the True- Type 1 font is represented by up to four files: a pfb Type spefication), the fonts are also valid TrueType or pfa file that stores the glyph descriptions and a fonts. Software such as rasterizers, layout engines, character-to-glyph encoding, an afm and/or a pfm and printer drivers can simply ignore the extra ta- files that store metric information, as well as the bles. OpenType fonts with Type 1 outlines require encoding, but no glyphs, and an inf file that stores special support in rasterizers and printer drivers, administrative infomation about the font. On Win- support beyond that required to support Type 1 and dows system, only the pfb and pfm files are used. TrueType fonts. In principle any TrueType-capable On Macintosh systems, there are multiple ways layout engine can use any OpenType font, since the to store fonts. The Macintosh metric and layout information are compatible (an supports two byte streams per file. One is called exception is pair-kerning information, which can the data fork and the other the resource fork, which appear in either the ‘kern’ table or the os table was meant to store application resources such as or both in a font with TrueType glyphs, but only localized strings, icons, and so on. The format of in the  table in a font with Type 1 glyphs). To the resource fork allows multiple resources to be emphasize the fact that OpenType fonts with True- stored in a single file. Before MacOS X (that is, Type glyphs can be used by any TrueType-capable before version 10), fonts were always stored in the software, whereas special support is required for resource fork of files whose data fork was empty. fonts with Type 1 fonts, files containing the first Fonts and font families are represented by several kind use the ttf or ttc extension, whereas files kinds of resources, such as the  resource that containing the second kind use the otf extension. describes an entire family (regular, bold, italic, etc.), So what is an OpenType font? According to the the  for storing TrueType fonts, the  and Microsoft/Adobe specification, any font that con-  for storing bitmap fonts, and so on. The fonts forms to the specification, including both TrueType of a family are usually stored in a single file called and Type 1 glyphs, with or without advanced lay- a suitecase, whose resource fork contains multiple out tables and digital signatures. This is somewhat resources. The Macintosh also associates a file type confusing, especially since the file icons in Win- (separate from the extension) and a creator code dows do not correspond to the glyph descriptions with each file. Font files need to have a specific (Windows 2000 and XP use the ‘O’ icon for otf type to be recognized as such by the Macintosh’s files and for ttf or ttc files if the fonts have a  operating system. table, and the ‘TT’ icon for all other ttf files). We Storing fonts in multiple resources within a single will use the acronyms  for OpenType fonts with file, and storing the font data in the resource fork Type 1 glyphs, - for fonts with TrueType rather than the data fork creates problems when

3 fonts are moved between platforms. To address this Font developed a few years ago a positioning aid issue, Apple introduced new ways to store fonts in for the Macintosh. This software, called Mapik-Ve- MacOS X. First, suitecases can now be placed in the Day, is a Macintosh system extension that selects a data fork, using a format called a dfont file (after its diacritic glyph according to the base letter. Fonts extension).Thisformatisessentiallyatraditional designed to work with this software have three sets Mac font file, but in the data rather than the resouce of diacritics: one for narrow letters, one for wide fork. Second, MacOS X also allows Windows-style letters, and one for medium-width letter. The dia- packaging of TrueType and  files in a single file critics in all sets usually have the same shapes, and in which the font data is stored in the data fork with all have zero advanced widths, but each set has dif- no header or trailer. ferent sidebearings. The three qamats glyphs, for example, all have the same shape and zero width, and all print to the right of the insertion point (so 3 Diacritic-Positioning Infor- they appear below the preceding letter in a right- to-lefttextrun),buttheamountofrightshiftingis mation in Older Fonts different. The software essentially divides the let- ters into three categories, each of which has its own Masterfont’s existing fonts used three mechanisms set of diacritics. for positioning diacritics. These mechanisms were These two mechanisms, the precomposed glyphs developed over a long period of time—each addi- and the three sets of diacritics of different widths, tional mechanism was designed to correct deficien- essentially mimic hot-led diacritics. cies in previous ones. These two mechanisms allow fairly good control The first mechanism uses a number of precom- over positioning, provided the font is designed for posed glyphs. These are used for dagesh,adotthat this system in mind. In particular, special attention appears inside letters, and which must be carefully must be given to the left sidebearings of base letters, positioned to prevent overstriking the letter itself. to ensure that the diacritics from the appropriate Such combinations are also used for shin/sin dots, category are well placed under them. for diacritics attached to a final letter (only two To allow more precise control over diacritic po- combinations are used in modern Hebrew), and a sitioning, MasterFont began to use explicit posi- few other cases. There are code points for tioning information in the fonts. These are stored these glyphs, as well as code points in the MacHe- in the kerning table of the font, even though they brew 8-bit encoding, and they are used by both are not real kerning pairs, since the insersion point Macintosh and Windows systems. should not move after the positioning adjustment. On the Macintosh, precomposed glyphs are also For example, a kerning pair alef-qamats with value used to place diacritics on particularly difficult let- 35 means that the qamats glyph must be shifted ter: resh, dalet,andqof.Thefirsttwoarewide relative to the alef glyph by 35 font units. The in- letters that have a single vertical stem at the right, sertion point remains exactly after (to the left of) under which below-baseline diacritics should be the alef,asifnoadjustmenttookplace.Thisin- placed. Incorrect placement under these letters formation is not used by the Macintosh operating looks awful. The qof is the only non-final letter system, but a some Adobe applications can use it. with a descender, so special attention is required to MasterFont currently has 86 fonts with this level prevent the below-baseline diacritics from colliding of diacritic positioing, which is essentially the set with the descender. These glyphs do not have Uni- of fonts designed for work. In addition, there code code points, but they are used in all the Mac’s are many more display fonts with pair kerning in- Hebrew fonts, including the fonts bundled by Ap- formation but without elaborate diacritic support. ple with the operating system. These glyphs appear to have been added by Apple quite early on. They do fix the most serious placement cases, but they 4Objectives do not fix all the placement problems. Further- more, this glyph set appears to have been designed Now that the setting has been described, we can by somebody without much expertise in Hebrew, enumerate the objectives of this project in more sincesomeoftheprecomposedglyphscannever detail. appear in a text (e.g., dalet with a hataf-patah). First and foremost, we wanted to convert the di- Since the precomposed glyphs are insufficient for acritic positioning information in the existing fonts correctly positioning all the combinations, Master- to OpenType advanced-layout tables. We wanted

4 to do this without specifying any additional po- significant. On the other hand, on pre-2000 Win- sitioning information. This restriction was moti- dows and pre-X Macs,  fonts require the Adobe vated by several reasons: Type Manager utility, which is free but nonethe- less requires downloading and installing by the end • Efficiency; there was no point in doing ex- user. Also, some applications, most importantly tra design work on fonts that already produce Microsoft’s PowerPoint, cannot use  fonts even perfecly-positioned texts. For example, there on systems that do support them (this is true for is no point in specifying positioning informa- both PowerPoint 2000 and PowerPoint 2002). Fi- tion for a combination represented by a care- nally, one of the tools we used in the production of fully designed-precomposed glyph. the fonts, Microsoft’s , provides much better support for - fonts than for  fonts; this • Correctness; by not specifying new position- is described more fully in the next section. Given ing information, the chances of introducing the clear disadvantages and only slight advantage new positioning bugs are minizized. of  fonts, we decided to produce - fonts.

• Continued support for older applications; we wanted to be able to produce additional new 5Tools fonts that would be able to work not only in OpenType applications, but also in older ap- The production of the fonts uses a number of soft- plications. By building new fonts according ware tools, which we describe in this section. We to the old specification and automatically con- also describe alternatives to some of the tools and verting them to OpenType, the foundry would explain our choice of tools. be able to offer customers either an OpenType font or an old-syle font for legacy applications. Assembly of the Advanced Typographic Tables Second, we wanted to automatically produce fonts for both the Windows and Macintosh platforms Thetoolthatweusedtoconstructtheadvanced (Windows fonts also work on Unix and Linux). typographic tables in the fonts is Microsoft’s Visual More specifically, we wanted to produce the fonts OpenType Layout Tool (). Given a font, we for the two platforms using the same source fonts, automatically construct input files for , and rather than generate a Windows font and convert use it to construct a derivative font with appropriate it, and then generate a Mac font and convert it. , , and  tables. This meant that the glyph sets for Windows and Adobe’s OpenType Font Development Kit () Mac fonts had to be merged, since previously the can perform a similar function. However, when we foundry used different glyph sets for each platform. started the project, the  had incomplete support Furthermore, if possible, we wanted to have identi- for the  table, which meant that we could not cal finished fonts, except for the suitcase wrappers. use it to convert our Hebrew fonts. The  is also It turned out to be possible. -oriented,inthatitcannotacceptTrueType Two remaining choices had to be made, con- glyphs as input, where as we wanted a -to-- cerning the glyph-description format and the Mac-  conversion, in order not to modify the glyphs packaging format. After some deliberation, we de- or their hints. These restrictions appear to still cided to produce - fonts rather than  hold. fonts. Producing  fonts has one advantage, In addition to , microsoft also distributes namely that the original Type 1 outlines and hints command-line tools that can construct advanced remain intact, whereas automatic conversion is typographic tables, but they are quite old and we used when producing  fonts from the same did not experiment with them. source files. We felt that given the accuracy of Versions 4.0 and 4.5 of FontLab can also pro- the conversion, this had essentially no impact on duce OpenType fonts with advanced typographic high resolution output from printers or imageset- tables. But our understanding has been that the ters. We also felt that modern on-screen rasterizers OpenType support in FontLab is based on Adobe’s that use antialiasing (font smoothing) produce ac-  and hence does not support the required  ceptable output from automatically-hinted and un- mechanisms, so we did not explore this approach. hinted TrueType outlines. Therefore, we felt that Since we used , we would like to comment ’s advantage over - is not particularly on its advantages and disadvantages. V is a

5 visual tool, designed to allow a font designer to vav+holam sequence, which can stand for a specify visually glyph substitutions and position- single long vowel or a consonant followed by a ings. Together with the sample fonts, it is a su- short vowel; there is a single Unicode sequence perb tool for understanding how OpenType layout for both cases, but they should be printed and features work and for prototyping and developing vocalized differently). OpenType layout support. In addition to visual • design,  allows the user to export and im- Defining diacritic positioning information. port the structure of the layout tables or parts of • Defining kerning pairs. the tables into text files with special syntax. Since we had to convert many fonts, we opted for au- We wrote the  program by developing a pro- tomatically generating these files, which are called totype font visually in , exporting the project  project files (vtp) rather than for visually file, and then writing the program so that given constructing each font. On the other hand,  the input file, it generates a similar project file. We does not have command-line options that can be then loaded the resulting project file into  and used to open a font and a  project file and ship inspected the resulting OpenType structure. When an assembled - font. This means that even we discovered problems, we modified the  pro- if the project files are constructed automatically en gram to correct them and so on. This methodology mass, they cannot be processed in batch mode— exploits the two strengths of : the ability to de- each font must be opened using a menu command, sign and inspect OpenType layout tables visually, the corresponding project file must be imported us- and the ability to accept automatically-generated ing another menu command, and the output font input. must be shipped using yet another command. Minor Modifications of Other TrueType Data Extraction and Project File Con- Tables struction We gradually discovered that other TrueType tables To produce the input file for , we had to con- had to be modified to ensure that the fonts perform vert the data in the initial  fonts into  properly. Here are the main modifications that we project files. The format of the  project files perform on the fonts: is complex and undocumented, but quite simple to figure out by comparing the file to the font structure • Weadd code-page-support and unicode-range in the graphical . information to the fonts. This information is We performed the conversion using two custom- used by Windows and Windows applications written programs. Thefirst program, whichiswrit- to determine which scripts a font supports. ten in C, reads a  font and outputs an afm-like text file, which maps glyph indices to PostScript • While we use  to construct the unicode glyph names, and which documents all the kerning character-to-glyph mapping table (a subtable pairs (glyphs in TrueType fonts are stored in an ar- of the ‘cmap’ table), we later add an 8-bit He- ray and are refered to by  using their indices). brew encoding table to support older Mac ap- The second program, which is written in the  plications. This encoding subtable must be language, transforms this information into a  added even if the original TrueType font has project file. The transformation consists of: one, since  regenerates the ‘cmap’ table, and to the best of our knowledge, cannot emit • Mapping each glyph to a glyph name this particular subtable. and Unicode code point(s). • We remove the ‘kern’ table, which contains • Defining glyph groups. diacritic-positioining data that are not true • Defining glyph substitution lookups, for kerning pairs, as described above. exmaple to map normal diacritics to wide • We add a ‘gasp’ table to specify that the fonts or narrow ones, to map glyph sequences to should to be antialiased at all sizes. precomposed glyphs, and in one case to de- compose a precomposed sequence depend- • We make minor modifications to the ‘name’ ing on the preceding glyphs (this supports table, which contains copyright, version, , two meaning and vocalizations of the unicode and other textual information for the end user.

6 Figure 1: One of the OpenType fonts in  along with three types of OpenType lookups that we use to position diacritics: anchor positioning, single contextual substitution, and substitution. Our fonts also use pair-kerning adjustments and more complex contextual substitutions.

7 Some of the modifications are done with a specially- line tools from the MacOS X developer kit to tag written C program. The other modifications are the suitcases with the required file type and creator performed by converting the appropriate table code. to  format using Apple’s ftxdumperfuser We also used a script to automatically scan an en- command-line tool for MacOS X, modifying the tire directory with - fonts and classify them  file using  and  programs, and then into families. The classification is done using the fusing the resulting -formatted table to the font family name field of the font. Once the classifica- file, again using ftxdumperfuser. tion is made, the script invokes ufond to package We perform some of the modification using a C the fonts of the family into a suitcase. program and some using the Apple tool because when we started the project, the Apple Font Tools for MacOS X had not yet been released. We there- 6 The Production Process fore wrote a custom C program to perform the modifications we found necessary. As testing pro- The final production process consists of four stages. gressed and we discovered more required or desired The prevolt stage is performed by a script that pro- modifications, we switched to using the Apple tool, cessesalltheinputfontsinagivendirectory. which was easier than extending the C program. For each input file, the script generates a modi- One problem with the  format that Apple uses fied  file and a volt project file. The modifica- to describe font tables is that simple text processing tion to the input files that we perform at this stage tools like  and  do not understand ’s hi- involve fixing the ‘post’ table to overcome an ap- erarchical structure. But for relatively simple mod- parent Fontographer bug, upgrading the version of ifications, the combination of ftxdumperfuser the ‘OS/2’ table and adding to it Unicode-range and and  or  scripts works. code-page information, and removing the ‘kern’ ta- There is another tools that can perform ble. The volt project file is produced by invoking TrueType-to- and -to-TrueType conver- the C program that generates an afm-like text file sions, Just van Rossum’s 1. We experimented with glyph infomation and kerning and diacritic- with this tool, which is written in the Python lan- positioning information, and converting that file to guage, but we could not install it successfully. The avoltprojectfileusingacustomprogram. trouble was that  uses a number of other Python In the second stage, each modified  file is packages, for example, to perform numerical cal- opened in , the corresponding project file is culations, which did not install propely on our sys- imported, and the resulting font is shipped out. tems. But assuming that these issues in  are This requires only three menu commands in  easily solvable, it is certainly an alternative to the and clicking ‘okay’ a couple of times, but it is still Apple tools, and at least in principle, it is a multi- the most time consuming stage of the production platform tool that runs on Windows, MacOS, and process. Linux. The next stage, the postvolt stage, processes all the files shipped from  in a given directory. General-Purpose Font Editors Ascriptinvokesftxdumperfuser afewtimeson each font, to add a MacHebrew encoding subtable, Although no general-purpose font editor was used to fix the ‘name’ table, and to add a ‘gasp’ table. for the actual conversion, we did use two font Although some of the processing can be moved editors to produce the input font files and to in- from the prevolt to the postvolt or vice versa, some spect fonts that seemed to have problems. We used processing must be done before  can process Fontographer to produce the input files to the con- the font and some processing must be done after version process, and we used PfaEdit to inspect  ships the font. Hence, a prevolt and a postvolt fonts. stages are necessary. The final suitcases stage again uses a script to Machintosh Suitcase Generation process an entire directory. The script first extracts the family name from each font file. Next, the script We used the ufond command-line program from finds all the font files that belong to a single family, 2 George Williams’  package to package - and invokes ufond on them to create a suitcase.  fonts into suitcases, and we used command- The suitcase is created by ufond in the data fork of 1http://www.letterror.com/code/ttx/ a file. We then move the font data to the resource 2http://fondu.sourceforge.net fork of the font file, and tag it with appropriate type

8 שֶׁלְָך :Ligature substitution זְ ָמן :Anchor positioning וְגָם :Contextual substitution ָמצוֹת .vs ִמצְוֹת A-Reg.TTF A-Ita.TTF Insensitivity to mark orderings: גָּל dalet+dagesh+qamats . . . B-Reg.TTF גָּל dalet+qamats+dagesh . . .

prevolt script processes Figure 3: Hebrew diacritic positioning using Open- an entire directory Type features. The first three lines show how Open- Type features utilize the mechanisms of older fonts. A-Reg.FIXED.TTF + A-Reg.VTP These examples correspond exactly to the exam- A-Ita.FIXED.TTF + A-Ita.VTP ples shown in Figure 1. The fourth line shows . . . a new application of contextual substitution that B-Reg.FIXED.TTF + B-Reg.VTP yields correctly-positioned glyphs for two identi- . . . cal unicode sequences with different grammatical meanings and different vocalizations. The last two Microsoft VOLT processes lines show that the OpenType features have been each font separately encoded in a way that prints all valid diacritic se- quences in the same way, as mandated by Unicode. A-Reg.VOLT.TTF The sample was prepared using Adobe InDesign A-Ita.VOLT.TTF 2.0 ME. . . . B-Reg.VOLT.TTF . . . and creator codes. The automatic recognition of the font files that belong to each family minimizes postvolt script processes the chances for errors that could occur if a family- an entire directory configuration file was written by hand.

A-Reg.OT.TTF Due to the use of ftxdumperfuser,theprevolt A-Ita.OT.TTF and postvolt stages must be performed on a Ma- . . . cOS X machine. The  stage must be performed B-Reg.OT.TTF on a Windows machine. The suitcases stage is also . . . performed on a MacOS X, in order to move the font data to the resource fork and in order to assign type suitcases script processes and creator tags; non-Macintosh operating systems an entire directory do not support these file-system features.

A.OT.SUIT בְֵּראשִׁית, בָָּרא ֱאֹלהִים, ֵאת הַשָּׁ ַמיִם, וְ ֵאת B.OT.SUIT הָ ָאֶרץ. וְהָ ָאֶרץ, הָיְתָה תֹהוּ וָבֹהוּ, וְחֹשְֶׁך, עַל פְּנֵי . . . תְהוֹם; וְרוּחַ ֱאֹלהִים, ְמַרחֶפֶת עַל פְּנֵי הַ ָמּיִם. וַיֹּ ֶאמר ֱאֹלהִים, יְהִי אוֹר; וַיְהִי אוֹר. וַיְַּרא ֱאֹלהִים .Figure 2: An overview of the production process ֶאת הָאוֹר, כִּי טוֹב; וַיַּבְ ֵדּל ֱאֹלהִים, בֵּין הָאוֹר וּבֵין Thefiguresshowstheinputandoutputfilesfor each stage and how that stage operates. The postvolt הַחֹשְֶׁך. וַיִּ ְקָרא ֱאֹלהִים לָאוֹר יוֹם, וְלַחֹשְֶׁך ָקָרא stage produces the final font files for Windows and לָיְלָה; וַיְהִי עֶֶרב וַיְהִי בֹ ֶקר, יוֹם ֶאחָד. MacOS X, and the suitcases stage produces the final font files for any Mac operating system, X or older.

Figure 4: The first few phrases of Genesis, type- set in Adobe InDesign 2.0 ME using an OpenType version of Henri Fridlaender’s Hadassah .

9 7Conclusions hints, then again to add the Euro symbol, then again to add non-latin glyphs for supporting addi- This project led us to several conclusions concern- tional scripts. In between, special versions might ing OpenType and font production in general. have been produced for bundling with operating systems or software packages. In the non-latin font Reflections on Font Production market, special versions might have been produced to work with various layout programs. And to- Fonts are atypical objects that present special chal- day,thesamefontdataisusedtoproduce- lenges to their manufecturers. The uniqueness of and/or  fonts. Even a relatively young foundry fonts is caused by a combination of factors that is like MasterFont has font data going back about 15 not present similar products. years. First, fonts are highly complex data objects. Forth, font foundries are typically small busi- WhileType1fontsarefairlysimple,TrueType, nesses or small business units [7]. This limits their OpenType, and other advanced font formats are ability to invest in custom programming to auto- complex, with hundreds of individual fields that mate font production. This again is a particular client software uses. problem in the non-latin font market, where fonts Second, fonts, especially those produced by in- aremorespecialized. dependent foundries, are supposed to work with a The longevity of font data from which new font variety of operating systems and software applica- files must be occasionally produced, together with tions. Since different clients access different parts the fact that many foundries accumulate hundered of font data, a font that tests perfectly with a given or thousands of fonts, should imply that automa- setofclientsmightfailonanotherclient,aswe tion should be widely employed in font produc- have often discovered during the production pro- tion. That is, producing a new font by launching cess. To compound the problem, font-file specifi- a font editor, loading an older version, making the cations specify the format and intent of data fields, required changes, and generating a new font, is in- but they specify only loosely the behavior of client efficient when a large number of fonts must be pro- data.Thisisoftendoneonpurpose,toaccomo- duced. Manual production is also prone to errors date the behavior of older existing clients, but it and hence requires more testing than an automatic makes it almost impossible to create working fonts conversion that processes all the fonts in exactly the without extensive testing. Let us give an example: sameway.However,thesizeofmostindependent are the glyph names in a TrueType or OpenType foundries preclude large investments in custom au- font significant, or are they present only to allow tomation (that is, paying programmers to automate printer drivers to download the font into a printer font production). in a consistent manner? Presumably, applications This problem has been addressed recently in should use the encoding table in the ‘cmap’ table to three ways: find glyphs, not the PostScript names of the glyphs. But if some application uses glyph names instead, a • Microsoft, Adobe, and Apple, who need to font with variant names would not work in that ap- encourage font production, release free font- plication (we note that even Microsoft- and Apple- production tools (Adobe’s interest in indepe- supplied fonts use names for the Hebrew glyphs dent font production stems from its role as a that are inconsistent with the Adobe Glyph List). vendor of application, not from its role as a Third, font data, such as glyph outlines, hints, font foundry). Microsoft has released  and metric information has a very long life, but and a large number of other tools for hinting, font files have a shorter life span. The outlines and adding digital signatures, editing strings in a metrics of widely-used fonts by foundries such as font, and so on. Adobe has released the , Linotype, Bitstream, or Agfa-Monotype are prob- and Apple has released a number of font tools. ably more than 20 years old, clearly an old age in To a large extent, the three companies release the digital world. On the other hand, font files the tools that they use themselves to produce need to be recreated from this data once in a while. fonts. Still, the effort in publicly releasing and Font data that might have been used to create pre- supporting these tools is significant, and the PostScript fonts, were used again in the mid 1980s wide availability of these tools does help inde- to create PostScript Type 3 fonts, then PostScript penent foundries. In some cases the tools are Type 1 fonts, then TrueType fonts. The TrueType not ideal for automated production. For ex- font might have been upgraded once with better ample, the inability of  to process a font

10 without invoking the graphical user interface to large font foundries, but are usually not evident slows down production. to smaller foundries.

• General-purpose font editors now include Reflections on OpenType scripting languages. Specifically, FontLab uses Python and PfaEdit it’s own scripting lan- Will the OpenType format, and in particular the guage. These tools will reduce the cost of advanced typographic layout, succeed, or will it automation and hence of font production, es- fail like Multiple Master fonts and GX fonts? This pecially if scripts can be applied to a font from question is important for font vendors, applica- the command line (this is true for PfaEdit, and tion developers, and font consumers, who all need perhaps also for FontLab). Obviously, this ap- to decide whether or not to invest in OpenType. proach requires programming, but at least the There are several reasons to believe that Open- programming environment is the familiar font Type layout will become successful and widespead. editor. One remaining problem in this ap- First, both Adobe and Microsoft are pushing this proach is that these font editors read the font technology. In particular, both companies provide data into their own in-memory data structures font producers with free production tools, Adobe and then generate a new font, which can have hasconvertedalmostitsentiretypefacelibraryto side effects on tables that are not supposed to OpenType (which was not the case with Multiple be modified by a script. FontLab is careful not Masters), and Microsoft has provided application to modify data it does not need to (for example, developers with both tools to utilize OpenType lay- not to modify TrueType glyphs unless glyphs out features (through the Uniscribe and OTLS li- are edited), but PfaEdit regenerates TrueType braries) and with assistance with developing lay- glyphs whenever it outputs a font file. out engines. Both companies already produce ma- jor applications that exploit OpenType’s layout fea- • Individuals produce powerful free tools that tures, namely Office XP and InDesign. Other com- can assist in automating font production. panies are also developing OpenType layout en- These include  and PfaEdit. One prob- gines, such as IBM’s ICU open-source engine. Sec- lem with using these tools in commercial font ond, the technology is essential for presenting text production is that they tend to be less stable. in some scripts, such as Indic scripts, and essential One might expect that they would not be as for presenting Arabic and Hebrew text with dia- well supported as commercial tools, but that is critics (Arabic and Hebrew without diacritics can not always true: George Williams, for exam- be set without OpenType layout features). In par- ple, the creator of PfaEdit, provides excellent ticular, Microsoft has used OpenType layout in its and prompt support. Arabic fonts and operating systems for years now. Third, the OpenType format has been designed to Font production requires careful management over make font design easy, which was not the case for time of source files, deliverables, and software. Multiple Masters and GX. The structure of Open- Source files are used to produce fonts over many Type’s layout support is declerative. For example, years, and they need to be updated by adding the font designer can declare that a certain glyph glyphs, metric infomation, and so on. When the substitution only occurs in a certain glyph context source files are updates or when deliverables in (preceding and following glyphs). The algorithmic new formats are needed, deliverables are produced question of how to recognize the context is left to again. It is beneficial to automate new production the layout engine. In contrast, GX’s structure is cycles as much as possible, especially when many procedural/programmable, and the font designer fonts are involved. Since foundries often cannot must specify a finite-state machine that the lay- invest significant funds in custom programming, out engine uses to detect the context. In general, standard font-production tools must support au- declarative font technologies like outline fonts and tomation and re-production. The scripting support Type 1 hinting have been more successful than pro- in FontLab is a step in this direction, and essentially grammable technologies like TrueType hinting, GX anycommand-linetoolisusableinscript-driven state machines, or metafont. (TrueType hinting is batch processing. But other tools, like , do not unsuccessful in the sense that the cost of hinting support automated production and re-production. causes most fonts to remain unhinted or automati- The importance of automation and the require- caly hinted.) The obvious reason is that most font ments of multiple production cycles may be evident designers are graphic designers by training, rather

11 than programmers. line from http://www.microsoft.com/ One must acknowledge, however, a few problems typography. related to OpenType layout. First, the main ben- [4] Yannis Haralambous. the holy efit that OpenType brings to the Latin-script mar- bible in hebrew, with T X. TUGboat, ket are alternate glyphs, especially small caps, old- E 15(3):174–191, 1994. Also appeared in the style figures, proportional figures, and swashes. But Proceedings of EuroT X 1994,Gdańsk. these glyphs have been available for years, although E in separate small-caps, old-style-figures, and ex- [5] Yannis Haralambous. “tiqwah”: a typesetting pert fonts. Using these separate fonts is not much system for biblical hebrew, based on TEX. Bible harder than using OpenType layout features: in- et Informatique, 4:445–470, 1995. stead of marking a run of text or a character style with OpenType features, the document designer [6] Apple Computer Inc. TrueType Reference or marks the text or style with Manual, 1999. Available online from http: an alternate font. This makes it a bit harder to //fonts.apple.com. switch font families, but the difference is not that [7] Emily King. New Faces: Type Design in dramatic. It is interesting to note that Adobe did the First Decade of Device-Independent Dig- notgoallthewayinitseffortstomakeOpenType ital Typesetting. PhD thesis, Kingston Uni- layout useful. For example, using OpenType fea- versity, 1999. Available online at http: tures to automatically select optically-scaled glyphs //www.typotheque.com under ‘Articles’. would have made optically-scaled fonts easier to use, but Adobe kept optically-scaled glyphs in sep- [8] Thomas W. Phinney. TrueType, PostScript arate fonts, probably in order to support different Type 1, & OpenType: What’s the differ- pricing for fonts with and without optical scaling. ence? PDF document available online at http://www.font.to/downloads/TT_ PS_OT.pdf, 2001. Acknowledgements [9] Adobe Systems. Adobe Type 1 Font Thanks to Microsoft’s Paul Nelson for answer- Format, 1990. Avilable online from ing numerous OpenType-related questions on the http://partners.adobe.com/asn/ -community’s message board, on the Open- developer/technotes/main.html. Type mailing list, and via private email exachanges. Thanks to WinSoft’s Pascal Rubini for answering [10] Adobe Systems. Type 1 Font Format questions regarding the behavior of InDesign 2.0’s Supplement, 1994. Technical Speci- Hebrew layout engine, and regarding the Hebrew- fication #5015, Avilable online from diacritic-handling mechanisms of older applica- http://partners.adobe.com/asn/ tions. Thanks for George Williams for making developer/technotes/main.html. PfaEdit available. Some of the historical informa- [11] Adobe Systems. Designing Multiple Mas- tion concerning font formats was gathered from ter , 1997. Technical Spec- replies to a question that Adam Twardoch posted ification #5091, Avilable online from on the OpenType mailing list. http://partners.adobe.com/asn/ developer/technotes/main.html. References [12] Adobe Systems. The Type 2 Charstring Format, 2000. Technical Specifi- [1] The Unicode Consortium. The Uni- cation #5177, Avilable online from code Standard Version 3.0, 2000. Parts http://partners.adobe.com/asn/ of the standard are available online at developer/technotes/main.html. http://www.unicode.org. [13] Sivan Toledo. A simple technique for type- [2] Microsoft Corporation. TrueType 1.0 Font setting hebrew with vowel points. TUGBoat, Files, Technical Specification Revision 1.66, 20(1):15–19, 1999. 1995. Available online from http://www. microsoft.com/typography. [14] Ada Yardeni. The Book of the Hebrew Script: History, Palaeography, Script Styles, - [3] Microsoft Corporation. OpenType Specifi- phy and Design. Carta, Jerusalem, 1997. cations Version 1.4, 2002. Available on-

12