Desktop design

Last month, I looked at the history of desktop publishing (DTP) and its effect on paper-based design, but the 1984 launch of the Apple Macintosh and its Graphical User Interface (GUI) also opened up an entirely new publishing medium that’s set to become even more important than paper – the computer screen itself. The Mac’s significance for screen-based design was that it pushed aside the text-only, character-based PC displays then dominant and instead treated the computer screen like a sheet of blank paper, right down to having black pixels on a white background. Treating the whole screen as an addressable bitmap enabled pictures and, most crucially, multiple typefaces to be presented in rich onscreen layouts.

At launch, the Mac’s bitmapped display and its dot-matrix ImageWriter printer operated in perfect harmony at 72dpi, so the same bitmapped fonts could be used on screen and paper. However, the print quality simply wasn’t acceptable, and bitmapped fonts weren’t scalable – bitmap-based rendering required storing a version of every typeface and style at every possible point size, which quickly became unworkable, especially at higher resolutions. This impasse was broken in 1985 when Adobe’s PostScript PDL (Page Description Language) moved away from bitmapped to programmatic vector-based fonts. PostScript describes both page layouts and scalable fonts in mathematical terms rather than as arrays of pixels – every page is an executable program that generates the desired final appearance (effectively a full-page vector drawing). At a stroke, pages became resolution-, device- and platform-independent, based on fully scalable Type 1 typeface outlines.

PostScript offered a brilliant solution for highly designed, quality paper output, so the next logical step was to use it to generate screen output too, which is exactly what Adobe provided in 1987 with Display PostScript (DPS), created in collaboration with Steve Jobs (who had just been ousted from Apple) for use on his new NeXT workstations. The most important advantage DPS provided over a bitmapped GUI was that it enabled Type 1 typefaces to be rendered at any size onscreen as well as paper, and its resolution independence meant a 24pt font would actually appear as such on screen. Moreover, future higher-density screens would provide more pixels to render each glyph, so improving onscreen quality. In short, Display PostScript offered a richer, more faithful and future-proof architecture, which, most crucially, was platform-independent and so could be shared with other vendors (for example, on IBM and SGI workstations, as well as NeXT cubes).

However, writing to the screen proved much harder than writing to paper. For example, rather than its target being a single, fixed sheet of paper, a screen description language is faced with multiple, variable-sized, variable-zoom windows. DPS needed to collaborate with host windowing engines like the Unix-based X Window System, which added even more layers of complexity. Plus, DPS needed to deal with user interactions, like hit detection, and support programming languages (for example, to wrap Display PostScript code within C functions). The complexity and processing demands increased by an order of magnitude compared to print PostScript.

Display PostScript also hid a further, fatal flaw: its major strength was its ability to provide high-quality scalable fonts onscreen, but this broke down at small point sizes and low resolutions, where there just weren’t enough pixels to play with, resulting in dropped features and letter stems of varying weight. This can be cured by adjusting the shape of each glyph to the bitmap grid available, which is exactly what Adobe Type 1 fonts’ hinting system achieved, but Type 1 hinting was tailored to the LaserWriter’s 300dpi output and inadequate for the problems of even lower-resolution screen rendering. So for the most important part of onscreen content – the body copy – vector-based DPS had to revert to hand-tuned, bitmapped fonts!