DPS Features and Enhancements
This chapter provides information on the Display PostScript (DPS) extension to the Solaris X server. The following topics are briefly discussed:
Overview information on the DPS system
Solaris font enhancements to DPS
DPS security issues
DPS compositing operators
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:
The application creates a PostScript execution context and establishes a communication channel to the server.
The application sends Client Library procedures and wraps to the context and receives responses from it.
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.
DPS Font Enhancements in the Solaris Server
The Solaris X server includes the following font enhancements to the DPS system:
Support for F3 Latin and Asian fonts
Support for TrueType fonts
See Chapter 4, Font Support for more information.
DPS Libraries
Table 2-1 lists the DPS libraries. The .so and .a files that comprise these libraries are located in the /usr/openwin/lib and /usr/openwin/lib/libp directories. For information on these libraries, see Programming the Display PostScript System with X and PostScript Language Reference Manual.
Table 2-1 DPS Libraries
| Library | Description |
|---|---|
libdps | DPS Client library |
libdpstk | DPS Toolkit library |
libpsres | PostScript Language Resource Location library |
libdpstkXm | DPS Motif Toolkit library |
Adobe NX Agent Support
The context creation routines (XDPSCreateSimpleContext and XDPSCreateContext) in libdps attempt to contact the DPS NX agent if they are unable to connect to the DPS/X extension. The NX client must be started manually, usually during the boot or X startup process.
The Adobe DPS NX agent, which is available from Adobe Systems Inc., is a separate process from the X server and the DPS/X client. When connected to the DPS NX agent, the client's DPS calls are intercepted and converted into standard X Protocol requests. Thus, a DPS client can run on an X server that does not natively support the DPS extension.
DPS Security Issues
The Solaris environment provides, and in some cases exceeds, the X Consortium's X11R5 sample server security levels. In particular, DPS programmers should be aware of two DPS-specific security features: PostScript file operators' inability to access system files, and secure context creation. These features are described below.
System File Access
The PostScript language provides file operations that allow users to access system devices such as disk files. This presents a serious security problem. In the Solaris environment, you cannot--by default--use PostScript file operators to open or otherwise access a system file.
For applications, the client rather than the server should perform necessary file operations. Thus, the client does not need all the same access privileges that the server needs. If you want PostScript file operators to access system files, start the server with the -dpsfileops option (see the Xsun(1) man page). If you attempt to access system files without specifying -dpsfileops, you will get a PostScript undefinedfilename error. This issue is particularly important in the CDE or xdm environment, as the server process is owned by a super-user.
Secure Context Creation
DPS contexts normally have access to global data. This allows a context to look into the activities of another context. For example, one context could intercept a document that another context is imaging. This section describes how to create secure contexts in the Solaris environment.
Section 7.1.1 "Creating Contexts" in the PostScript Language Reference Manual, Second Edition describes three ways that contexts can share VM:
"Local and global VM are completely private to the context." This capability is new with Level 2, and a context created this way is called a secure context.
"Local VM is private to the context, but global VM is shared with some other context." This is the normal situation for contexts created with XDPSCreateContext and XDPSCreateSimpleContext.
"Local and global VM are shared with some other context." This is the situation for contexts created with XDPSCreateContext and XDPSCreateSimpleContext when the space parameter is not NULL.
To create a secure context, use XDPSCreateSecureContext as shown below:
XDPSCreateSecureContext DPSContext XDPSCreateSecureContext(dpy, drawable, gc, x, y, eventmask, grayramp, ccube, actual, textProc, errorProc, space) Display *dpy; Drawable drawable; GC gc; int x; int y; unsigned int eventmask; XStandardColormap *grayramp; XStandardColormap *ccube; int actual; DPSTextProc textProc; DPSErrorProc errorProc; DPSSpace space;
All parameters have the identical meaning to those in XDPSCreateContext, but the context being created has its own private global VM. If the space parameter is not NULL, it must identify a space created with a secure context. A space created with a secure context cannot be used for the creation of a nonsecure context. Specifying a nonsecure space with a secure context or a secure space with a nonsecure context generates an access error.