Every programming language was designed with a specific purpose, even if that purpose was to be a “general-purpose programming language.” To use a language effectively, you should understand its design and learn its strengths and weaknesses. PostScript is a full-fledged programming language, and it is possible to accomplish almost any task with it. It includes many high-level language constructs and data structures. The PostScript language is a tool kit filled with hundreds of special-purpose tools. Mastery of the language teaches you to select just the right instrument, swiftly and instinctively, and to use it effectively.

DESIGN FEATURES

PostScript’s most obvious language features are that it is an interpreted language, it is stack-based, and it is heavily oriented toward graphics and typography. These design choices were all made in order to make it useful as a device-independent page description language for imaging on raster devices. These language features also make it a fairly unusual language in which to write programs.

The PostScript language is stack-based (resulting in “backwards” syntax) primarily so that a program can be evaluated with very low overhead in processing and storage. Each instruction can be acted upon immediately, without the need to buffer large amounts of the program.

PostScript is interpreted (rather than compiled) for a couple of reasons. The most obvious one is device independence. If the program remains in source form until it reaches its final destination, it is extremely portable to new computer environments, processors, etc. It is an interpreted language also because documents are often transmitted long distances, archived, or saved and printed many times, and this enables the documents to remain in ASCII text source form for better life expectancy and resiliency in a device-independent environment.

And finally, PostScript is heavily biased toward graphic imaging and typography because it was originally conceived as a mechanism to control raster imaging devices like laser printers and display screens.

The design choices made in the PostScript language have quite an impact on the programmer’s experiences in mastering the language, but they

were not made arbitrarily, nor intended to make the programmer’s life more difficult.

STRUCTURED PROGRAMMING TECHNIQUES

If you have had any formal training in programming, you are familiar with the various structured programming techniques, up through and including object-oriented programming. These techniques vary, but are largely based on the concept of a procedure, or a modular functional unit (sometimes called a black box). A black box is typically any set of operations that has a specific input and output and performs a single task. The mechanics of the operation are hidden from one who uses the black box. This is the notion behind writing procedures, creating software libraries, object-oriented programming, block-structured code; it is a widely recognized technique in computer science.

To start out, PostScript simply isn’t well suited to structured programming, and if you try too hard to formalize the interfaces, declare local variables, and observe many tried and true programming practices, you may end up with a complicated, inefficient, and ill-designed program. On the other hand, if you ignore structured programming techniques and write code off the top of your head, you will probably have something worse. The trick is to borrow enough of the useful concepts from structured programming to make programs readable, easy to maintain, easily debugged, and efficient, while using the expressive power of the language to your advantage.

There is no concept of goto in the PostScript language, or even explicit control transfer, so you don’t have to worry about that particular dogmatic concern. You do have to be careful about procedure-calling interfaces, where they exist, since all program checking is done at run-time.

Many of the concepts in structured programming can be used quite effectively in PostScript. You can define procedures to help you share similar code across parts of your program. You can use the operand stack for your temporary data rather than having many global variables. You can design interfaces between components of your program and pass parametric information on the stack. You can even define functions that return results onto the stack for use by other procedures.

PROGRAMMING TASKS

There are many different kinds of tasks associated with programming. There are data-crunching tasks, user interface tasks, communication with other computers or programs, file operations, graphics, and various others. In some tasks, such as numerical computation, the algorithm by which the task is carried out is of the utmost importance, both for accuracy and for performance. Other tasks, such as user interfaces and graphics, are much more results oriented: what is important is whether it looks good and/or works well. In file operations, arguably the accuracy with which the operations are carried out is the most important aspect of the task, and the algorithm and performance of the task are secondary.

The nature of the task has a strong influence on the programming style and technique. If your purpose is to draw graphics, your programming efforts should be minimal, clear, and used only to streamline the process of drawing. In the PostScript language in particular, graphics programming is the means to the end, not the end in itself. The PostScript Language Reference Manual mentions that any marks made on the page are a side effect of the execution of the program, but from your perspective as a programmer, it is the other way around. The fact that you have to write PostScript programs is a side effect of the fact that you are trying to draw pictures on a PostScript-based system.

WINDOW SYSTEMS, COMMUNICATIONS, AND DISPLAYS

Recently, the PostScript language has evolved from a printer control language into a communications medium on host computers. There are window systems and networks based on the PostScript language. In light of this, there are many new kinds of programming tasks that must be (or can be) carried out in the PostScript language.

One of the more interesting aspects of a window system or communications environment based on a programming language is that you can send an algorithmic description of the picture you want drawn (or of the operation you want carried out) instead of the individual bits or instructions. For instance, if you wanted to draw a grid of parallel lines, both horizontally and vertically, you might express this graphic operation

(which has a strongly repetitive basis) as two loops of instructions. (See Example 1.1. The results of Example 1.1 are shown in Figure 1.1).

Example 1.1: Repetitive Algorithms

%18-pt spacing, 24 lines

0 18 18 24 mul { %for dup 0 moveto 600 lineto

} for stroke

%18-pt spacing, 36 lines

0 18 18 36 mul { %for dup 0 exch moveto 436 exch lineto

} for stroke

Figure 1.1: Output of Example 1.1

This is quite a bit more compact than it would be to draw 60 individual lines, each with its own coordinates and moveto and lineto instructions. In this particular example, 25 percent of the data end up being 0; just avoiding the transmission of those zeroes is significant. The loops above consist of 30 PostScript language tokens to be transmitted, whereas the same program done with moveto and lineto instructions would require 360 PostScript tokens.