Mac OS 9 to OS X: Printing and Font Changes

The transition from Classic Mac OS 9 to the Unix-based Mac OS X fundamentally altered the architecture of the Macintosh operating system. By replacing the legacy QuickDraw imaging model and resource-fork-dependent structures with modern subsystems like Quartz and standard Unix frameworks, Apple completely redefined how print pipelines and typography were managed. This transition shifted printer drivers from monolithic Chooser extensions to modular, standardized print drivers, while transforming font suitcases from fragile, dual-fork containers into resilient, cross-platform font formats.

The Evolution of Printer Drivers

In Mac OS 9, printing relied heavily on QuickDraw, the system’s primary 2D graphics engine. Printer drivers were treated as system extensions located within the "Extensions" folder inside the System Folder. Users selected and configured devices through the classic "Chooser" desk accessory. Because QuickDraw handled display output differently than how PostScript or raster printers produced hard copies, developers had to write extensive custom code within the driver to translate QuickDraw calls into printer-specific instructions.

With Mac OS X, Apple introduced the Quartz 2D graphics engine, which was built on the Portable Document Format (PDF) specifications. This unified the display and print rendering models. Instead of relying on proprietary QuickDraw translation layers, Mac OS X adopted modular PostScript Printer Description (PPD) files and raster filters.

Starting in Mac OS X 10.2 (Jaguar), Apple integrated the Common Unix Printing System (CUPS) as the core spooler and filtering engine. Printer drivers shifted from monolithic Mac-specific binaries to modular driver packages placed in /Library/Printers/. CUPS allowed Mac OS X to convert Quartz-generated PDFs into PostScript or raster data through standard filter pipelines, drastically simplifying driver development, enabling native network printer sharing, and eliminating the need for the Chooser.

The Modernization of Font Suitcases

Typography in Mac OS 9 depended on "font suitcases." These suitcases were not individual files in the modern sense; rather, they relied entirely on the Classic Mac OS file structure, which split every file into a "data fork" and a "resource fork." A font suitcase stored bitmap screen fonts and metric data inside the resource fork under specific resource types (FOND, NFNT, and FONT). If a user utilized PostScript Type 1 fonts, the suitcase held only the screen metrics, requiring separate printer outline font files to sit alongside the suitcase in the system's single Fonts folder.

This dual-fork structure presented severe issues when transferring files over standard non-Mac networks, the internet, or to PC systems, as any transfer mechanism unaware of the Apple HFS file system would discard the resource fork, rendering the font completely empty and unusable.

Mac OS X restructured fonts by moving away from resource forks toward standard, single data-fork files:

  • Data-Fork Suitcases (.dfont): Apple created the .dfont format as an interim transition bridge. It took the exact data previously stored in the resource fork and moved it entirely into the data fork, allowing legacy Mac font data to survive on Unix and PC filesystems.
  • Native OpenType and TrueType: Mac OS X prioritized industry-standard OpenType (.otf) and TrueType (.ttf) fonts, eliminating the need to maintain separate outline and bitmap files for a single typeface.
  • Apple Type Services (ATS): Apple introduced the ATS framework to handle font rendering, discovery, and activation, replacing the manual caching and loading behavior of Mac OS 9.

Structural Path and Permission Changes

The shift also introduced a hierarchical domain structure that replaced the single-user, flat folder layouts of Mac OS 9. Instead of dumping all printer extensions and fonts into a single, global System Folder, Mac OS X divided them across three distinct administrative levels:

  • System Domain (/System/Library/): Reserved strictly for protected operating system fonts and core print services, preventing user modification.
  • Local Domain (/Library/): Dedicated to shared fonts and printer drivers installed by administrators for all local users.
  • User Domain (~/Library/): Allowed individual non-administrative users to install custom fonts within their personal home directories without affecting other accounts on the machine.