Display PostScript

NeXT Computer Inc. designed Display PostScript (or DPS) for their series of Unix-based personal computers starting around 1987. Display PostScript was developed with (or given to) Adobe, and made an official Adobe product with its own standards documents and licensing requirements.

Display PostScript is a fairly limited expansion on the original PostScript language. In order to support interactive, on-screen use with reasonable performance, a few changes were needed:

• multiple execution contexts: unlike a printer setting where the PS interpreter had only one job at a time, DPS would be used in a number of windows at the same time, each with their own settings (colors, brush settings, scale, etc.). This required a modification to the system to allow it to keep several "contexts" (sets of data) active, one for each process (window).

• encoded names: many of the procedures and data structures in PostScript are looked up by name. In DPS these names could be replaced by small numbers, which are much faster for a computer to find.

• interaction support: a number of procedures were defined to handle interaction, including hit detection

• halftone phase: halftones need to be matched to the device they are printed on in order to avoid moiré patterns. Since the display can be moved and changed on the fly, DPS added the ability for the device to change the halftoning to match.

• incremental update: in printing applications the PS code is interpreted until it gets a showpage at which point it is actually printed out. This is not suitable for a display situtuation where you need a large number of minor updates all the time.

• bitmap font support: DPS added the ability to map PS fonts onto hand-drawn bitmap fonts and change from one to the other on the fly. While PS's ability to display fonts on "low rez" devices was good, "low rez" meant something on the order of 300dpi, not the 72dpi that a screen used. This required hand-built fonts for reasonable output.

• programming language support: DPS introduced the concept of a "pswrap", which allowed developers to wrap PostScript code into a C language function which could then be called from an application.

DPS did not, however, add a windowing system. That was left to the implementation to provide, and DPS was meant to be used in conjunction with an existing windowing engine. This was often the X Window System, and in this form Display PostScript was later adopted by companies such as IBM and SGI for their workstations.

On the NeXT system a completely new windowing engine was written, to take full advantage of their object oriented operating system. The windowing system itself used PostScript to draw items like titlebars and scrollers. This, in turn, made extensive use of pswraps, which were in turn wrapped in objects and presented to the programmer in object form.

Apple's Mac OS X operating system now makes use of a similar imaging model to Display PostScript, but does not have the same level of programmability. The new system, known as Quartz, is based on the PDF model in which the source of the image is not the PostScript code itself, but the result of interpreting that code. It keeps the basic graphics primitives, font handling and measurements, and in many cases looks and feels like DPS. It is not entirely clear why this happened, but speculation suggests that Adobe was asking for a high licensing fee.

See also:

Portable Document Format

Links:

PostScript Language Reference Manual (http://partners.adobe.com/asn/developer/pdfs/tn/psrefman.pdf)
- includes details on DPS in Chapter 7