PostScript fonts
PostScript fonts are a class of digital outline fonts developed by Adobe Systems, primarily in the Type 1 format, for integration with the PostScript page description language to deliver scalable, high-resolution typography in printing and digital applications.[1] Introduced in 1984, these vector-based fonts use mathematical outlines—often defined by Bézier curves—to represent glyphs, allowing them to scale without loss of quality across different devices and resolutions.[2] A key innovation was the inclusion of font hinting, which adjusts outlines at low resolutions to ensure crisp rendering on raster output devices like laser printers.[3] The development of PostScript fonts stemmed from Adobe's creation of the PostScript language itself, founded by John Warnock and Charles Geschke in 1982 as a device-independent programming language for describing page elements, including text, graphics, and images.[3] Evolving from earlier systems like Xerox's JaM and Interpress, PostScript treated fonts geometrically, enabling precise control over type rendering and paving the way for desktop publishing in the 1980s.[3] By licensing popular typefaces and embedding font technology in printers, Adobe established PostScript as an industry standard, powering millions of devices and transforming professional typesetting from manual to digital workflows.[4] While PostScript fonts revolutionized printing with their precision and portability, they have largely been superseded by more versatile formats like OpenType, which Adobe began promoting in 1996 to address limitations such as smaller glyph support and compatibility issues with modern software.[1] Adobe announced the end of support for creating and editing Type 1 fonts in its applications by 2023, citing incompatibilities with contemporary browsers, operating systems, and the need for broader Unicode coverage.[2] Despite this phase-out, the legacy of PostScript fonts endures in the evolution of technologies like PDF, which derives from PostScript principles and remains ubiquitous for document interchange.[3]History
Origins and Development
PostScript fonts originated from the pioneering work of John Warnock and Charles Geschke, who co-founded Adobe Systems in December 1982 after leaving Xerox's Palo Alto Research Center (PARC), where they had developed precursor technologies like the JaM page description language and early outline font systems.[5][3] These efforts culminated in the creation of PostScript as a comprehensive page description language, with its font architecture designed to support scalable, vector-based typography integrated directly into the language for high-quality printing.[6] The fonts were invented specifically to enable device-independent rendering, allowing consistent typographic output across varying resolutions without reliance on fixed bitmap representations.[7] The development drew significant influence from PARC's innovative graphical systems, including the Xerox Alto workstation's early experiments with outline fonts and the broader push for device-independent typography to overcome the limitations of bitmap-based displays and printers prevalent in the late 1970s.[6] Warnock and Geschke's prior projects at PARC, such as JaM, emphasized mathematical descriptions of character shapes using curves, which directly informed PostScript's approach to scalable fonts that could adapt to different output devices like laser printers.[5] This foundation addressed the era's need for professional-grade typesetting in computing, moving beyond pixelated bitmaps to enable smooth, resolution-independent text.[3] PostScript 1.0, incorporating these font innovations, was released in 1984, marking Adobe's strategic decision to keep the underlying font format proprietary as a trade secret while making it licensable to hardware manufacturers for broad adoption.[7][8] The first major commercial deployment occurred in 1985 with Apple's Macintosh computer and the LaserWriter printer, which bundled PostScript and its scalable fonts, revolutionizing desktop publishing by supplanting bitmap alternatives with high-fidelity, adjustable type that supported professional layouts at 300 dpi.[5][7] This partnership, initiated through Steve Jobs' investment in Adobe, propelled PostScript fonts into widespread use, establishing them as a cornerstone of digital typography.[3]Evolution Across PostScript Versions
PostScript Level 1, released in 1985, introduced Type 1 fonts as a scalable outline format designed for high-quality digital typesetting, featuring compact charstring encoding to minimize file size and declarative hinting mechanisms to ensure precise rendering on low-resolution devices by aligning stems and preserving character proportions.[8] These fonts represented a significant advancement over earlier bitmap-based approaches, enabling device-independent scaling and supporting the Adobe Type Library's initial distribution for desktop publishing workflows.[1] With the advent of PostScript Level 2 in 1990, font capabilities expanded to include support for color imaging, allowing fonts to integrate with composite color models like CMYK, and the introduction of Type 0 composite fonts, which enabled the creation of virtual fonts by combining multiple component fonts for efficient handling of complex scripts and ligatures.[9] Improved data compression techniques, such as LZW for font resources, further reduced storage requirements while maintaining compatibility with Level 1 interpreters.[10] These enhancements facilitated broader adoption in color printing environments and laid groundwork for multilingual font support through CID-keyed structures.[11] PostScript Level 3, introduced in 1997, built on prior versions by enhancing integration with the Portable Document Format (PDF), enabling seamless distillation of PostScript files into PDFs with embedded fonts and device-independent color spaces like DeviceN for specialized printing.[12] It expanded the core font set to 136 fonts, incorporating extensions for the Adobe Central European and Cyrillic character sets, and introduced features precursor to OpenType, such as advanced glyph substitution tables in CIDFonts for better handling of diacritics and variant forms.[12] These updates improved rasterization efficiency and color accuracy, particularly for high-end RIPs in professional printing.[10] In the post-2000 era, Adobe shifted emphasis toward OpenType fonts starting in 1996, converting many legacy Type 1 outlines to the OpenType CFF format for enhanced cross-platform compatibility and larger glyph capacities, while preserving backward compatibility with PostScript interpreters through dual-format support.[1] This transition was influenced by the late-1980s "font wars," where Apple's development of TrueType as a royalty-free alternative to Adobe's licensed Type 1 fonts sparked competition, ultimately leading to collaborative standards like OpenType to unify formats.[13] Although PostScript fonts faced deprecation in favor of PDF workflows for document portability, they remained integral to high-end printing systems; in the 2010s, updates via CIDFont extensions provided limited Unicode support for legacy environments, accommodating broader character repertoires without full native integration.[1] The core font sets evolved across levels, with Level 1 offering 35 base fonts, expanding significantly in subsequent versions to support diverse linguistic needs.[12]Technical Foundations
Font Architecture
PostScript fonts are structured as dictionaries within the PostScript language, enabling device-independent representation of scalable typography. The core of this architecture is the Font Dictionary, which encapsulates all essential font data, including the FontName for identification, FontType to specify the format (such as 1 for Type 1 fonts), FontMatrix for scaling transformations, Encoding array for character-to-glyph mapping, CharStrings dictionary for glyph outlines, and Private dictionary for internal data.[10] This dictionary-based organization allows fonts to be loaded and manipulated via operators like findfont and makefont, ensuring portability across PostScript interpreters.[10] Glyph outlines in PostScript fonts are defined in the CharStrings dictionary, where each entry maps a glyph name to a procedure composed of cubic Bézier curves. These curves are constructed using operators such as rcurveto (relative curve to) or curveto (absolute curve to), which specify control points in a unitless character space, typically scaled by a factor of 1000 for precision.[8][10] The Encoding vector, an array of up to 256 elements, maps character codes (0–255) to these glyph names, facilitating standard or custom character sets like StandardEncoding.[8][10] Font metrics, including ascent (maximum height above baseline) and descent (maximum depth below baseline), are stored in entries like FontBBox (defining the overall bounding box as [llx lly urx ury]) or FontInfo dictionary, alongside sidebearing widths via commands like hsbw (horizontal sidebearing width).[8][10] Scalability is inherent to this vector-based design, where glyph outlines are mathematical paths that can be transformed without quality loss. Points on a curve are scaled via the FontMatrix, commonly [0.001 0 0 0.001 0 0] for a 1000-unit em square, applied through operators like scalefont; for a uniform scale factor s, a transformed point is computed as (x', y') = (x × s, y × s), maintaining resolution independence across devices.[8][10] To optimize storage in complex fonts, subroutine sharing employs the Subrs array in the Private dictionary, allowing CharStrings to call reusable curve segments via callsubr, reducing redundancy by up to nested depths of 10.[8] The Private dictionary further supports vendor-specific data, such as encryption keys for CharStrings or alignment zones, isolated from the public Font Dictionary to preserve compatibility.[8][10] Unlike bitmap fonts, which rely on fixed-resolution pixel grids prone to aliasing at varying sizes, PostScript fonts use these parametric outlines for infinite scalability, generating crisp output at any resolution through path filling and stroking.[8][10] This architecture, exemplified in Type 1 fonts, underpins the device's output independence central to PostScript.[8]Rendering and Hinting Mechanisms
The rendering of PostScript fonts involves a pipeline that begins with the interpretation of PostScript code to define glyph paths, followed by rasterization through scan conversion to produce pixel-based output on raster devices. During interpretation, character codes are mapped to glyph descriptions via font dictionaries, employing operators such asmoveto, lineto, and curveto to construct paths, which are then transformed by the current transformation matrix or font matrix.[10] Rasterization converts these paths into device-space pixels using painting operators like fill and stroke, with scan conversion ensuring consistent thickness and preventing glyph distortion due to pixel grid alignment.[10]
In Type 1 fonts, a dedicated hinting system optimizes this process at low resolutions by embedding instructions within charstrings to adjust glyph outlines for pixel grid fitting. These hints align stems—vertical or horizontal stroke elements—to the pixel grid; for instance, the stem3 instruction, implemented as { hstem3 } for horizontal stems or { vstem3 } for vertical ones, positions three equally spaced zones, such as in symbols like the equivalence sign or lowercase "m", without overlapping prior hstem or vstem hints.[8] Blue zones, defined in the font's BlueValues array (up to seven pairs of y-coordinates, starting with the baseline and ensuring at least three units separation), enforce consistent alignment for features like cap height and x-height across glyphs, while optional OtherBlues handle additional zones such as descenders.[8] For curves, flex hints enable smooth rendering of shallow segments, such as serifs, by treating two connected Bézier curves as a flexible unit that may simplify to a straight line at small sizes, constrained by parameters like BlueShift (typically the maximum flex height plus one); counter hints, often via hstem3 or vstem3, maintain uniform spacing in enclosed areas.[8]
Type 3 fonts differ markedly in rendering, as they permit arbitrary PostScript operators within the BuildGlyph or BuildChar procedures, allowing custom path construction and effects but introducing greater complexity and lacking the structured hinting of Type 1 fonts, which results in less optimized low-resolution output.[10][8] In PostScript Level 2 and higher implementations, performance for large fonts is enhanced through optimizations like banding, which processes output in horizontal strips to manage memory efficiently and reduce virtual memory errors, alongside supercell techniques that support up to 1016 gray levels for smoother rasterization.[10] Caching of rendered glyphs further mitigates repeated computation demands in these environments.[10]
Font Types
Simple Fonts (Type 1 and Type 3)
Simple fonts in PostScript represent the foundational single-glyph font types, limited to 8-bit encodings that support up to 256 characters per font. These include Type 1 and Type 3 formats, which enable scalable outline definitions but differ in their implementation and flexibility. Type 1 fonts provide a standardized, compact structure optimized for professional typography, while Type 3 fonts offer programmable freedom for custom designs at the expense of built-in optimizations.[8][10] Type 1 fonts, developed by Adobe as the standard outline font format, consist of a clear-text ASCII portion containing the font dictionary (including entries like FontName, FontBBox, and Encoding) and an encrypted binary portion that includes the Private dictionary and CharStrings. The CharStrings define glyph outlines using a compact, encoded syntax resembling PostScript path operators, such as moveto, lineto, and curveto, with all CharStrings encrypted using a specific algorithm (starting key 4330) to protect proprietary designs. For example, a simplified unencrypted CharString for the glyph 'A' might sequence as: hsbw 0 0 500 0 rmoveto 100 0 lineto 150 700 lineto 200 0 lineto closepath endchar, where hsbw sets horizontal metrics, rmoveto positions the start, and the path operators draw the outline before endchar terminates the definition. Hinting in Type 1 fonts employs standard hints like hstem and vstem to align stems to pixel grids, and flex hints via subroutines (OtherSubrs 0-3) for smooth curve rendering at low resolutions.[8][8][8] Type 3 fonts, in contrast, are user-defined and allow arbitrary PostScript procedures to construct glyphs, typically via the BuildChar procedure in LanguageLevel 1 or BuildGlyph in LanguageLevel 2, integrated into the font dictionary. These procedures can invoke any PostScript operators, including path drawing, clipping, or even imagemask for bitmap-like effects, while remaining scalable through the FontMatrix and current transformation matrix (CTM). Unlike Type 1, Type 3 fonts lack built-in hinting mechanisms, requiring designers to implement manual alignments within the procedures for consistent rendering across sizes. This format supports creative applications, such as textured or procedural glyphs, but demands careful management of the graphics state to avoid issues with save/restore operations.[10][10][10] Encoding in simple fonts uses an 8-bit array mapping code points (0-255) to glyph names or indices, with common vectors like StandardEncoding (an Adobe extension of ASCII covering Western European characters) or ISOLatin1Encoding (aligned with ISO 8859-1 for Latin-1 supplement). Type 1 fonts often default to StandardEncoding, while both types permit re-encoding for custom needs, though limited to 256 glyphs total—leaving one slot (.notdef) for undefined characters. The seac operator, specific to Type 1, facilitates accented characters by combining a base glyph (e.g., 'e') with an accent component (e.g., acute), adjusting positions via width adjustments and the accent's left-side bearing, as defined in the CharStrings.[10][10][8] A key limitation of Type 1 fonts is the strict 255 usable glyphs (excluding .notdef), necessitating multiple fonts or re-encoding for larger sets, alongside a cap of 1500 path elements per CharString to prevent excessive complexity. Type 3 fonts, while more flexible, inherit the 256-glyph encoding constraint and face challenges like no color support in cached glyphs, potential memory overhead from procedural execution, and incompatibility with global VM contexts. Historically, Type 1 fonts dominated early desktop publishing (DTP) from the mid-1980s, powering scalable typography in tools like Adobe Illustrator and enabling high-quality output on PostScript printers. Type 3 fonts found niche use in custom effects, such as decorative textures or mathematical symbols, leveraging PostScript's full expressiveness before more structured formats prevailed.[8][10][1]Composite Fonts (Type 0 and Type 42)
Composite fonts in PostScript enable the aggregation of multiple subfonts to manage complex character sets efficiently, particularly for scripts requiring thousands of glyphs, such as those in East Asian languages. Unlike simple fonts, which handle individual glyph definitions, composite fonts use a hierarchical structure where a parent font dictionary references descendant fonts, allowing for modular organization and shared resources like metrics and hinting data. This design supports multi-byte encodings and character mapping via CMaps, facilitating international text rendering without embedding all glyphs in a single font dictionary.[10] Type 0 fonts represent the primary composite format in PostScript, defined with aFontType entry of 0 in the font dictionary. They consist of a high-level parent dictionary that includes a DescendantFonts array (also known as FDepVector), which lists subordinate font dictionaries such as CIDFonts or other Type 0 fonts, enabling up to five levels of nesting for scalability. The parent font also specifies an Encoding entry, typically a CMap stream that maps input character codes to Character Identifiers (CIDs), which are then resolved to glyph indices in the descendant fonts. An optional CIDToGIDMap entry or stream provides a direct mapping from CIDs to glyph indices (GIDs) in TrueType-based CIDFonts, defaulting to an identity mapping if omitted to optimize glyph selection. Introduced in PostScript Language Level 2, Type 0 fonts were specifically developed to handle large character collections in CJK (Chinese, Japanese, Korean) writing systems, where traditional simple fonts would be inefficient due to the sheer volume of glyphs—often exceeding 10,000 per font family.[10][10][10]
Within Type 0 fonts, composition rules leverage shared resources across descendants to maintain consistency. The FDArray (Font Descriptor Array) in associated CIDFonts is an array of dictionaries that define common attributes like FontMatrix for scaling, FontName, and Private data for glyph subsets, metrics, and hinting instructions, ensuring uniform rendering behavior despite the modular structure. For instance, a Type 0 font might combine a Roman subfont (e.g., for Latin characters) with a Greek subfont (e.g., for polytonic accents and breathings) by assigning distinct CID ranges in the CMap, allowing seamless support for mixed-script text like classical literature without duplicating shared metrics. This approach reduces file size and improves interpreter performance by loading only relevant subfonts as needed.[10][10][10]
Type 42 fonts serve as a specialized composite variant, acting as a PostScript wrapper for TrueType fonts to enable their use in PostScript interpreters equipped with TrueType rasterizers, first supported in PostScript version 2010. The structure includes a FontType of 42, an identity FontMatrix, an sfnts array of strings embedding the TrueType sfnt tables (such as cmap for character mapping, loca and glyf for outlines), and a CharStrings dictionary mapping glyph names to indices for PostScript compatibility. Rendering proceeds by using the embedded TrueType tables: character codes are mapped via cmap, then resolved to outlines for rasterization, preserving the original TrueType quality without conversion to Type 1 outlines. An optional unique identifier (XUID) allows glyph bitmaps to be cached across jobs for efficiency. Type 42 fonts support subsetting and incremental downloading, making them suitable for large CJK TrueType collections, and function as a bridge between TrueType ecosystems (common in Windows and web applications) and PostScript printing environments, avoiding the need for full font conversion. Introduced in PostScript Language Level 2 alongside Type 0, they extend composite capabilities to non-PostScript outline formats while maintaining the hierarchical and modular advantages for complex scripts.[14][14][14]
Specialized and Legacy Types (Type 2, 4, 5, 9-11, 14, 32)
Type 2 fonts represented an early implementation of encrypted outline fonts in the PostScript language, predating the standardized Type 1 format and utilizing a basic encryption scheme for protecting font data during distribution. This approach was intended to safeguard proprietary glyph outlines but was abandoned due to vulnerabilities in the encryption method, which allowed unauthorized decryption and rendering the format obsolete by the late 1980s.[15] Types 4 and 5 fonts were developed for low-resolution output devices, such as early laser printers with limited processing power, where Type 4 provided a pure bitmap representation of glyphs stored as pixel-aligned rasters for efficient rendering on font cartridges or ROM. Type 5 is similar to Type 4 but compressed for storage in the ROMs of PostScript printers, also known as a CROM (Compressed ROM) font. For bitmap scaling in these types, nearest-neighbor interpolation was employed to map pixels directly without smoothing, preserving sharpness at low pixels-per-inch resolutions typical of 300 PPI devices. These formats saw limited adoption beyond specialized hardware and were phased out in the 1990s as outline-based fonts gained prevalence for higher-quality rendering.[16] Types 9, 10, and 11 are CID-keyed fonts that store Type 1, Type 3, and Type 42 glyphs, respectively, in a format compatible with the Macintosh operating system, integrating PostScript compatibility with Macintosh-specific resource management. They emerged as proprietary extensions primarily for Apple Macintosh systems, facilitating seamless character mapping for Macintosh Roman and Symbol sets in cross-platform workflows, but their platform-specific design restricted broader use and led to deprecation following the shift to TrueType in the early 1990s. Type 14, known as the Chameleon format, was introduced in PostScript Level 3 to enable dynamic font substitution within printer ROMs, employing a compact master font dictionary paired with variant descriptors to generate multiple styles from a single base without duplicating outlines. This memory-efficient approach supported 112 Latin-based core fonts but was confined to embedded printer applications, with no support in host-based rendering software like Ghostscript. Its specialized role contributed to its legacy status post-1990s.[12][17] Type 32 fonts act as a PostScript wrapper for OpenType fonts using the Compact Font Format (CFF), allowing post-2000 embedding of CFF-based outlines in PDF files and PostScript streams while maintaining compatibility with legacy interpreters. Unlike earlier bitmap types, Type 32 supports scalable vector data derived from Type 2 charstrings, but Adobe Distiller explicitly excludes support for it in PDF generation to favor native formats. Although most specialized PostScript font types were phased out after the 1990s in favor of OpenType and TrueType, Type 32 persists for transitional PDF workflows involving converted CFF content.[18]Core Font Set
PostScript Level 1 Core Fonts
The PostScript Level 1 core fonts comprise a set of 35 base fonts standardized by Adobe in 1985 for embedding in printer ROMs, ensuring reliable text rendering across compatible devices without the need for external font downloads. These fonts form the foundational typography library for PostScript interpreters, focusing on Western European characters using the StandardEncoding scheme. Designed primarily as outline fonts (Type 1 format), they leverage cubic Bézier curves for scalable vector descriptions, allowing high-quality output at various resolutions. The set includes variations across 10 primary families, providing regular, bold, italic/oblique, and specialized styles to support diverse typographic needs in desktop publishing and printing. Key families and their variants are as follows:| Family | Variants | Notes |
|---|---|---|
| ITC Avant Garde Gothic | Book, BookOblique, Demi, DemiOblique | Condensed geometric sans-serif; example of variants with adjusted widths for compact layouts. |
| ITC Bookman | Demi, DemiItalic, Light, LightItalic | Serif with high contrast; supports standard kerning pairs for improved readability. |
| Courier | Regular, Oblique, Bold, BoldOblique | Monospaced typewriter-style; based on IBM's 1955 Selectric design for code and fixed-width text. |
| Helvetica | Regular, Oblique, Bold, BoldOblique, Narrow, NarrowOblique, NarrowBold, NarrowBoldOblique | Sans-serif; originates from Linotype's 1957 design by Max Miedinger, licensed by Adobe for PostScript. |
| New Century Schoolbook | Roman, Italic, Bold, BoldItalic | Serif with open counters; suited for body text. |
| Palatino | Roman, Italic, Bold, BoldItalic | Humanist serif; elegant for headlines and books. |
| Times | Roman, Italic, Bold, BoldItalic | Serif; adapted from Monotype's 1932 design for The Times newspaper, emphasizing legibility. |
| Symbol | Regular | Mathematical and Greek symbols; non-text encoding. |
| Zapf Chancery | MediumItalic | Calligraphic script for decorative use. |
| Zapf Dingbats | Regular | Pictorial symbols and ornaments. |
PostScript Level 2 and 3 Core Fonts
PostScript Level 2, introduced in 1990, expanded the core font set beyond the original 13 fonts of Level 1 to a standardized collection of 35 base fonts, primarily Type 1 outline fonts, to enhance compatibility and typographic versatility in printing environments.[10] This expansion included nine additional outline font families, such as ITC Avant Garde Gothic (with Book, Book Oblique, Demi, and Demi Oblique variants), ITC Bookman (Light, Light Italic, Demi, Demi Italic), Palatino (Roman, Italic, Bold, Bold Italic), and New Century Schoolbook (Roman, Italic, Bold, Bold Italic), alongside variants of existing families like Helvetica Narrow and the inclusion of Symbol and Zapf Dingbats.[19] These additions supported improved rendering for diverse document types, with font metrics incorporating features like optical scaling for better legibility across sizes.[10] Level 2 also introduced composite font support via Type 0 fonts, enabling more efficient handling of complex character sets.[20] Building on this foundation, PostScript Level 3, released in 1997, further broadened the core font set to 136 fonts, incorporating over 100 new additions to accommodate emerging platforms like Windows 95/NT, Macintosh systems, Microsoft Office, and the HP 110 font collection.[12] Key new families included Albertus (Light, Roman, Italic), Antique Olive (Roman, Italic, Bold, Compact), Apple Chancery, Arial (Regular, Italic, Bold, Bold Italic), Bookman expansions, Palatino variants, and symbol sets like Microsoft Wingdings and Apple Hoefler Text Ornaments, with Dingbats receiving significant extensions for decorative elements.[12] These fonts were provided in formats such as Type 1, TrueType (via Type 42), and the new Chameleon format for 112 ROM-resident fonts, alongside the Compact Font Format (CFF) which reduced storage by 50-60% and facilitated embedding in documents like those produced by Adobe Acrobat 3.0.[12] Level 3 enhancements emphasized international compatibility, particularly through composite font support for the Adobe Central European (CE) character set, which added 253 characters, enabling coverage of languages like Baltic, Turkish, Czech, Hungarian, and Polish for a total of 315 glyphs.[12] Licensing terms for these core fonts permitted embedding in PostScript files and PDFs, promoting widespread adoption while maintaining Adobe's control over distribution.[12] Although Level 3 introduced capabilities for color separations in printing, the core font set focused on monochrome outline and bitmap glyphs rather than native color fonts.[10] By Level 3, the cumulative core set, including variants, reached up to 136 base fonts, providing a robust foundation for professional typesetting.[12]Supplementary and Third-Party Fonts
In addition to Adobe's official core font sets, URW++ Design and Development Incorporated provided a collection of 35 high-quality Type 1 PostScript fonts as metric-compatible alternatives to the standard base 35 PostScript fonts, enabling broader compatibility in open-source environments.[17] These URW++ fonts, such as Nimbus Roman No. 9 L, which closely mirrors the design and metrics of Times New Roman, were developed in the 1980s and integrated into systems like Ghostscript for free distribution.[21] The base 14 subset of these URW++ fonts, including equivalents for Courier, Helvetica, and Times-Roman, became essential for PDF compliance, serving as drop-in replacements in PostScript Level 1 implementations without requiring proprietary Adobe licensing.[17] Monotype and Linotype, major type foundries, extended the PostScript ecosystem through licensed contributions of their extensive font libraries, converting classic designs into Type 1 formats for digital typesetting. For instance, Gill Sans, originally designed by Eric Gill and released by Monotype in 1928, was adapted as a PostScript font family in the late 1980s, offering humanist sans-serif styles with multiple weights and italics for professional printing and display applications.[22] Linotype's involvement, particularly after its merger with Monotype in 2006, included PostScript versions of families like Frutiger and Optima, which provided high-fidelity outline rendering on PostScript devices and were widely licensed for use in Adobe applications.[23] Custom PostScript fonts, particularly Type 3 variants, allowed users and third-party developers to create specialized typefaces for unique purposes, bypassing the encryption and hinting of Type 1 fonts. Type 3 fonts, defined using PostScript's general graphics operators, were often employed for bitmap-based or procedurally generated glyphs in technical illustrations, maps, or experimental designs where precise control over rendering was needed.[24] Third-party foundries like Font Bureau produced bespoke PostScript font sets, such as custom sans-serifs and display types for branding, emphasizing scalable outlines tailored to client specifications in the pre-OpenType era.[25] In the 2020s, open-source PostScript fonts have gained prominence through distributions like Ghostscript, which bundles URW++ alternatives and supports the creation of custom Type 1 and Type 3 fonts for archival and rendering needs.[26] These fonts ensure compatibility with PDF/A standards for long-term document preservation, as Ghostscript's interpreter handles Type 1 outlines in conformance with ISO 19005 specifications.[27] PostScript font licensing has evolved from Adobe's proprietary model in the 1980s and 1990s—characterized by high fees and restricted distribution—to partial open standards following industry shifts post-2010. Adobe's 2021 announcement to end Type 1 support by January 2023 accelerated the transition to OpenType, an open specification co-developed with Microsoft, allowing foundries to release PostScript-compatible outlines under more permissive licenses while phasing out encrypted Type 1 formats.[1] This change, driven by competition and standardization efforts, has encouraged third-party vendors to offer convertible PostScript assets, reducing barriers for legacy integration.[2]Character Sets and Encodings
Standard Roman and Western Encodings
PostScript fonts employ several standard encodings to map character codes to glyphs for Roman and Western European scripts, ensuring compatibility with Latin-based text in documents and printing. These encodings are defined as 8-bit arrays in the PostScript language, typically supporting up to 256 positions, though the number of defined glyphs varies. They prioritize ASCII fundamentals extended with diacritics, symbols, and typographic elements suitable for Western languages, excluding complex scripts like CJK.[10] The StandardEncoding serves as the foundational mapping for Type 1 fonts, accommodating 240 characters that include the full ASCII set (codes 0-127) plus extensions for basic Western symbols and spacing. For instance, code 0xA0 is assigned to the non-breaking space, while positions 0-31 and 127 are often reserved for control characters or mapped to the .notdef glyph. This encoding is built into the PostScript interpreter's system dictionary and acts as the default for Latin-text fonts, enabling straightforward rendering of English and simple European text without accents.[10][28] ISOLatin1Encoding extends compatibility with international standards by aligning with ISO/IEC 8859-1, supporting 256 characters that incorporate Western European accented letters and symbols. It builds on StandardEncoding by reassigning positions 160-255 to include glyphs like é (0xE9), ü (0xFC), and À (0xC0), facilitating text in languages such as French, German, and Spanish. This encoding is also predefined in the PostScript system dictionary, allowing fonts to switch via the Encoding key for broader Western coverage without altering the core Roman base.[10][28] AdobeStandardEncoding, a PostScript-specific variant, enhances typographic precision with dedicated slots for expert glyphs, including ligatures such as fi and fl, as well as old-style figures and fractions. It maintains the 256-position structure but prioritizes professional typesetting elements over some ISO mappings, making it ideal for Adobe's Type 1 font library where aesthetic details like swashes or superiors are needed. This encoding is referenced in font dictionaries to access supplementary Roman variants beyond basic ASCII.[29][10] For PostScript Level 2 and higher implementations, Western 2 Encoding—also known as WinAnsiEncoding—adapts to Windows-1252 code page conventions, supporting 256 glyphs with adjustments for Microsoft environments. It diverges from ISO 8859-1 in positions like 0x91-0x94, which map to curly single and double quotes instead of control codes, and includes the euro symbol (0x80) for modern Western text. This ensures seamless integration with Windows applications while preserving Roman and Western European character support.[10][28]| Encoding | Character Positions | Key Features and Examples | Primary Use Case |
|---|---|---|---|
| StandardEncoding | 256 (240 defined) | ASCII + non-breaking space (0xA0); .notdef for controls | Base for Type 1 Latin fonts |
| ISOLatin1Encoding | 256 | Accented chars: é (0xE9), ü (0xFC) | ISO 8859-1 Western European text |
| AdobeStandardEncoding | 256 | Expert glyphs: fi ligature, old-style figures | Typographic PostScript fonts |
| WinAnsiEncoding | 256 | Curly quotes (0x91-0x94), euro (0x80) | Windows-compatible Western text |
International and CJK Encodings
PostScript introduced support for international character sets beyond the standard Roman encodings through multi-byte schemes, particularly for complex scripts in Central/Eastern Europe and East Asia, enabling global typography in documents and printing. These encodings leverage composite fonts (Type 0) with CID-keyed structures to handle large glyph sets efficiently, where character codes are mapped to unique Character Identifiers (CIDs) via CMap resources.[30] For Central and Eastern European languages, Adobe CE encoding extends the ISO Adobe (Latin-1) set to include characters necessary for languages such as Croatian, Czech, Estonian, Hungarian, Polish, Romanian, Slovak, and Slovenian, aligning with ISO 8859-2 standards. Introduced in PostScript Level 2, this single-byte encoding adds diacritics and special letters like ć, ł, and ň, supporting up to 256 characters while maintaining compatibility with Western scripts.[31] In East Asia, Adobe developed dedicated CID-keyed collections for Chinese, Japanese, and Korean (CJK) scripts, which require thousands of glyphs due to logographic systems. Adobe-GB1, based on the GB 2312-80 standard for Simplified Chinese, encompasses 7,717 glyphs in its initial collection (GB1-0), including 6,763 hanzi and associated punctuation, encoded via double-byte sequences in EUC-CN or GBK formats for PostScript Type 0 fonts.[32] For Traditional Chinese, Adobe-CNS1 draws from the Big5 encoding and CNS 11643 Planes 1 and 2, providing 13,053 glyphs in CID form within the CNS1-0 collection, covering traditional hanzi, bopomofo, and Taiwanese extensions to support horizontal and vertical writing modes in composite fonts.[33] Adobe-Japan1 and Adobe-Japan2 address Japanese typography, rooted in Shift-JIS encoding, with Japan1 including over 6,000 kanji from JIS X 0208 and extensions, totaling 8,284 glyphs in its initial version (Japan1-0) for hiragana, katakana, and vertical typesetting. Japan2 supplements this by adding vertical variants and JIS X 0212 characters, enabling efficient CID mapping for composite PostScript fonts in publishing workflows.[34] The Adobe-Korea1 collection supports Korean text per KSC 5601, featuring 2,350 precomposed Hangul syllables alongside 488 hanja and compatibility characters, structured as 9,333 CIDs (CIDs 0–9,332) in Korea1-0 for double-byte EUC-KR encoding in CID-keyed Type 0 fonts.[35] Central to these international encodings is the CID-keyed structure in PostScript composite fonts, where CIDs serve as 16-bit indices (up to 65,535 glyphs) for glyph access, extensible to 32-bit in advanced CMaps for larger collections; this allows a single font resource to reference multiple subfonts via an FMapType 9, optimizing storage and rendering for multi-script documents.[30]File Formats and Storage
Binary and ASCII Font Files
PostScript Type 1 fonts are stored in two primary file formats: Printer Font Binary (PFB) and Printer Font ASCII (PFA), which serve as wrappers for the underlying font program data.[8] The PFB format encapsulates the font data in a compact binary structure, consisting of three segments each preceded by a 6-byte header. The header begins with the byte value 128 (0x80 in hexadecimal), followed by a segment type identifier (1 for ASCII text, 2 for binary data, or 3 for the end marker), and then a 4-byte length field indicating the size of the subsequent data, with the most significant byte last.[15] Typically, the first segment (type 1) contains the initial ASCII header of the font program, including comments and the font dictionary up to theeexec encryption command; the second segment (type 2) holds the binary encrypted portion with glyph outlines; and the third segment (type 3) is a trailer of 512 zero bytes to mark completion.[15] This segmentation allows for efficient storage and transmission, particularly when binary data must be converted to hexadecimal for 7-bit channels, as the PostScript interpreter handles decryption of the eexec-encrypted sections using a key of 55665 followed by charstring-specific encryption with key 4330.[8]
In contrast, the PFA format represents the entire font program as a single ASCII text file, with binary encrypted sections encoded in hexadecimal pairs to ensure compatibility with text editors and 7-bit data channels.[8] It lacks the explicit segment headers of PFB, instead relying on PostScript syntax within the font dictionary, such as /FontName and length indicators like /Length1 for the encrypted portion before the eexec command.[36] The structure follows the standard Type 1 font program organization: an initial header with font metadata and encoding vector, the Private dictionary containing hinting parameters, the CharStrings dictionary defining glyph outlines as encrypted procedures, and an encoding array mapping characters to glyphs.[8] Whitespace is permitted in PFA except in the first eight characters after encryption start, facilitating readability while the interpreter decodes the hex to binary during execution.[8]
PFB files, commonly using the .pfb extension, are preferred for applications on Microsoft Windows and classic Macintosh systems due to their compactness, enabling easier embedding in documents and reduced storage needs.[15] PFA files, with the .pfa extension, are used where ASCII compatibility is essential, such as in direct PostScript program inclusion via commands like (fontname.pfa) run.[36] The binary nature of PFB typically halves the file size compared to PFA, as hexadecimal encoding doubles the space required for the same data.[36] These formats often pair with supplementary metrics files for full font implementation, as detailed in related specifications.[37]