Display PostScript: Difference between revisions

Revision as of 19:09, 27 September 2004

Revision as of 07:46, 5 October 2004

Line 9:

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

*''halftone phase'': [[halftone]]s needneeded to be matchedpositioned toby the deviceprogram. theyAt arethe printedtime onredrawing inan orderentire scrolling window's contents was considered too expensive and would produce flashing due to avoidthe lace of [[moirédouble patternbuffering]]s. SinceBut if you moved the [[display]] canand bethen moveddrew andonly changedthe onnew contents, the flyhalftones would not line up, DPSproducing addedvisible thelines abilityand forboxes in the devicedisplay toof changegraphics. theModern halftoningfull-color todisplays with no halftones have made this idea mostly matchobsolete.

*''[[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.

Line 17:

*''[[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.

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 [[International Business Machines|IBM]] and [[Silicon Graphics|SGI]] for their workstations. Often the code needed to get from an X window to a DPS context was much more complicated than the entire rest of the DPS interface, this greatly limited the popularity of DPS when any alternative was available.

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 itselflibrary [[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 happened, but speculation suggests that Adobe was asking for a high [[licensing fee]].