Display PostScript
Display PostScript is an extension of Adobe's PostScript page-description language (PDL) and is designed as an imaging model for graphics displays. In theory, software developers could write the display portions of their applications just once using Display PostScript: These applications would run without modification on any computer and operating system that supports Display PostScript. Another major benefit is that the image on the screen would reproduce identically on a printer supporting the PostScript PDL.
Display PostScript is device-independent, and important feature when you consider that specific dimensional sizing is display-dependent in most graphics handlers. For example, if you write a Display PostScript routine to draw a 2-inch square on the screen, the routine will always draw a 2-inch square on any display supporting Display PostScript, regardless of the resolution, color capability, or size of the output device. In other words, Display PostScript permits a "non--unitized" description of an image until it is interpreted for a particular display.
This non-unitized approach is in contrast to pixel-based graphics handlers that can only handle proportional sizing. Of course, you can also specify proportional sizing and Display PostScript. Additionally, Display PostScript automatically uses the maximum color capabilities of the host display, whether it has just black and white, or 16 million colors. The programmer does not have to worry about the characteristics of the output device while writing the application.
The core of Display PostScript is called the DPS Kernel. The DPS Kernel is an interpreter that translates PostScript routines into the images on the screen and is designed to be machine-independent. The DPS Kernel is supplied precompiled in object format to the OEM.
In addition to the Kernel, Adobe supplies the OEM with "front- and back-end" adapters that consist of source code for interfacing to the display devices, the operating system, and the windowing system. The Display PostScript adapters become part of the host computer manufacturer's system software. Of course, modifying these adapters for the host computer system is not a trivial task, and it is usually undertaken by the OEM as a joint or cooperative effort with Adobe Systems. Again, the important point here is that the software developer need not worry about these "adapters."
The main underlying concept of Display PostScript is to isolate the display operation from not only the host computer's operating system but also from its windowing system. The core of Display PostScript fits inside the host windowing system, which in this case is the NeXT windowing system, although it could be anything from Microsoft Windows to X-Windows to QuickDraw.
While the windowing system handles functions such as cut, paste, and copy, and manages the window boxes on the screen, Display PostScript handles the actual painting of the window's contents. DOS, routines for displaying icons, text fonts, and graphics images have to be written only once using Display PostScript. However, the software developer still has to write separate window calls for each windowing system.
Programmers can use the Display PostScript language directly, or they can use a library of C procedures called PSWrap, which is recognized and interpreted by the DPS Kernel.
NeXT fully supports the PSWrap library, but has added many of its own procedures. Some of these are used by the Application Get to create and manage windows; other procedures handle events, mouse, and cursor operations; and still other support "compositeing."
The composite procedures are multibit pixel operators designed by NeXT's sister company, PIXAR. Each pixel has two values associated with it: its data value (or color), and its alpha value (the data's transparency or opacity). On the cube's 2-bit display, composite and makes an icon transparent as it moves over another object on the screen. These compositing operators are easily expandable and will while the NeXT software to migrate to color displays when the time comes.
From brief glimpses of alpha versions of Display PostScript, several industry observers have concluded that Display PostScript has serious performance problems-- it is too slow. Adobe Systems vehemently denies this and says critics have jumped to conclusions based on preliminary demonstrations. Adobe says Display PostScript is very fast provided the code is written properly.
A number of techniques have been developed to improve Display PostScript's performance, including a binary pre-processor (described below), graphic state objects (multiple PostScript graphic states they can be switched quickly by changing a pointer), and user paths (an aggregate of PostScript drawing commands that represent a PostScript path). NeXT uses these techniques and its own compositing functions to boost the speed of display.
As an example of how binary encoding works, say we want to issue the PostScript operator 72 426 moveto. Normally the DPS kernel would have to translate the ASCII digits 72 and four to six into a floating-point format, and the ASCII moveto operator into a binary code. A lookup table uses this binary code in the DPS Kernel to steer execution to the routine that implements the moveto operation. A NeXT application normally calls a PSWrap function, PSmoveto( ), that passes the IEEE 75 for floating-point values of the numbers to the DPS Kernel, along with the corresponding binary code for moveto. This effectively eliminates the overhead of the ASCII translation stage for the DPS Kernel. The NeXT DPS Kernel can process ASCII PostScript commands if required.
Display PostScript has one major limitation in that it does not support three-dimensional imaging. It is therefore not suitable for CAD software. Adobe admits that Display PostScript is not intended for high-and mechanical design applications. (Steve Jobs said that NeXT will support the Renderman Standard, which he called "the PostScript of three-dimensional graphics.")
Display PostScript has some very compelling features for software designers and for end-users. It could greatly facilitate the porting of software applications across incompatible hardware systems.
But the various competitors for display standards-- such as IBM and Apple-- will have to make some compromises before Display PostScript can succeed. Until these compromises are made, both the end-user and the software developer will continue to be plagued by an incompatible world of competing display standards.