The PostScript Thinker

Glenn Reid, principal and founder of RightBrain Software, has

written and published two books with Addison-Wesley on the PostScript Language. Glenn has been kind enough to

spare his time to bring us up to speed on his latest projects and explore PostScript and PDF.

Planet PDF: Glenn, back in 1987, and 1990 you wrote two books that

contributed greatly to the PostScript programming world – namely, Adobe’s ‘Green book’ and ‘Thinking in

PostScript’ – It seems amazing to think that this book is still in print. How is that PostScript has managed to

resist the change that newer programming languages like Java have been plagued with?

Glenn Reid: That’s an interesting question. There are several answers, I

think. First, what the world came to know as PostScript was not in fact the first generation of the language.

It took form as JaM (for John and Martin) when John Warnock was working with Martin Newell, then went through

some more revisions as Interpress at Xerox’s Palo Alto Research
Center, and they rewrote it again as PostScript.

It was mature, well thought-out, and complete when it first shipped. It was intentionally designed to handle

arbitrarily complex documents, rather than being restricted by memory or language limitations. This has proved

incredibly far-sighted, as extremely complex pages
have of course been built that no doubt have exceeded the original expectations of the designers.

PostScript has evolved and had revisions and changes, but the changes mostly are for convenience

(‘rectfill’), advances in color technology (‘setcolorspace’), speed,
or specific printer control (‘setpagedevice’). None of these enhancements are required for most pages. In

fact, there are still compelling reasons to write Level-1 compatible page descriptions, which are ultimately

portable. I rarely reach for Level 2 or Level 3
operators unless there’s a compelling reason to use them.

A second answer is that Java was not really finished when it was released, so there has been a great deal of

work to do. As a language it was fairly complete at first release, but Java is not just a programming

language; it is a ‘platform’, and is only useful when large chunks of operating system software are provided as

libraries and toolkits.

This work is still ongoing. Put another way, the ‘C’ language has not changed much since it was invented,

but you can’t do much with ‘C’ without interacting with the OS toolboxes, whether on Macintosh, Windows, or

UNIX. Java was released before these sub-systems were mature (or even begun, in many cases). The language

itself has not changed much, but the sub-systems are still changing wildly. With PostScript, the sub-systems

were there from the beginning (file operations, for example), although substantial extensions were made for

Display PostScript/Level 2.

Planet PDF: In your book – you mention that one needs to ‘Think in

PostScript’ in order to be a truly successful PostScript programmer? Can you provide us with a few examples

that demonstrate this.

Glenn Reid: The most common one that comes to mind, which in fact motivated

an entire chapter in the book (‘Trusting the Stack’) is that programmers typically think in terms of

‘variables’. There are no variables in PostScript. All operations are performed on objects on the operand

stack. You can store something in a dictionary with a name and pretend that it’s a variable, but when you

‘use’ the variable, what you’re really doing is pulling it out of the dictionary and putting it back on the

operand stack where it started out.

This is an obvious inefficiency, and good PostScript programmers don’t feel a need to make everything into a

variable. It is, of course, often desirable and even necessary to give intermediate results names and store

them in a dictionary so you can keep track of what you’re doing, since it can be challenging to follow stack

manipulations.

But it is amazing how many procedures you see which take several parameters on the stack, take them off the

stack and put them into variables, then immediately pass those ‘variables’ to a PostScript operator, which of

course puts them right back on the stack where they started. If the ‘variable’ is only used once, there’s

little point in doing that. After a while, when you start Thinking in PostScript, you set up your procedures

to naturally use the objects directly from the operand stack as they are passed in.

Planet PDF: How does PostScript relate to PDF? What exactly does

the Acrobat Distiller do to our .PS files?

Glenn Reid: Well, PostScript is a programming language, and PDF is not.

They share the same Imaging Model, which means that you describe pages using the same mechanisms, coordinate

systems, colors, and even data structures like paths and text and bitmaps. PDF is interpreted, but
it is not executed in the strict sense.

You cannot have a loop in PDF, for example. Some people see this as a good thing, perhaps including me.

What Acrobat Distiller does is to actually execute the PostScript program (which is the only way to truly

determine what it does) but instead of reducing each painting operation to a bitmap, it preserves the

higher-level representation of the shape or object or text and writes out an equivalent bit of PDF into the

output file as it goes along.

This means that it ‘distills’ the PostScript program down to just its essence: the operations that actually

paint on the paper. An example of this might be a loop in PostScript that goes around 30 times, each time

moving slightly down the page and drawing a line. In PostScript this might be expressed something like

this:


35 600 moveto
1 1 30 { 400 0 rlineto -400 10 rmoveto } for
stroke

In the resulting PDF file, the loop itself would be gone, replaced by just the line-drawing operations.

However, since the power of executing a loop is lost, you would now have 30 line-drawing instructions. In the

business, we call this ‘unrolling’ a loop.

Planet PDF: Is it true that you need to have a basic understanding

of PostScript in order to master PDF?

Glenn Reid: Sort of. Mostly you need to understand the imaging model,

which is somewhat complicated. You certainly don’t need to understand the ins and outs of how a PostScript

program executes, the stack and procedures and all that. But you need to understand what a
path is, how text is drawn, what an image is, and how the three fit together into a page description.

Planet PDF: Now, you seem to have a keen interest in woodworking,

how does this relate to PostScript, PDF and programming in general?

Glenn Reid: It doesn’t relate at all, which is sort of the point. People

have different motivations for programming. Mine is largely creative: I like to design and build things, and

programming languages are the ultimate building materials. There are no issues like sagging or breakage or dry

rot or fatigue. A program either works or it doesn’t. And you can make a perfect copy of your program before

you start experimenting, and come back to it if your experiment didn’t work.

What I enjoy about woodworking is mostly the design and partly the execution. I don’t work from plans, I

design everything myself, even fairly complicated furniture and cabinets. That, for me, is the pleasure of it.

But it’s much more challenging than programming
because you can ruin all of it with one mistake.

You have to really think ahead, do things in the right order, and there was never an adage more true than

‘measure twice, cut once, measure once, cut twice.’ And it’s low-tech, which I find appealing at the end of the

day. No monitors, keyboards, or modems. I admit to using woodworking machinery, but if the power goes out,

there’s still a lot I can do.

Planet PDF: What do you think of the new Acrobat 4.0? Can you ever

see us achieving the ubitiquous paperless office?

Glenn Reid: Those are very different questions! I don’t know much about

Acrobat 4.0. I’ll learn it when I need it, like everything else. But I’m sure it’s full of good stuff. I use

PDF for lots of things and truly believe it is great technology. It is ironclad in its platform
independence, and it is often the simplest solution to the gnarly real-world problems of how to get a document

to someone you don’t know. Some people choose Microsoft Word for this task, figuring that the recipient will

own a copy of Word. The rest of us use PDF.

You May Also Like

About the Author: Karl De Abrew

Leave a Reply