A PostScript language procedure is simply an executable array of PostScript objects. Normally, procedures are given a name and stored in a dictionary, so that they may be called up by present- ing the appropriate executable name to the PostScript inter- preter. However, procedures can exist without having names at all (as can any object until it is stored into a dictionary).
A procedure that exists (perhaps on the operand stack) but is not referenced by name is typically referred to as a procedure body. Procedure bodies are usually stored in a dictionary under a particular name and used in the same manner as the built-in operators, although they are also required (or permitted) as argu- ments to several operators, including image, imagemask, setscreen, settransfer, if, ifelse, loop, and forall.
The PostScript language’s mechanism for building and defining a procedure is worth examining more closely:
/F { %def
findfont exch scalefont setfont } bind def
This is a typical procedure definition. It builds a procedure body (in this case consisting mostly of operators), executes bind to dis- till out the name lookup, and then defines the procedure in the current dictionary under the name F.
Let’s look at this sequence as the PostScript interpreter would, token by token:
/F
The scanner digests this as a literal name object and hands it to the interpreter. The PostScript interpreter places all literal objects directly on the operand stack and moves on.
{
This is a special PostScript language delimiter (informally known as a “curly brace,” or “open-curly”). It marks the beginning of a procedure body. The scanner enters deferred execution mode when this character is encountered. All objects through the clos- ing ‘}’ token are scanned but not executed, regardless of their type. When the closing delimiter is found, an executable array is created containing all the collected objects between the ‘{ }’ delimiters.
In most implementations, the scanner uses the operand stack to construct procedure bodies, placing a mark on the stack and then placing each object on the operand stack until the closing
brace is found, at which point the array is constructed from the objects on the stack. This places a practical limitation on the number of objects (which may be composite objects) which can be put into a procedure. In most implementations, this number is 499, which is the depth of the operand stack less 1 for the mark (listing 2-3 contains a method for building much larger pro- cedure bodies when necessary). Here is the state of the stack just before the ‘}’ character is encountered, which causes the objects on the stack (down through the mark) to be collapsed into a single array object.
setfont scalefont exch findfont --mark-- /F
These are all objects of type /nametype, with the exception of the mark, which is of /marktype. The scanner performs no name lookups during the scanning of a procedure body.
When the scanner recognizes the ‘}’ delimiter it performs sever- al functions. First, it decrements the level counter that keeps track of the nesting of curly braces, and if the level is back to 0, the interpreter reverts back to immediate execution mode (which is the normal state of the PostScript interpreter). Next, the scanner performs the equivalent of counttomark array astore: It allocates an array of the appropriate length, fills it with the objects on the stack down through the mark, removes the mark, and leaves a freshly created array object on the stack. The final step is to make the new array an executable array. (It does this by performing the equivalent of cvx.) Here is the state of the operand stack right after the ‘}’ character is processed:
--executable array-- /F
The name /F is still on the bottom of the operand stack, where it was at the beginning of this example. The entire procedure body is now stored in memory as a sequence of objects repre- sented as an executable array object on the operand stack. Note that there is still no procedure named F. There are merely two objects on the operand stack. They could be eliminated very eas- ily by executing the clear or pop operators, for example. It is not until the def operator is finally executed that this array object is safely stored in the current dictionary under the name F. The remaining part of the last line of the program is
bind def
These are two more executable names. Each of these is looked up and executed (since the interpreter is now in immediate exe- cution mode). The effect of executing bind is to perform early name binding on any elements of the array object that may be executable operator names. (See Section 2.5, “OPERATORS AND NAME LOOKUP,” for a discussion of bind.) The bind operator expects to find an executable array on the operand stack, and it leaves one there (possibly containing different objects) when it is through.
The effect of executing def, of course, is to take the top two ele- ments from the operand stack and make a key-value pair associa- tion in the current dictionary. The F procedure is now defined. It can be used like any of the built-in operators in the PostScript language, as long as the dictionary in which it is stored is avail- able on the dictionary stack.
listing 2-2
%!PS-Adobe-2.0 /F { %def
findfont exch scalefont setfont } bind def
24 /Helvetica F 288 72 moveto (Green Book) show showpage
Listing 2-2 would result in something like this being printed on the page:
Green Book
VERY LARGE PROCEDURE BODIES
Occasionally one needs to define a very large procedure body, perhaps as a character description in a font or as part of a logo- type. The operand stack depth limit is typically about 500 ele- ments, which limits the total size of a procedure created while in deferred execution mode, since all the elements in the proce- dure are first placed on the operand stack.
There are a few ways to cope with this problem. The easiest way, if the host application can keep track of how many elements are being generated, is to break out pieces of the procedure and make them separate procedures, invoked by name within the large procedure body:
/small1 { one two three four } def /small2 { five six seven eight } def /small3 { nine ten eleven twelve } def /large {
small1 small2 small3 } def
If the procedure is being generated automatically, rather than by hand, this may not be a feasible approach. For one thing, the number of new (unique) names required cannot be predicted easily. In listing 2-3 is a method for collapsing a large procedure into many small component pieces.
listing 2-3
%!PS-Adobe-2.0
%%Title: collapseproc.ps %%EndComments
/EXEC { /exec load } bind def /mainproc [ %def
{ gsave 400 36 moveto } EXEC { /Times-Italic findfont 24 } EXEC
{ scalefont setfont (from Listing 2-3) } EXEC { show grestore } EXEC
] cvx bind def %%EndProlog mainproc showpage %%Trailer
Notice the use of exec in this example. It is necessary since the component procedure bodies will not be immediately executed when encountered directly (they are simply placed on the operand stack). Also, the relationship between building square bracket arrays and curly-brace procedure bodies is interesting (and crucial to this example). Since the outermost brackets are actually square brackets, all the intervening PostScript code is executed, not deferred. For this reason, in order to place the exec operator in the procedure body, its value must be obtained with load (see the EXEC procedure in the example). Here is what the /mainproc in listing 2-3 looks like after it is built (a lit- tle interactive dialog is shown to show the length of the array, too):
PS> /mainproc load dup ==
{ { gsave 400 36 moveto } --exec-- { /Times-Italic findfont 24 } --exec-- { scalefont setfont
(from Listing 2-3) } --exec-- { show grestore } --exec-- }
PS> length == 8
Each procedure body within the square brackets is built individu- ally, and when the ‘}” token is encountered, each one is col- lapsed into a single (executable) array object on the operand stack. This way the operand stack does not overflow, since it is effectively segmented into smaller pieces. An array of arrays is built, and each sub-array is explicitly executed by exec. The out- ermost array is simply made executable and can be used like any other procedure.
listing 2-4
%!PS-Adobe-2.0 %%Title: addproc.ps %%EndComments
/F { findfont exch scalefont setfont } bind def /S { moveto show } bind def
/addprocs { %def
dup length 2 add array cvx dup 3 -1 roll 2 exch putinterval dup 0 4 -1 roll put
dup 1 /exec load put } bind def
%%EndProlog gsave
currenttransfer { 1 exch sub } addprocs settransfer
36 /Helvetica-Oblique F 1 setgray % normally white...
(Black) 36 670 S % but the inverse transfer (Words) 36 634 S % function yields black grestore
showpage %%Trailer
Another application of this technique is a space-efficient way to concatenate two procedure bodies, as can be seen in listing 2-4. It defines a procedure called addprocs which concatenates two existing procedure bodies. It creates one new procedure body that is the length of the second procedure plus two. The array object representing the first procedure is inserted into the 0th position in the new array, the exec operator is placed in the sec-
ond slot, and the second procedure is copied into the rest of the new procedure body, resulting in a new procedure like this:
{ one two three } { four five six } addprocs => { { one two three } exec four five six }
This preserves at least the first of the procedures without hav- ing to copy it (it is simply executed with exec).