Display PostScript: Difference between revisions

Revision as of 03:03, 13 November 2004

Revision as of 23:41, 24 November 2004

Line 1:

[[NeXT|NeXT Computer Inc.]] designed '''Display PostScript''' (or ''DPS'') as a display system 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 Systems|Adobe]] product with its own standards documents and licensing requirements.

DisplayAs PostScriptthe isname aimplies, fairlyDPS limiteduses [[expansion]]the onPostScript theimaging originalmodel [[PostScript]]and language to generate on-screen graphics. In order to support interactive, on-screen use with reasonable performance, a few changes were needed:

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

*''[[encoded name]]s'': 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.

Line 9:

*''[[interaction]] support'': a number of procedures were defined to handle interaction, including [[hit detection]]

*''halftone phase'': [[halftone]]sin neededorder to beimprove positionedscrolling byperformance, theDPS program.only Atdrew the timesmall redrawingportion anof entire scrollingthe window's contentsthat wasbecame consideredvisible, tooshifting expensivethe andrest wouldof producethe flashingimage due to the lackinstead of [[doublere-drawing buffering]]it. ButHowever ifthis youmeant movedthat the display and then drew only the new contents, the halftones[[halftone]]s would not line up, producing visible lines and boxes in the display of graphics. DPS included additional code to properly handle these cases. Modern full-color displays with no halftones have made this idea mostly obsolete.

*''[[incremental update]]'': in printing applications the PS code is interpreted until it gets a <code>showpage</code> 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. DPS included modes to allow semi-realtime display as the instructions were received from the user programs.

*''[[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 72dpi96dpi that a NeXT screen used. This required hand-built fonts for reasonable output.

*''[[programming language]] support'': DPS introduced the concept of a "[[pswrap]]", which allowed [[developer]]s to wrap PostScript code into a C language function which could then be called from an application.

Line 21:

On the NeXT system a completely new windowing engine was written, to take full advantage of their [[object oriented]] [[operating system]]. A number of commands were added to DPS to actually create the windows and to react to events, similar but simpler than [[NeWS]]. The single API made the writing of stuff at higher levels much easier and making NeXT one of the few systems to extensively use DPS. The user-space windowing system library [[NeXTStep]] 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 Computer|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 (Macintosh)|Quartz]], is based on the [[Portable Document Format|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 switch happened, but speculation suggests that Adobe was asking for a high [[licensing fee]].

==See also==