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
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
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.
OK, so you want to stamp your document. Maybe you need to give reviewers some advice about the document's status or sensitivity. This tip from author Ted Padova demonstrates how to add stamps with the Stamp Tool along with related comments.