TrueType & PostScript Type 1: What's the Difference?

By Thomas W. Phinney

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.

Brief History

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.

Technical Differences

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.

Multiple Masters

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

TYPE*chimérique | TrueType Typography | TYPE*links