Display PostScript

related topics
{system, computer, user}
{math, number, function}
{law, state, case}

Display PostScript (or DPS) is an on-screen display system. As the name implies, DPS uses the PostScript (PS) imaging model and language to generate on-screen graphics. To the basic PS system, DPS adds a number of features intended to ease working with bitmapped displays and improve performance of some common tasks.

While early versions of PostScript display systems were developed at Adobe Systems, the full implementation of Display PostScript was developed for Sun Microsystems' NeWS in 1986. NeXT also developed a Display PostScript system in cooperation with Adobe in 1987. It was an official Adobe product with its own standards, documents and licensing requirements.

Contents

Changes from Ordinary PostScript

In order to support interactive, on-screen use with reasonable performance, changes were needed:

  • Multiple execution contexts: Unlike a printer environment where a PS interpreter processes 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 state data) active, one for each process (window).
  • Encoded names: Many of the procedures and data structures in PostScript are looked up by name, string identifier. In DPS these names could be replaced by integers, 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: 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 halftones 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 showpage 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 fonts and change from one to the other on the fly. While PS's ability to display fonts on "low resolution" devices was good, "low resolution" meant something on the order of 300 dpi, not the 96 dpi that a NeXT screen used. This resolution required hand-built bitmap fonts to provide reasonable quality.
  • 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. 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.

Full article ▸

related documents
Common Gateway Interface
Adware
Applesoft BASIC
G.711
Fiber distributed data interface
CHS conversion
Context menu
Encryption
Fluent, Inc.
Edlin
ICab
BINAC
IP over Avian Carriers
32-bit application
FastTrack
EDVAC
Automatic number announcement circuit
Links (web browser)
Wiki software
Intel 80186
Z3 (computer)
UserLand Software
Z/OS
IBM 704
Evolution (software)
MOS Technology 6510
AMOS (programming language)
Interior Gateway Routing Protocol
Nascom
Microphone array