If you mix up the index and the value, you will very likely get an error, although not always, if the values are still within range. Remember that the PostScript operators themselves don’t know what you have in mind. They are flexible, and will allow you to do things that you may not have intended. It is very easy to lose track of what is on the operand stack, or to supply incorrect operands to some operator, leading to bugs in your program that are sometimes difficult to locate.

GROUPING AND VISUAL CHUNKING

One of the best ways to learn to read and write PostScript programs is to be able to “chunk” together sequences of instructions into a block that has a well-understood input and output. In many programming languages, you can usually read a single line of the source code and make sense of it. In fact, usually one line of the program represents a single statement in that language, which may be an assignment statement or a procedure call. But in the PostScript language, the statements can get fairly complex, and each operator and its arguments represents one phrase of the statement. The programs that are the most difficult to read are those that use one operator to manufacture the arguments for the next operator.

Let’s look quickly at two examples that illustrate the concept of one operator leaving behind results that become arguments for the subsequent operation. The first case (Example 5.2) shows a series of code samples of gradually increasing complexity, culminating in some that may look a little bit confusing at first glance. Take a moment to mentally execute the program to see what it does.

Example 5.2: Each Operator Uses the Operand Stack

%currentgray leaves result for setgray currentgray 1 exch sub setgray

%save leaves a value for restore (“3 exch” is just there to confuse you) save 3 exch restore

%search leaves three strings and a boolean

(ABCD) (B) search { = pop = flush }{ = flush } ifelse

Example 5.3 is an extremely familiar program fragment that is actually somewhat tricky in its operation. The findfont operator returns a dictionary that is used by the scalefont operator, and if you ever mix up the order of these operators, you might never even know that this object was there, since it no sooner is produced than it is consumed again. The (Testing) exch part of this example demonstrates that there really is a font dictionary on the operand stack, and if you put something else on top of it and use exch to flip the two, scalefont will still have the right information on the stack to perform its task, but the string will now be on the bottom of the stack, ready to be used by show at the end of the example.

Example 5.3: The findfont Operator Returns a Dictionary

/Times-Roman findfont (Testing) exch 12 scalefont setfont show

The secret to “visual chunking” is to recognize an operator and its operands in the middle of a program segment. You might have noticed several candidates for visual chunking in the short program of Example 5.3. Even if you didn’t, with a little practice, you’ll learn to chunk program fragments together visually, greatly improving your ability to read PostScript code. There are really three kinds of things you can see:

1.A sequence of operators that, combined, yields a new object or group of objects on the operand stack.

2.A sequence of operators that may rearrange or duplicate some elements of the stack, but which do not inherently add anything new to the stack.

3.Operations that consume or otherwise remove things from the operand stack.

Visual chunking for the code of Example 5.3 is illustrated graphically in Figure 5.3.

After a while, you start to see bigger chunks all at once, which makes it much easier to follow the program.