About DPS

The Display PostScript system displays graphical information on the computer screen with the same PostScript language imaging model that is a standard for printers and typesetters. [This section is based on Chapter 4 of Programming the Display PostScript System with X by Adobe Systems Incorporated (Addison-Wesley Publishing Company, Inc., 1993) and is used with the permission of the copyright holder.] The PostScript language makes it possible for an X application to draw lines and curves with perfect precision, rotate and scale images, and manipulate type as a graphic object. In addition, X applications that use the Display PostScript system have access to the entire Adobe Type Library.

Device and resolution independence are important benefits of PostScript printers and typesetters. The Display PostScript system extends these benefits to interactive displays. An application that takes advantage of the DPS system will work and appear the same on any display without modification to the application program.

How DPS Works

The DPS system has several components, including the PostScript interpreter, the Client Library, and the pswrap translator. The Client Library is the link between an application and the PostScript interpreter.

Each application that uses the DPS extension creates a context. A context can be thought of as a virtual PostScript printer that sends its output to a window or an offscreen pixmap. It has its own set of stacks, input/output facilities, and memory space. Separate contexts enable multiple applications to share the PostScript interpreter, which runs a single process in the server.

Although the DPS system supports multiple contexts for a single application, one context is usually sufficient for all drawing within an application. A single context can handle many drawing areas. There are exceptions, however, when it is preferable to use more than one context in a client. For example, a separate context might be used when importing Encapsulated PostScript (EPS) files. This simplifies error recovery if an included EPS file contains PostScript errors.

An application draws on the screen by making calls to Client Library procedures. These procedures generate PostScript language code that is sent to the PostScript interpreter for execution. In addition to the Client Library, the DPS system provides the pswrap translator. It takes PostScript language operators and produces a C-language procedure–called a wrap–that can then be called from an application program.

The PostScript interpreter handles the scheduling associated with executing contexts in time slices. The interpreter switches among contexts, giving multiple applications access to the interpreter. Each context has access to a private portion of PostScript virtual memory space (VM). An additional portion of VM, called shared VM, is shared among all contexts and holds system fonts and other shared resources. Private VM can hold fonts private to the context.Figure 2–1 shows the components of DPS and their relationship to X.

Figure 2–1 DPS Extension to X

An application interacts with the DPS system in the following manner:

1. The application creates a PostScript execution context and establishes a communication channel to the server.

2. The application sends Client Library procedures and wraps to the context and receives responses from it.

3. When the application exits, it destroys the context and closes the communications channel, freeing resources used during the session.

The structure of a context is the same across all DPS platforms. Creating and managing a context, however, can differ from one platform to another. The Client Library Reference Manual and Client Library Supplement for X contain information on contexts and the routines that manipulate them, and Display PostScript Toolkit for X contains utilities for Display PostScript developers.