Version 1.51, October 1, 1997
(C) Copyright 1995-1997 by Thomas Phinney, but permission is granted to duplicate and distribute this information for any non-profit purpose, as long as it is reproduced in full, unedited, and the author and copyright information (this paragraph) is retained. The author also requests that he be contacted by e-mail prior to any publication or redistribution, so that the most recent version may be used. Versions of this document are available in ASCII text, HTML and Acrobat PDF (both 2.0-compatible and Web-optimized for Reader 3.0). Special thanks to David Lemon, Kathleen Tinkel, Tom Rickner, and Kaspar Brand for their invaluable feedback; however, any errors are the author's sole responsibility.
TrueType (TT) and PostScript Type 1 (PS1) are both multi-platform outline font standards for which the technical specifications are openly available. "Multi-platform" means that both font types are usable on multiple sorts of computer systems. "Outline font" means that they describe letter shapes ("glyphs") by means of points, which in turn define lines and curves.
This representation is resolution independent, meaning that outlines, by their very nature, can be scaled to pretty much any arbitrary size. Depending on the particular program being used and the operating system it's run under, there may be upper and lower limits to the size the font can be scaled to, but few users will ever encounter these limits.
An outline font must be represented by the dots of the output device, whether it's screen pixels or the dots of a laser, ink-jet or wire-pin printer. The process of converting the outline to a pattern of dots on the grid of the device is called "rasterization."
When there aren't enough dots making up the glyph (such as at small si= zes or low resolutions), there can be inconsistencies in the representation of certain letter features, at a single size, due to different rounding based on how the outline happens to sit on the grid. A common form of this is that the widths of the letter stems can vary when they shouldn't. Worse, key features of the glyphs can disappear at small sizes.
However, PostScript Type 1 and TrueType fonts both have a means of dealing with these inconsistencies, called "hinting." This consists of additional information encoded in the font to help prevent these problems.
PostScript predates TrueType by about six years. First, we had many different formats for digital fonts, none of which were standardized. Then Apple adopted Adobe's PostScript page description language (PDL) for its Apple LaserWriter printer in 1985. This, combined with the introduction of desktop publishing software, sparked a revolution in page layout technology.
Soon the PostScript language was adopted for use in higher-end imagesetting devices, and became the native operating mode and language of many graphics programs as well. PostScript's dominance seemed assured. Adobe was in complete control of the PostScript technology at this point. Although the command structure of the PostScript language was publicly available, and it was possible for someone to build a PostScript interpreter to compete with Adobe's rasterizing software, it wouldn't be able to interpret the hints. This was because the PostScript font specification for Type 1 fonts, which included hinting, was not publicly available. Adobe had only released the specifications for Type 3 fonts, which had some minor advantages, but did not image well on low resolution devices.
It rapidly became obvious to the major system software creators (Apple, Microsoft, and later IBM) that it was important to have scaleable font technology supported at the level of the operating system itself. But neither Apple nor Microsoft wanted to have a key piece of their system software technology controlled by an outside company. So Apple developed their own scaleable font technology, first code-named Royal, and later introduced as TrueType.
Apple traded the technology with Microsoft in exchange for the latter's TrueImage PostScript clone technology (which was buggy at the time, and never got used by Apple, although it has surfaced in various later incarnations). The TrueType specifications would be made public, and TrueType would be built into the next versions of the Mac and Windows operating systems.
Adobe's pre-emptive response started with the release of the long-protected specifications for the PostScript Type 1 font format in March 1990. This was followed by introduction of Adobe Type Manager (ATM) software in mid-1990. ATM scales Type 1 (but not Type 3) PostScript fonts for screen display and imaging on both PostScript and non-PostScript printers.
In early 1991, TrueType for the Mac became available, followed by the Windows 3.1 implementation. Now, with either TrueType or ATM, Mac users (and later Windows and OS/2 users) could actually see on-screen at any size what the font output would look like.
So now there are two widely used outline font specifications, one (TrueType) built into the operating systems used by over 95% of computers world-wide, and the other (PostScript Type 1) both well-established and supported directly by most high-end output devices.
But as time goes on, the practical differences begin to blur. Support for TrueType is built in to many implementations of PostScript Level 2, and is standard in PostScript 3. Similarly, the ATM rasterizing technology is slated to be incorporated into Windows NT 5.0, side-by-side with TrueType. Apple's forthcoming "Rhapsody" operating system uses Display PostScript as the basis of its entire imaging model, which also gives it native support for PostScript fonts. Under the new OpenType format (discussed later), either TrueType or PostScript outlines can be put into a TrueType-style wrapper. Under the new OpenType format (discussed later), either TrueType or PostScript outlines can be put into a TrueType-style wrapper.
The first difference between TrueType and PostScript fonts is their use of different sorts of mathematics to describe their curves. Conversions between the two formats are typically imperfect: although mathematically speaking the quadratic B-splines of TrueType are a subset of the cubic Bézier curves of PostScript, there are usually small rounding errors no matter which direction one converts fonts; however, the errors are greater in going from PostScript to TrueType than vice versa. More importantly, hinting information does not directly translate in either direction between the two formats.
Some articles have said that TrueType fonts require more points than PostScript, or that they take longer to rasterize because the math is more complicated. In fact, the math is simpler (quadratics are simpler than cubics), and a few shapes take fewer points in TrueType than in PostScript (a circle takes twelve points in PostScript vs. eight in TrueType). However, some PostScript rasterizers are unsurprisingly going to be faster at dealing with PostScript, and it's true that most fonts will end up using more points in TrueType, even if the mathematical description of the curves is simpler.
The primary advantage of TrueType over PS1 fonts is the fact that TrueType allows better hinting. PostScript Type 1 fonts can hint vertical and horizontal features, overshoots, stem snaps, equal counters, and shallow curves ("flex"). Several of these can have a threshold pixel size at which they activate.
TrueType hints can do all that PostScript can, and almost anything else, as defined by the very flexible instructions. This includes controlling diagonals, moving speci=DEed points on the glyph outlines at specific arbitrary sizes to improve legibility. This ability to move points at a specific point size allows the font production staff to hand-tune the bitmap pattern produced by the outline at any specified size.
This is really symptomatic of a larger philosophical difference. PostScript uses "dumb" fonts and a "smart" interpreter, while TrueType uses relatively smarter fonts and a dumber interpreter. This means that PostScript hints tell the rasterizer what features ought to be controlled, and the rasterizer interprets these using its own "intelligence" to decide how to do it. Therefore, if Adobe upgrades the PostScript interpreter, the hinting can be improved.
Contrariwise, TrueType puts very specific instructions (some TT aficionados don't like to call them hints) into the font to control how it will appear. Thus the font producer has the potential for very fine control over what happens when the font is rasterized under different conditions. However, it requires serious effort on the part of a font developer to actually take advantage of this greater hinting potential.
Another factor is the fact that TrueType rasterizing is built into several operating systems. Both the Mac OS and all the current incarnations of Windows support TrueType directly. These operating systems will rasterize TrueType fonts for the screen, and handle the sending of them to the printer, whether as bitmaps or as fonts in some format the printer can understand.
On the other hand, PostScript Type 1 font support is built into only one significant operating system: OS/2. This OS will do for PS1 fonts what the others do for TrueType. However, recent agreements between Microsoft and Adobe will include the ATM rasterizer for PostScript Type 1 as a part of Windows NT 5.0 and higher.
Scaling PostScript fonts on current versions of the Mac or Windows essentially requires the Adobe Type Manager (ATM) software, which handles the rasterizing to the screen, and rasterizes or converts the fonts for non-PostScript printers. Technically, ATM is not required to use PostScript fonts on PostScript printers, but ATM is required to display the font accurately on screen at arbitrary sizes.
Although ATM is commercial software, it comes with virtually every Adobe application, and with every commercial Adobe typeface package. At this point, it's still an add-on, rather than an integral part of current Windows and Mac operating systems. Apple long ago agreed to increase its system-level support for PostScript, but has not aggressively pursued doing so.
A smaller, but consistent, advantage has to do with the physical storage of the fonts. TrueType fonts have all the data in a single file (although Windows 3.1 will create a "FOT" file for installed TT fonts, as a pointer to the location of the font data).
However, PostScript fonts require two separate files: one contains the character outlines, and the other contains metrics data (character widths and kern pairs). On the Macintosh, the current system software (System 7.5.5 and earlier) requires PS1 fonts to have not only the outline font, but also a bit-mapped screen font in at least one size, which contains the metrics data. For Windows systems using PostScript, a "PFB" file contains the outlines, while a "PFM" file carries the metrics. OS/2 uses an "OFM" file for the same purpose.
The system-independent "AFM" metrics file can be converted to a Windows PFM file upon installation by ATM, or can be used by a font editing program along with the outline to create a screen font for the Mac that includes any kerning pairs in the original.
On the other hand, PostScript's pair of Files are often smaller than TrueType's single file. The size difference ranges from only a 5% savings for an average font, to as much as a doubling of size for TrueType fonts that actually have extensive "hinting" instructions.
Also, most high-end output devices use PostScript as their internal page description language. PostScript fonts can be sent directly to these devices. It used to be the case that TrueType fonts were either downloaded as bitmaps or required that the TrueType rasterizer be downloaded as a PostScript program, which slowed printing a bit.
More recently, many PostScript Level 2 printers (and all PostScript 3 printers) have the TrueType rasterizer in ROM, built in. However, with some Windows printer drivers the user must change the printer driver settings in software to take advantage of this feature (downloading TrueType as "Type 42," which is basically a PostScript wrapper around the TrueType data).
Further Practical Differences
Many of the theoretical advantages of TrueType are not actually realized in most commercially available TrueType fonts. PostScript backers point to a number of problems that still make PostScript fonts a better solution for many users. Besides the above-mentioned issue of the language of the output device, there are four other practical issues that even the score for PostScript:
First, at present many of the commercially available TrueType fonts one sees at the corner software store are of poor quality, coming in "zillion-fonts-for-a-buck" collections. Many of these fonts were originally shareware or public domain PostScript fonts, and have been converted to TrueType using some basic automatic utility. The outlines and hinting are no better than they were in the PostScript versions, and will suffer slightly in almost any automatic conversion. Usually in the case of extremely cheap collections, they weren't the best quality PostScript fonts even before conversion to TrueType.
Of course, TrueType backers point out that often these fonts were available before; it's simply the availability of a universal font scaling technology that makes discount fonts for the masses practical, and of course they are more likely to be released in the most widely available format.
Second, as of this writing there is no font editing software available at the retail level with native TrueType support, although this will change in late 1997 with the release of FontLab 3.0. All prior retail font editing programs use only PostScript-style bézier curves as their native operating mode. Exporting TrueType fonts from these programs entails conversion, and some minor loss of accuracy. The other tools required to do native editing of TrueType fonts, and to take advantage of the theoretical abilities of TrueType hinting, cost thousands of dollars.
Regardless of the specific tools used, achieving first-class hinting in TrueType currently requires intensive manual coding on a glyph-by-glyph basis. This requires substantial time and expertise on the part of the person doing the hinting.
As a result, high-quality TrueType fonts are currently only available from a handful of very large vendors, and only a minority of even those fonts really exploit the potential of TrueType hinting.
Third, TrueType's hinting advantage only matters when hinting matters: when outputting to low-resolution devices, or for screen display. The increasing, widespread use of 600 dpi and better laser printers makes this less critical for print work. On the other hand, the increasing importance of screen displays for multimedia production and the Internet makes hinting more important.
Fourth, PostScript has some advantages simply from being the longer-established standard, especially for serious graphic arts work. Service bureaus are standardized on, and have large investments in, PostScript fonts. Most of the fonts which have "expert sets" of old style figures, extra ligatures, true small capitals and the like are in PostScript Type 1 format.
Although most major vendors have TrueType fonts, only a few (such as Bitstream) offer their entire libraries in both formats. Most, like Linotype and Monotype, have only a minority of their fonts in TrueType format. Given the current state of the tools, it would take a concerted effort of many years to convert all the major vendors' font libraries to TrueType.
A final issue that is often raised is the story that some PostScript devices, particularly imagesetters, have problems either with TrueType fonts in general, or especially with mixing TrueType and PostScript on the same page or the same line. This is mostly an historical issue. More recent TrueType operating system implementations, and newer PostScript raster image processing software, have resolved what few problems there were early on.
According to Dov Isaacs, then Adobe's Manager of Quality Assurance, Printing & Systems Division, "regardless of whether you are on a Mac or a PC running Windows 3.1 or above, you can mix TrueType and Type 1 with t= he caveat that you should never have both TrueType and Type 1 fonts with the same exact names on the same system." Having two fonts with identical names can confuse the operating system, with unpredictable results.
Also, if using Windows, one may find that PostScript versions of the Windows TrueType system fonts get substituted by the output device: Times New Roman becomes Times-Roman, and Arial becomes Helvetica. Further, although the basic spacing of the substituted fonts is identical, their kerning pairs are not. This can cause text to reflow if one switches between two different-but-almost-the-same fonts on the computer doing the typesetting, if the program supports kerning pairs (graphics and DTP programs, and some better word processors).
Getting the same font on the actual output can be guaranteed by changing printer settings in the printer control panel, to ensure the TrueType system fonts get used. Hackers can also try editing the WIN.INI file on the computer that is doing the printing (whether to device or file). Delete the relevant lines in the font substitution section, so that the TrueType font used on-screen is also sent to the output device, rather than a printer font being substituted. On Windows NT or Win95, Registry settings control the same behavior. Alternatively, get a scalable version of the font used in the printer, and use it instead of the system fonts.
One actual, but rare, source of problems is not inherent in TrueType, but a result of the fact that rasterizing TrueType can require a bit more RAM in the raster image processor (RIP) than rasterizing PostScript--primarily in older PostScript rasterizers when the TrueType rasterizing program must be downloaded. If the RIP has barely enough RAM, it's possible that this could push it over the edge. Service bureaus are notoriously conservative about this sort of thing (understandably, since any delays or problems can cost them money); your best bet is to consult with them, and if they warn of potential problems, test something complex with a mix of fonts for future reference.
The Multiple Master (MM) format is an extension of the Adobe Type 1 PostScript font format. Essentially, it allows two design variations to be encoded as opposing ends of a single design axis. Afterwards, any in-between state may be generated by the user on need. Thus, an MM font could have a "weight" axis which has an ultra-light master and an extra-black master, allowing any conceivable variation in between. And this is only one possibility; almost any two design extremes could theoretically be put on a multiple master, as long as their Bézier control points can be matched up to allow interpolation.
Multiple axes are also possible, but each additional axis doubles the number of master fonts that must be created, because each possible extreme must be designed separately. Imagine a dimensional space, with each corner requiring a master. Thus a three-axis MM (a cube) must have eight master fonts; a four-axis font (the theoretical maximum) would need sixteen master fonts, which is one reason nobody has released one yet.
The primary uses to which MM technology has been put are: weight (light to bold); width (condensed to extended); and optical size (text to display). A few MM fonts experiment with other forms, such as the existence or type of serifs. All of these adjustments can be done by cruder means, by creating separate fonts, or even just ignored; but MMs allow typographically aware users to create the precise, desired typeface in a more refined fashion.
As of this writing, fewer than 36 MM fonts have been released by major font vendors--and more than half by Adobe. Using Multiple Masters also requires that the user have Adobe Type Manager, but this is a near-necessity for PostScript fonts anyway.
There are a few older devices with implementations of PostScript level 1 that can't handle MM fonts, notably Apple's Personal LaserWriter NT, the HP LaserJet IIID, the PostScript cartridge for the HP LaserJet IIP, the TI microLaser PostScript series, and some older PostScript clones.
A more common problem with MM technology is that it can be inconvenient to access additional MM variants. At present, much of the time, the user must use ATM (or a "Font Creator" utility with Mac ATM prior to 4.0) to instantiate each additional font variant in order to make it available to the system. There are a few exceptions: Microsoft Word 6 & 7 support direct creation of MM instances on the fly by typing the exact name of the instance (easy, but hardly obvious). PageMaker 6 also has integrated support for creating and using MM instances, as does QuarkXPress 3.3x, via an included extension. But because this is less convenient, and many users are unfamiliar with MM technology, it often makes more economic and marketing sense to release a font set as multiple Type 1 variants, even if it was designed using multiple master-style interpolation. An example of this trend is Jonathan Hoefler's reworking of Didot.
If there were better system-wide and/or application-level support for MM fonts, they might be more popular. CompuServe DTP Forum Sysop and typography writer Kathleen Tinkel says, "if MM fonts were to become easier to use, I think we'd see another two dozen fonts very quickly."
QuickDraw GX & GX Fonts
Another attempt to enhance these typographic niceties (and then some) is Apple's QuickDraw GX, and GX fonts. GX is not specific to either TrueType or PostScript Type 1; GX fonts are an extension of either font specification, although there are some additional features possible in TrueType GX fonts.
TrueType GX fonts have essentially the same capability as Multiple Masters vis-à-vis design axes. However, they also have greater flexibility in the use of these axes. Although master fonts can be put at each corner of the design space, each axis has a minimum requirement of one new outline at the end of each axis; this means that instead of doubling the number of masters, each axis could simply add one instead. Thus, for example, it would be possible to have an eight-axis GX font that only had nine master designs, instead of the 256 it would take in Multiple Master technology. Of course, designers taking advantage of this feature must be careful, because the corners of the design space must be created by vector addition, which has the potential to create unexpected problems in the corners of the design space.
Of equal or greater interest to the average user is the potential inherent in the GX Line Layout Manager. This bit of system software can interpret and manage additional information encoded in a font to do all sorts of nifty things, such as automatic intelligent ligature substitution, or optically aligning the edges of text based on the actual shapes of the letterforms rather than the outside of the character bounding box.
GX fonts also allow extended character sets beyond the usual 256 allowed by standard TrueType and PostScript type 1 fonts. These could be alternate letterforms, or those characters usually included in "expert sets," or foreign languages, or whatever the designer desires. The difference between this and the currently available "expert sets" and "alternates" is that the user simply chooses between stylistic variations encoded in the single font, which could include specific languages, old style figures, ligatures or swashes. Further, either regular or special characters can also substitute themselves intelligently based on adjacent characters, or their position in the word or the line.
Unfortunately, the GX font specification has not met with wide acceptance as of this writing. One reason is that it is only available for the Macintosh, and most major layout software is actively seeking cross-platform compatibility; therefore the vendors are loathe to adopt a "standard" that doesn't have a counterpart for Windows (and other systems they may support).
Further, GX is a model which wants to take on many functions which have previously been areas where high-end layout applications have put considerable effort into adding features and value for the end user. The makers of such applications would be understandably reluctant to abandon their previous hyphenation and justification capabilities (for example) in favor of GX capabilities which are delivered "free" to the lowliest word processor which chooses to support GX.
While most existing applications will work with GX installed, if they don't access most of its features, why should a user bother risking potential incompatibilities?
The result is that none of the biggest software vendors have released any applications which are GX-savvy. There are about a dozen programs that offer some degree of support for GX, including two page layout programs, Uniqorn and Ready-Set-Go 7 GX, and LightningDraw, a drawing package.
With Apple's recent changes in operating system strategy, the future of GX is unclear. Apple has announced its intention to continue GX typography in the upcoming NeXT-OS-based Mac operating system ("Rhapsody"), but this will presumably be without the GX graphics model, and may be a somewhat different form of GX type. If Apple pulls it off, Rhapsody could have the effect of increasing basic GX support; it certainly worked for Apple when they fully integrated TrueType into version 7.0 of their operating system.
Unicode is an international standard for representing a broader character set using two-byte encoding for each letter. This allows the encoding of 64,000 characters instead of 256, essentially all the characters for every language in the world, each with a unique ID. However, the Unicode specification only covers differences that have a linguistic impact, such as accented characters. It does not deal with typographic niceties such as ligatures, old style numbers, or small caps. To paraphrase Chuck Bigelow, it may seem like a metaphysical distinction, but Unicode is a character encoding, rather than a glyph encoding.
The result is that simply adding Unicode capability is very useful for non-English or multi-lingual typography. However, it does not, in and of itself, aid in dealing with the typographic issues addressed by, say, GX or OpenType.
The Unicode character encoding is directly supported by Windows NT. It is not currently supported at the system level by any other major operating system. However, OpenType (see below) is directly based on Unicode, and thus operating systems that support OpenType will get Unicode support in the process, within OpenType fonts.
National Language Support & WGL4
Windows 95 does not fully support Unicode, but has a less universal approach called National Language Support. This allows use of TrueType fonts with more than the usual 256 glyphs of Windows or Macintosh extended ASCII. For convenience, and to help preserve compatibility with older programs, the user's selected language setting determines which glyphs are accessible from the keyboard (as in, the correct ones for the chosen language, assuming they're in the font).
The Windows "WGL4" character set is a specific NLS set of some 652 characters, which include all the characters for every European language. This means all the usual Latin regular and accented characters, plus Greek, Cyrillic, Turkish, a host of accented characters, and IBM Linedraw thrown in for good measure. The basic Windows system fonts (Arial, Courier, Times New Roman) have all been upgraded to the WGL-4 glyph set. Only a few other TrueType fonts have this character set, such as Microsoft's version of the Franklin Gothic family.
This 1996 Adobe/Microsoft initiative surprised industry analysts. OpenType puts either a PostScript or TrueType outline in a TrueType-style wrapper. Applications and most operating system functions outside of the font subsystem will no longer care which type of font is in this "wrapper." As part of the deal, Microsoft and Adobe licensed the TrueType and PostScript font technologies to each other.
The OpenType format will support all the most advanced features of existing TrueType and PostScript formats (much like GX), such as Multiple Master fonts (with PostScript outlines), multilingual character sets with full Unicode support, and extended character sets to support such typographic niceties as "true" small caps, ligatures, fractions and alternate glyphs, all within the main font. OpenType supports automatic glyph substitution so that one glyph can be substituted for a set (such as the f-f-i ligature, or many Arabic characters), or multiple glyphs can be substituted for a single one. Glyph substitution can be context sensitive, and/or activated by explicit user activity. Uses of substitution would be a swash letter that's only used at the beginning of a word or a line, when the "swash" behavior is turned on, formatting text as true "small caps" or cycling through available alternate letter forms.
Although Seybold analysts reported on this as a victory for Microsoft and TrueType, that's only true if you look at the publishing business in isolation. In the broad view, it is really more of a win/win/win situation. Microsoft may finally get greater TrueType acceptance in the high-end publishing market. Adobe gets PostScript font outline support at the system level in Windows, potentially making the Adobe type library more accessible to a broader range of potential buyers. Best of all, end users win by getting a single cross-platform font format, eliminating one of the largest remaining hassles for document transfer between Macintosh and Windows computers.
Apple has not yet announced support for OpenType in either Mac OS 8.x or the NeXT-based "Rhapsody OS." However, Adobe and Microsoft seem committed to delivering a complete solution. (Ironically, the OpenType approach to putting TrueType and PostScript in a common wrapper is very much like what Apple did with QuickDraw GX and GX-enabled fonts.)
What Does the Future Hold?
It is interesting to compare the future of Open-Type to the past of GX. GX features are not actively supported by any of the leading graphics programs, and GX is actively incompatible with some of them. Will OpenType succeed where GX seems to have failed?
GX enthusiasts may say that all the features offered by OpenType can be had today in GX, and that advanced typographic support is easier if one goes with GX.
But there are several key differences which may swing the future in OpenType's favor. First, OpenType is in no way incompatible with existing applications and fonts--it's not the case that one must embrace it all at once, as GX attempted. Second, OpenType was created by the leading maker of business software (Microsoft) and the leading creator of graphics software (Adobe). If even only these two companies' applications support OpenType to start with, that would be much further than GX got with mainstream applications.
On the other hand, applications that support OpenType may not do it as evenly as GX-savvy apps support that technology. With GX, an application simply lets the GX "Line Layout Manager" do all the work. With OpenType, the needed font information is available through system calls, but it is up to each application to decide what to do with it.
One thing that drives acceptance of some solution, whether GX or OpenType, is the needs of the international markets. In particular, the Asian languages such as Chinese, Japanese and Korean, which can't be represented by a single-byte font, require something that supports larger character sets. This is essential for operating system companies such as Apple and Microsoft, and very important to Adobe, which also derives a large chunk of revenue from the Asian markets.
By mid-1998, initial OpenType font offerings, OS support, and the first actively supporting applications should appear. This is also when the full version of Apple's Rhapsody OS is scheduled to ship. At this time it should be much more apparent how OpenType and GX support are shaping up, and whether the support and benefits of either or both are sufficiently compelling to users. In the meantime, they are both technologies worth keeping an eye on.
OpenType may be a savior in the font wars, but first it will have to be supported at the operating system level, and applications will need to be re-engineered to take advantage of its more whizzy features. Although existing font libraries could easily be converted directly, it is only by the combining of fonts and the laborious addition of new features that the greatest value can be added to them. This will take years. In the meantime, users still have to choose.
There are some real differences between PostScript and TrueType--although the relative advantages of each are often exaggerated by the boosters of one or the other format. Each format-- and the combination of the two in OpenType--has extensions, which offer the promise of new capabilities; but these are not yet widely adopted. In practice, most users can usually use both formats, and mix them, without worrying a great deal about the differences, which are usually transparent to the final viewer.
Nonetheless, there are definitely situations in which one format or the other may be desirable, such as when particular expert sets are needed (more commonly available in PostScript fonts), when TrueType doesn't work on a particular older imagesetter, or when maximum legibility is needed for screen display (the best TrueType fonts).
© Thomas W. Phinney
- 24 minutes to read
OpenType fonts are an extension of the TrueType Font File format.
This chapter introduces the basic concepts needed to create and instruct a TrueType font, or an OpenType font that contains TrueType outline data. It begins with an overview of the steps involved in taking a design from paper to the creation of a bitmap that can be sent to an output device and follows with a closer look at each of the steps in the process.
From design to font file
A TrueType font can originate as a new design drawn on paper or created on a computer screen. TrueType fonts can also be obtained by converting fonts from other formats. Whatever the case, it is necessary to create a TrueType font file that, among other things, describes each glyph in the font as an outline in the TrueType format.
From Font File to Paper
This section describes the process that allows glyphs from a TrueType font file to be displayed on raster devices.
First, the outline stored in the font file isscaled to the requested size. Once scaled, the points that make up the outline are no longer recorded in the FUnits used to describe the original outline, but have become device-specific pixel coordinates.
Next, the instructions associated with this glyph are carried out by the interpreter. The result of carrying out the instructions is a grid-fitted outline for the requested glyph. This outline is then scan converted to produce a bitmap that can be rendered on the target device.
- Digitize outline with FUnit coordinates in TrueType font file
- Scaler converts FUnits to pixel coordinates and scales outline to size requested by application
- Outline “sized” to new grid
- Scaled outline with pixel coordinates
- Interpreter executes instructions associated with glyph “B” and gridfits
- Grid-fitted outline
- Grid fitted outline
- Scan converter decides which pixels to turn on
- Bitmap is rendered on raster device
Digitizing a Design
This section describes the coordinate system used to establish the locations of the points that define a glyph outline. It also documents the placement of glyphs with respect to the coordinate axes.
In a TrueType font, glyph shapes are described by their outlines. A glyph outline consists of a series of contours. A simple glyph may have only one contour. More complex glyphs can have two or more contours. Composite glyphs can be constructed by combining two or more simpler glyphs. Certain control characters that have no visible manifestation will map to the glyph with no contours.
Contours are composed of straight lines and curves. Curves are defined by a series of points that describe second order Bezier-splines. The TrueType Bezierspline format uses two types of points to define curves, those that are on the curve and those that are off the curve. Any combination of off and on curve points is acceptable when defining a curve. Straight lines are defined by two consecutive on curve points.
The points that make up a curve must be numbered in consecutive order. It makes a difference whether the order is increasing or decreasing in determining the fill pattern of the shapes that make up the glyph. The direction of the curves has to be such that, if the curve is followed in the direction of increasing point numbers, the black space (the filled area) will always be to the right.
FUnits and the em square
In a TrueType font file point locations are described in font units, or FUnits. An FUnit is the smallest measurable unit in the em square, an imaginary square that is used to size and align glyphs. The dimensions of the em square typically are those of the full body height of a font plus some extra spacing to prevent lines of text from colliding when typeset without extra leading.
While in the days of metal type, glyphs could not extend beyond the em square, digital typefaces are not so constrained. The em square may be made large enough to completely contain all glyphs, including accented glyphs. Or, if it proves convenient, portions of glyphs may extend outside the em square. TrueType fonts can handle either approach so the choice is that of the font manufacturer. Figure 1-3 A character that extends outside of the em square
The em square defines a two-dimensional coordinate grid whose x-axis describes movement in a horizontal direction and whose y-axis describes movement in a vertical direction. This is discussed in more detail in the following section.
FUnits and the grid
A key decision in digitizing a font is determining the resolution at which the points that make up glyph outlines will be described. The points represent locations in a grid whose smallest addressable unit is known as an FUnit or font Unit. The grid is a two-dimensional coordinate system whose x-axis describes movement in a horizontal direction and whose y-axis describes movement in a vertical direction. The grid origin has the coordinates (0,0). The grid is not an infinite plane. Each point must be within the range -16384 and +16383 FUnits. Depending upon the resolution chosen, the range of addressable grid locations will be smaller.
The choice of the granularity of the coordinate grid-that is, number of units per em (upem)-is made by the font manufacturer. Outline scaling will be fastest if units per em is chosen to be a power of 2, such as 2048.
The origin of the em square need not have any consistent relationship to the glyph outlines. In practice, however, applications depend upon the existence of some convention for the placement of glyphs for a given font. For Roman fonts, which are intended to be laid out horizontally, a y-coordinate value of 0 typically is assumed to correspond to the baseline of the font. No particular meaning is assigned to an xcoordinate of 0 but manufacturers may improve the performance of applications by choosing a standard meaning for the xorigin.
For example, you might place a glyph so that its aesthetic center is at the xcoordinate value of 0. That is, a set of glyphs so designed when placed in a column such that their xcoordinate values of 0 are coincident will appear to be nicely centered. This option would be used for Kanji or any fonts that are typeset vertically. Another alternative is to place each glyph so that its leftmost extreme outline point has an x-value equal to the left-side-bearing of the glyph. Fonts created in this way may allow some applications to print more quickly to PostScript printers.
Non-Roman fonts may wish to use other conventions for the meaning of the xorigin and yorigin. For best results with high-lighting and carets, the body of the character should be roughly centered within the advance width. For example, a symmetrical character would have equal left and right side bearings.
The granularity of the em square is determined by the number of FUnits per em, or more simply units per em . The em square as divided into FUnits defines a coordinate system with one unit equaling an FUnit. All points defined in this coordinate system must have integral locations. The greater the number of units per em, the greater the precision available in addressing locations within the em square.
FUnits are relative units because they vary in size as the size of the em square changes. The number of units per em remains constant for a given font regardless of the point size. The number of points per em, however, will vary with the point size of a glyph. An em square is exactly 9 points high when a glyph is displayed at 9 points, exactly 10 points high when the font is displayed at 10 point, and so on. Since the number of units per em does not vary with the point size at which the font is displayed, the absolute size of an FUnit varies as the point size varies.
Because FUnits are relative to the em square, a given location on a glyph will have the same coordinate location in FUnits regardless of the point size at which the font is rendered. This is convenient because it makes it possible to instruct outline points once considering only the original outline and have the changes apply to the glyph at whatever size and resolution it is ultimately rendered.
Scaling a glyph
This section describes how glyph outlines are scaled from the master size stored in the font file to the size requested by an application.
Whatever the resolution of the em square used to define a glyph outline, before that glyph can be displayed it must be scaled to reflect the size, transformation and the characteristics of the output device on which it is to be displayed. The scaled outline must describe the character outline in units that reflect an absolute rather than relative system of measurement. In this case the points that make up a glyph outline are described in terms of pixels.
Intuitively, pixels are the actual output bits that will appear on screen or printer. To allow for greater precision in managing outlines, TrueType describes pixel coordinates to the nearest sixty-fourth of a pixel.
Converting FUnits to pixels
Values in the em square are converted to values in the pixel coordinate system by multiplying them by a scale. This scale is:
pointSize * resolution / ( 72 points per inch * units_per_em )
where pointSize is the size at which the glyph is to be displayed, and resolution is the resolution of the output device. The 72 in the denominator reflects the number of points per inch.
For example, assume that a glyph feature is 550 FUnits in length on a 72 dpi screen at 18 point. There are 2048 units per em. The following calculation reveals that the feature is 4.83 pixels long.
550 * 18 * 72 / ( 72 * 2048 ) = 4.83
Display device characteristics
The resolution of any particular display device is specified by the number of dots or pixels per inch (dpi) that are displayed. For example, a VGA under Windows is treated as a 96 dpi device, and most laser printers have a resolution of 300 dpi. Some devices, such as an EGA, have different resolution in the horizontal and vertical directions (i.e. non-square pixels); in the case of the EGA this resolution is 96 x 72. In such cases, horizontal dots per inch must be distinguished from vertical dots per inch.
The number of pixels per em is dependent on the resolution of the output device. An 18 point character will have 18 pixels per em on a 72 dpi device. Change the resolution to 300 dpi and it has 75 pixels per em, or change to 1200 dpi and it has 300 pixels per em.
Displaying type on a particular device at a specific point size yields an effective resolution measured in pixels per em (ppem). The formula for calculating pixels per em is:
ppem = pointSize * dpi / 72
= (pixels per inch) * (inches per pica point) * (pica points per em)
= dpi * 1 / 72 * pointSize
On a 300 dpi laser printer, a 12 point glyph would have 12300/72 or 50 ppem. On a typesetter with 2400 dpi, it would have 122400/72 or 400 ppem. On a VGA, a 12 point glyph would have 1296/72 or 16 ppem. Similarly, the ppem for a 12 point character on a 72 dpi device would be 1272/72, or 12. This last calculation points to a useful rule of thumb: on any 72 dpi device, points and pixels per em are equal. Note, however, that in traditional typography an inch contains 72.2752 points (rather than 72); that is, one point equals .013836 inches.
If you know the ppem, the formula to convert between FUnits and pixel space coordinates is:
pixel_coordinate = em_coordinate * ppem /upem
An em_coordinate position of (1024, 0) would yield a device_pixels coordinate of (6, 0), given 2048 units per em and 12 pixels per em.
Grid-fitting a glyph outline
The fundamental task of instructing a glyph is one of identifying the critical characteristics of the original design and using instructions to ensure that those characteristics will be preserved when the glyph is rendered at different sizes on different devices. Consistent stem weights, consistent color, even spacing, and the elimination of pixel dropouts are common goals.
To accomplish these goals, it is necessary to ensure that the correct pixels are turned on when a glyph is rasterized. It is the pixels that are turned on that create the bitmap image of the glyph. Since it is the shape of the glyph outline that determines which pixels will make up the bitmap image of that character at a given size, it is sometimes necessary to change or distort the original outline description to produce a high quality image. This distortion of the outline is known as grid-fitting.
The figure below illustrates how grid-fitting a character distorts the outline found in the original design.
As the illustration above suggests, the grid-fitting employed in TrueType goes well beyond aligning a glyph's left side bearing to the pixel grid. This sophisticated grid-fitting is guided by instructions. The beneficial effects of grid-fitting are illustrated in the next figure.
Figure 1-10 12 point outlines and bitmap ungrid-fitted (left) and
Grid-fitting is the process of stretching the outline of a glyph according to the instructions associated with it. Once a glyph is grid-fitted, the point numbers will be unchanged but the actual location of that point in the coordinate grid may have shifted. That is, the coordinates for a given point number will, very likely, have changed after a glyph is grid-fitted.
What are instructions?
The TrueType instruction set provides a large number of commands designed to allow designers to specify how character features should be rendered. Instructions are the mechanism by which the design of a character is preserved when it is scaled. In other words, instructions control the way in which a glyph outline will be grid-fitted for a particular size or device.
Instructing a font will reshape the outline for a given glyph at a specific size on a given target device in such a way that the correct pixels are included within its outline. Reshaping the outline means moving outline points. Points that have been acted upon by an instruction are said to have been touched. Note that a point need not actually be moved to be touched. It must simply be acted upon by an instruction. (See MDAP, chapter 3.)
TrueType fonts can be used with or without instructions. Uninstructed fonts will generally produce good quality results at sufficiently high resolutions and point sizes. The range of sizes over which an uninstructed font will produce good quality results depends not only on the output device resolution and point size of the character but also on the particular font design. The intended use of the font can also be a factor in determining whether or not a particular font should be instructed. For most fonts, if legibility of small point sizes on low resolution devices is important, adding instructions will be critical.
Instructing a font is a process that involves analyzing the key elements of a glyph's design and using the TrueType instruction set to ensure that they are preserved. The instructions are flexible enough to allow characteristics that are roughly the same to be “homogenized” at small sizes while allowing the full flavor of the original design to emerge at sizes where there are sufficiently many pixels.
How does the TrueType interpreter know the manner in which an outline should be distorted to produce a desirable result? This information is contained in instructions attached to each character in the font. Instructions specify aspects of a character's design that are to be preserved as it is scaled. For example, using instructions it is possible to control the height of an individual character or of all the characters in a font. You can also preserve the relationship between design elements within a character thereby ensuring, for example, that the widths of the three vertical stems in the lower case m will not differ dramatically at small sizes.
The following figure illustrates how changing a glyph's outline at a specific size will yield a superior result. They show that an uninstructed 9 point Arial lowercase m suffers the loss of a stem due to chance effects in the relationship of stems to pixel centers. In the second glyph, instructions have aligned the stems to the grid so that the glyph suffers no similar loss.
The TrueType interpreter
This section describes the actions of the TrueType interpreter. It is the interpreter, as the name suggests, that “interprets” or carries out the instructions.
More concretely, the interpreter processes a stream or sequence of instructions. Typically these instructions take their arguments from the interpreter stack and place their results on that stack. The only exceptions are a small number of instructions that are used to push data onto the interpreter stack. These instructions take their arguments from the instruction stream.
All of the interpreter's actions are carried on in the context of the Graphics State, a set of variables whose values guide the actions of the interpreter and determine the exact effect of a particular instruction.
The interpreter's actions can be summarized as follows:
The interpreter fetches an instruction from the instruction stream, an ordered sequence of instruction opcodes and data. Opcodes are 1-byte in size. Data can consist of a single byte or two bytes (a word). If an instruction takes words from the instruction stream it will create those words by putting together two bytes. The high byte appears first in the instruction stream and the low byte appears second.
The following instruction stream is depicted as it will be shown in the examples that follow. Note that the pointer indicates the next instruction to be executed.
The instruction is executed
- If it is a push instruction it will take its arguments from the instruction stream.
Any other instruction will pop any data it needs from the stack. A pop is illustrated below.
Any data the instruction produces is pushed onto the interpreter stack. A push is illustrated below.
As the previous discussion indicates, the interpreter stack is a LIFO or last in first out data structure. An instruction takes any data it needs from the last item placed on the stack. The action of removing the top item from the stack is commonly termed a pop. When an instruction produces some result it pushes that result to the top of the stack where it is potential input to the next instruction.
The instruction set includes a full range of operators for manipulating the stack including operators for pushing items onto the stack, popping items from the stack, clearing the stack, duplicating stack elements and so forth.
The effect of execution depends on the values of the variables that make up the Graphics State.
- The instruction may modify one or more Graphics State variables. In the illustration shown, the Graphics State variable rp0 is updated using a value taken from the interpreter stack.
The process is repeated until there are no further instructions to be executed.
Instructions can appear in a number of places in the font file tables that make up a TrueType font. They can appear as part of the Font Program, the CVT Program, or as glyph data. Instructions appearing in the first two apply to the font as a whole. Those found in glyph data ('glyf') apply to individual glyphs within a font.
The Font Program
The Font Program consists of a set of instructions that is executed once, the first time a font is accessed by an application. It is used to create function definitions (FDEFs) and instruction definitions (IDEFs). Functions and instructions defined in the Font Program can be used elsewhere in the font file.
The CVT Program
The CVT Program is a sequence of TrueType instructions executed every time the point size or transformation change. It is used to make font wide changes rather than to manage individual glyphs. The CVT Program is used to establish the values in the Control Value Table.
The purpose of the Control Value Table or CVT is to simplify the task of maintaining consistency when instructing a font. It is a numbered list of values that can be referenced by either of two indirect instructions (MIRP and MIAP). CVT entries can be used to store values that need to be the same across a number of glyphs in a font. For example an instruction might refer to a CVT entry whose purpose is to regularize stem weights across a font.
|0||0||upper and lower case flat base(base line)|
|1||-39||upper case round base|
|2||-35||lower case round base|
|3||-33||figure round base|
|5||1114||x-height round overlap|
|9||1491||numbers round top|
|12||157||x stem weight|
|13||127||y stem weight|
|15||83||space between the dot and the I|
Instructions that refer to values in the CVT are called indirect instructions as opposed to the direct instructions which take their values from the glyph outline.
As part of the TrueType font file, the values in the CVT are expressed in FUnits. When the outlines are converted from FUnits to pixel units, values in the CVT are also converted.
When writing to the CVT you may use a value that is in the glyph coordinate system (using WCVTP) or you can use a value that is in the original FUnits (using WCVTF). The interpreter will scale all values appropriately. Values read from the CVT are always in pixels (F26Dot6).
The Storage Area
The interpreter also maintains a Storage Area consisting of a portion of memory that can be used for temporary storage of data from the interpreter stack. Instructions exist that make it possible to read the values of stored data and to write new values to storage. Storage locations range from 0 to n-1 where n is the value established in the maxStorage entry in the maxProfile table of the font file. Values are 32 bit numbers
The Graphics State
The Graphics State consists of a table of variables and their values. All instructions act within the context of the Graphics State. Graphics State variables have default values as specified in Appendix B, “Graphics State Summary”. Their values can be determined or changed using instructions.
The Graphics State establishes the context within which all glyphs are interpreted. All Graphics State variables have a default value. Some of these values can be changed in the CVT Program if desired. Whatever the default value, it will be reestablished at the start of interpretation of any glyph. In other words, the Graphics State has no inter-glyph memory. Changing the value of a Graphics State variable while processing an individual glyph will result in a change that remains in effect only for that glyph.
The scan converter
The TrueType scan converter takes an outline description of a glyph and produces a bitmap image for that glyph.
The TrueType scan converter offers two modes. In the first mode, the scan converter uses a simple algorithm for determining which pixels are part of that glyph. The rules can be stated as follows:
- Rule 1
- _If a pixel's center falls within the glyph outline, that pixel is turned on and becomes part of that glyph._
- Rule 2
- _If a contour falls exactly on a pixel's center, that pixel is turned on._
A point is considered to be an interior point of a glyph if it has a non-zero winding number. The winding number is itself determined by drawing a ray from the point in question toward infinity. (The direction in which the ray points in unimportant.) Starting with a count of zero, we subtract one each time a glyph contour crosses the ray from right to left or bottom to top. Such a crossing is termed an on transition. We add one each time a contour of the glyph crossed the ray from left to right or top to bottom. Such a crossing is termed an off transition. If the final count is non-zero, the point is an interior point.
The direction of a contour can be determined by looking at the point numbers. The direction is always from lower point number toward higher point number.
The illustration that follows demonstrates the use of winding numbers in determining whether a point is inside a glyph. The point p1 undergoes a sequence of four transitions (on transition, off transition, on transition, off transition). Since the sequence is even, the winding number is zero and the point is not inside the glyph. The second point, p2, undergoes an off transition followed by an on transition followed by an off transition yielding a winding number of +1. The point is in the interior of the glyph.
What is a dropout?
A dropout occurs whenever there is a connected region of a glyph interior that contains two black pixels that cannot be connected by a straight line that only passes through black pixels.
The TrueType instructions are designed to allow you to gridfit a glyph so that the desired pixels will be turned on by the simple scan converter regardless of the point size or the transformation used. It may prove difficult to foresee all possible transformations that a glyph might undergo. It is therefore difficult to instruct a glyph to ensure that the proper grid-fitting distortion of the outline will take place for every desired transformation. This problem is especially difficult for very small numbers of pixels per em and for complex typefaces. In these situations, some renditions of a glyph may contain dropouts.
It is possible to test for potential dropouts by looking at an imaginary line segment connecting two adjacent pixel centers. If this line segment is intersected by both an on-Transition contour and an off-Transition contour, a potential dropout condition exists. The potential dropout only becomes an actual dropout if the two contour lines continue on in both directions to cut other line segments between adjacent pixel centers. If the two contours join together immediately after crossing a scan line (forming a stub), a dropout does not occur, although a stem of the glyph may become shorter than desired.
To prevent dropouts, type manufacturers can choose to have the scan converter use two additional rules:
- Rule 3
- _If a scan line between two adjacent pixel centers (either vertical or horizontal) is intersected by both an on-Transition contour and an off-Transition contour and neither of the pixels was already turned on by rules 1 and 2, turn on the left-most pixel (horizontal scan line) or the bottom-most pixel (vertical scan line)_
- Rule 4
- _Apply Rule 3 only if the two contours continue to intersect other scan lines in both directions. That is do not turn on pixels for 'stubs'. The scanline segments that form a square with the intersected scan line segment are examined to verify that they are intersected by two contours. It is possible that these could be different contours than the ones intersecting the dropout scan line segment. This is very unlikely but may have to be controlled with grid-fitting in some exotic glyphs._
The type manufacturer can choose to use the simple scan converter employing rules 1 and 2 only or may optionally invoke either rule 3 or rule 4. The decision about which scan converter to use can be made on a font wide basis or a different choice can be specified for each glyph. The selection made in the preProgram will be the default for the entire font. A change made to the default in the instructions for an individual glyph will apply only to that glyph.