Display PostScript: Difference between revisions

Revision as of 18:57, 24 January 2022

Revision as of 05:40, 26 July 2023

Line 15:

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

* ''Halftone phase'': In order to improve scrolling performance, DPS only drew the small portion of the window that became visible, shifting the rest of the image instead of re-drawing it. However this meant that the [[halftone]]s might 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 updates'': 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 situation where a large number of minor updates are needed 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 font]]s and change from one to the other on the fly. Adobe PS's ability to display fonts on low -resolution devices (significantly less than 300&nbsp;[[Dots per inch|dpi]]) was very poor. For example, a NeXT screen used only 96&nbsp;dpi. This PS limitation was worked around by using hand-built bitmap fonts to provide passable quality. Later implementations of PS (including compatible replacements like [[Ghostscript]]) provided [[anti-aliased]] fonts on grayscale or colour displays, which significantly improved quality. However, this development was too late to be of much use. Modern displays are still around 100&nbsp;dpi,{{update after|2020|1|12}} but have very muchfar superior font quality without using bitmap fonts.

* ''Programming language support'': DPS introduced the concept of a "<code>pswrap</code>", which allowed [[Software developer|developers]] to wrap PostScript code into a [[C (programming language)|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 [[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.{{citation needed|date=March 2011}} This greatly limited the popularity of DPS when any alternative was available.{{citation needed|date=March 2011}}

Line 23:

== History ==

The developers of [[NeXT]] wrote a completely new windowing engine to take full advantage of NeXT's [[object-oriented operating system]]. A number of commands were added to DPS to actually create the windows and to react to events, similar to but simpler than [[NeWS]]. The single API made programming at higher levels much easier and made 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 <code>pswrap</code>s, which were in turn wrapped in objects and presented to the programmer in object form.

== Modern derivatives ==

Line 32:

* [[PostScript Standard Encoding]] (PostScript character set)

* [[NeXT character set]]

* [[NeWS]]

* [[Quartz 2D]]

==References==