Postscript Tutorial
Volume Number: 9
Issue Number: 4
Column Tag: Cover Story
The Postscript Programming Language 
A tutorial introduction to PostScript
By Gregor Koomey, Albany, New York
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
This article is a tutorial introduction to PostScript programming in the
Macintosh environment. We begin with a description of the context and form of the
language, then ease into a practical explication of the concepts of the PostScript
graphics and computational models (using examples that you are actually expected to
type in and send to a printer or emulator), finishing up with a mild discussion of
appropriate hardware and software (including books).
A Little Context
In 1985, Apple introduced the “Laserwriter”, a “smart” printer whose
primary distinction (beside price) was the embedded hardware interpreter of a never
before heard of page description language called “PostScript”, which was (and still is)
developed and licensed by Adobe Systems, Inc. PostScript introduced a high-level,
resolution independent graphics model which served as foundation for subsequent
development of what has become the thriving desktop publishing industry.
PostScript was significant then because it defined a flexible, high-level standard
for the description of artwork (particularly type). Previous printing protocols
required low-level binary encoded data/instruction formats, different for each make
and model of device, be programmed for each new machine that came along. The rather
irrational notion of “degrees of compatibility” became commonplace as consumers
tried to find Epson or HP compatible products which might or might not support any or
all desired features. In general, one could not be sure that a new printer would work
unless the driver software had been written with the exact model in mind. The
typeface was Courier, hard coded into the machine and capable of only minor
modification of the typewriter concept (remember when underlining and italics were a
big deal?)!!
The Macintosh brought to the marketplace a user interface that defined
everything as a raster graphic, including text. As such, it was fairly simple to
introduce multiple typefaces for use in this WYSIWYG environment, each represented
by a sequence of bitmap designs.
Unfortunately, size constraints allow only a few screen and dot-matrix printer
fonts to be stored as bitmaps on a floppy based system. If multiple sizes, or higher
resolution printing are desired, too much disk space is required.
Further, consider the resources that go into rasterizing a simple black and white
300 dpi letter size (8.5 x 11 inch) page. The memory required for the raster buffer
alone is approximately one megabyte (1,051,875 bytes); A full meg on a 1985 Mac
was a luxury, much of which was already taken up by system and application software.
Add color, higher resolution or a larger page size and memory requirements increase
geometrically.
PostScript solved these problems by moving most of the responsibility of
rasterization from the host machine to the printer. Using PostScript with the Mac,
only screen fonts need be available to the computer; the higher resolution bitmaps are
created in the printer, from size independent vector paths that make up the PostScript
font character descriptions. The frame buffer is totally isolated from the host
machine. Most importantly, the graphics model is reasonably compact and high level
enough to allow for easy translation from application to variable resolution printout.
The Language
PostScript, as a machine generated, arbitrary resolution graphics standard, is
easier to learn to manipulate than other comparable systems, such as Quickdraw or
HPGL, because it is itself a well-designed high-level programming language. In order
to learn to use other graphics environments, it is necessary to obliquely manipulate,
through some language such as C, Pascal or Assembler, the procedures or bytecodes
through which graphics are defined. With PostScript, it is possible to develop very
complex systems directly in the language itself; the visceral understanding required to
create a custom application/printer interface comes easily through “hands on”
manipulation of the programming environment.
PostScript is a very high-level language, comparable to LISP. The notion of high
and low level, as used here, refers to conceptual distance from actual machine activity.
The binary stream navigated by the program counter register, on the 680x0 CPU in
your Mac, is the lowest language level, that which is directly interpreted by the chip
itself. The next level up is that of assembly language, followed by the level of C, then
of Basic and Pascal. PostScript, LISP and Prolog are higher still. Basically it’s the
distance of the conceptual basis of the language from implementation details. Machine
language has no level of abstraction, while PostScript has a very strongly abstracted
language model.
The language definition depends almost entirely upon a strictly controlled
interpreter environment model (established and maintained by Adobe, Inc.). It is
interpreted; there is no provision in the Adobe model to compile PostScript language
instructions into object code. The execution model is stream oriented (top down),
using a “postfix notation” (sometimes called “reverse polish”) and a number of
“stacks” (last in first out data structures). The reason for the use of postfix notation
is tied to the intended role of the language; since it is interpreted, and is meant to serve
as an intermediary data format, both generated and consumed by automata (the
application/system and the printer/display), the postfix/stack model minimizes
lexical analysis, thereby cutting down on the overall time consumed in operation while
retaining the flexibility of a very high-level language.
Postfix notation is difficult to understand at first, but once grasped, the
stream/stack model of programming becomes quite intuitive, allowing for efficient,
modular system building. The “operand stack” is the primary system stack upon
which most data is passed to and from the various built-in operators.
Every value in PostScript, including operators and user defined procedures, is a
first class object. This means that a polymorphic protocol exists for manipulation of
all types of values on the stack, in arrays and in dictionary structures.
Name binding is accomplished through the dictionary mechanism. A dictionary is
basically a collection of key/value pairs. After storage, a value is accessible from the
key under which it was stored. The default environment includes two dictionaries on
the dictionary stack, systemdict and userdict, neither of which can be removed;
systemdict is read-only and represents the only interface to system level primitives.
The dictionary stack can take up to 20 active dictionary objects.
Arrays are user-defined objects which define a number of polymorphic slots into
which any PostScript value can be stored or retrieved. The length, or size, of an array
is established at the time of creation of the array object.
The procedure is an array with an executable attribute. Upon execution a
procedure body executes each of its objects in turn. Invocation is accomplished
through the dictionary mechanism by storing a procedure as value in an active
dictionary and calling it through use of its key as an executable name; there is also an
explicit “exec” operator, which takes a procedure body on the stack. The procedure
data structure allows a programmer to store commonly used sequences of operations to
be called as a single name. Fonts are basically dictionaries that include a procedure
definition for each character to be drawn.
Variables are implemented using the dictionary mechanism. After definition of a
key/value pair, the value can be redefined without limit. Think of the value as a slot
for arbitrary polymorphic storage.
The graphic model is designed around the concept of the page. Each printer
defines one or more page sizes, either black and white or color, represented in printer
memory by a frame buffer of the appropriate size, which can be thought of as a
two-dimensional Euclidean coordinate system, with the default origin (0, 0) at the
lower left corner, with positive y going up. This is in contrast to standard computer
monitor coordinates which define the origin as the upper left corner, with positive y
going down.
The default coordinates are measured in “points” (1/72nd of an inch), which
approximate the “point” measure used by typographers.
The standard two-dimensional transformations: translate, scale, and rotate are
directly supported by primitive operators and the graphics state globals, specifically
the transformation matrix operators. Using these operators alters the coordinate
system from the default cumulatively.
The two ways to define graphics are through path definition and use of the
“image” family of operators. The heart of PostScript is really the path graphics, so
that is what will be focused on here. “image” and the other related operators are used
to print sampled graphics (such as scanned photographs); a comprehensive
explanation can be found in the red book (see resource list below).
The first step toward learning to program in PostScript is to get an interpreter,
either a printer or an emulator (see resource list), a copy of the PostScript Language
Reference Manual (the red book), and, optionally, one of the indicated tutorial texts. A
careful reading of the red book is essential to anyone who really wants to understand
this language. Further, since nothing beats practical experience, it helps to type in
and run tutorial examples until you understand what’s going on enough to experiment
on your own.
The following examples should give you an idea of what programming in the
language is like. Since I’m not a big fan of hand-holding programming tutorials, the
presentation here is offered more to give an idea of the flavor of the language than to
develop competent skills; if you really want to learn the language, start with this stuff
then go to work on some of the books, particularly the tutorials. The execution model
basically consists of a stack and a stream of objects. Objects are placed on the stack for
operators to act upon. Procedure creation and dictionary binding allow the
programmer to dynamically save and access sequences of operations as well as
variables. For a complete explanation of each operator, refer to the descriptions in the
red book.
The first section moves the origin from the corner of the page, draws a 36 pt
(1/2 inch) increment grid and places explanatory text. The totality of the listings are
meant to be sent to the print environment and will result in six pages of incrementally
defined graphics. The intent is for the reader to type it in, print it out and then
examine the pages with the code.
%%
%preliminary operation for clarity of listed examples
%offset origin from edge of page
%draw grid to illustrate coordinate system
%%percent sign marks comments for PostScript -
%%to the end of the text line
52 72 translate %offset origin by (3/4”, 1”)
/Courier findfont 12 scalefont setfont
0 -27 moveto
(coordinate grid in increments of 36 pts \(1/2”\)) show
0 792 moveto
0 0 lineto
612 0 lineto
stroke
gsave
[3 6] 3 setdash
720 -36 36
{
dup 0 exch moveto
594 exch lineto stroke
} for
576 -36 36
{
dup 738 moveto
0 lineto stroke
} for
grestore
%listing 1 - simple line drawing
%current path is empty
%sets currentpoint to x = 100 pts, y = 200 pts
100 200 moveto
%adds line between (100, 200) and (200, 300) to current path
200 300 lineto
%draws and clears the current path on the raster buffer
stroke
copypage %print current page%%
%listing 2 - simple curve drawing
%%
100 200 moveto %
%adds bezier segment via control points
150 200 150 300 100 300 curveto
stroke %
copypage %
%%
%listing 3 - simple procedures - circle, box
%%
/inch %called as: number inch
{72 mul}
bind def
/circle %called as: xcenter ycenter radius circle
{0 360 arc closepath}
bind def
/box %called as: leftx bottomy xdimension ydimension box
{
/yval exch def %note use of variables
/xval exch def
moveto
0 yval rlineto
xval 0 rlineto
0 yval neg rlineto
closepath
}
bind def
100 100 2 inch circle
stroke
100 100 2 inch 2 inch box
stroke
gsave
.75 setgray
300 200 1.5 inch circle
fill
grestore
copypage
%%
%Listing 4 - simple text
%%
/Helvetica findfont 50 scalefont setfont
40 600 moveto %set current point
(this is a string of text ) show
copypage
%%
%Listing 5 - fountain screen - “for” control structure
%%
/graylevel 0 def % variable
gsave
300 1 400
{
graylevel setgray
400 moveto
0 100 rlineto
stroke
/graylevel graylevel .01 add def
} for
grestore
copypage
%%
%Listing 6 - spiral path - “for” control structure
%%
/polar %takes: radius angle (from origin) and returns x y
{
%note stack manipulation instead of variables
2 copy cos mul 3 1 roll
sin mul
} bind def
/inch {72 mul} bind def
/angle 0 def %variable
gsave %save graphics state variables
4.25 inch 5.5 inch translate
0 0 moveto
0 .5 500 %three numbers: start increment finish
{
angle polar lineto
/angle angle 1 add def
} for %for operator takes three numbers and procedure body
stroke
grestore %restore graphics state variables
showpage
%%
%%
PostScript Environments (on the Mac)
The most obvious examples of PostScript in Macintosh computing are the
printers, the Laserwriter family as well as their legitimate and illegitimate third
party progeny. If the hardware specs indicate “Adobe PostScript” then the machine
includes an implementation of the actual Adobe software. If, on the other hand, the
specs or the advertising say “PostScript compatible” or some such thing, it is a clone
implementation programmed by somebody else. For the purposes of general consumer
computing, this distinction probably doesn’t matter too much yet, since PostScript
code is usually machine generated and therefore designed to run in as plain vanilla an
environment as possible. If, however, the intention is to use the machine for
development, the distinction between “True Adobe PostScript” and “Not” becomes
important. Since the language definition is designed and maintained by Adobe, low level
hacking requires access to an environment as close to that described in the official
documentation as possible. Besides, true Adobe printers aren’t that expensive
anymore, unless you’re interested in color.
The other major type of provider for PostScript processing on the Mac is
software emulation; every example of this category is a clone. These suffer from all
the problems of non-Adobe-hood, they’re slow as the day is long (e specially without a
coprocessor) and they deny the user direct application printing. The standard input
and output streams are also arbitrarily handled, such that error reporting and access
to the standard “print” operator are either disabled or work in a funny way (a
programmer’s gripe to be sure; in all fairness, I recognise that these products are
designed to be used with application generated, and therefore carefully tested and not
particularly error-prone, PostScript code).
On the plus side, however, the software clones offer easy access to the file
operators (which almost makes up for the non-standard streams), screen preview and
cheap color PostScript processing. File operators are important for modular system
building and advanced troubleshooting techniques; With a hardware interpreter,
equivalent manipulation of the file ops require either printer based hard drive
capability (usually an external) or a bit of finagling with the host/printer software
interface (either terminal/serial hookup or Lasertalk over Appletalk). The screen
preview feature saves on paper when you’re designing a custom graphic. Color
printers, even with clone interpreters, generally start somewhere in the
neighborhood of eight grand; T-Script or Freedom of the Press and an HP DeskWriterC
costs around five or six hundred.
PostScript related resources:
Software emulation
Freedom of Press
T-Script
Editors and PS communications software:
Qued/M - good general purpose programmer’s editor
Lasertalk - editor plus direct link to PostScript printer environment
Font Downloader - comes with system software, download fonts/code
Laserstatus - similar to Font Downloader - adds printer feedback
SendPS - similar to Laserstatus
Book list:
PostScript Language Reference Manual, second edition, Adobe Systems Inc.,
Addison-Wesley, 1985. “The Red Book” is the standard reference material for
all implementations up to and including Level 2 and Display PostScript.
PostScript Language Tutorial and CookBook, Adobe Systems Inc., Addison-Wesley,
1985. “The Blue Book” is the official Adobe tutorial.
PostScript Language Program Design, Adobe Systems Inc., Addison-Wesley,
1988. “The Green Book” is an advanced technique manual geared toward the design of
PS printer drivers.
Real World PostScript, ed. Stephen F. Roth, Addison-Wesley, 1988. This is the
most interesting of the lot, consisting of essays and code by various (non-Adobe) PS
professionals; particularly interesting is the essay “PostScript as a Programming
Language”, by Bill Woodruff.
Programming the LaserWriter, David Holzgang, Addison-Wesley, 1991.. Custom
program the Macintosh LaserWriter driver with Think C object system.
Inside PostScript, Frank Braswell, Systems of Merritt & Peachpit Press, 1989.
In depth reference describing QMS-PS 800 true Adobe PostScript environment; Nuts
and bolts.
Encapsulated PostScript - Application Guide for Macintosh and PCs, Peter
Vollenweider, Prentice-Hall UK, 1990. Fairly useful PS/EPS interchange information
regarding specific applications...
Online resources:
Adobe forum on Compuserve (go Adobe) - If you have complex questions, ask
them here.
PostScript roundtable on Genie (psrt) - This is somewhat hobbyist oriented, but
includes an extensive file library of programming examples.
Glossary:
Apple Computer - if you don’t know what this is you shouldn’t be reading this
magazine
Adobe, Inc. - Company that created and markets the PostScript language and related
software products
Epson - printer manufacturer
HP - Hewlett Packard - printer manufacturer
Quickdraw - medium level software graphics system for Macintosh system software
HPGL - low level printer control language for Hewlett Packard and compatible
printers
680x0 CPU - Motorola chip family that includes all Macintosh CPU’s
postfix notation - operands precede operator: “5 10 mul” results in “50”
raster graphic - a computer graphic represented by a series of pixel values; a bit
map or pix map
raster buffer - area of memory established for immediate storage of raster graphic
rasterization - the process of setting pixels in a raster buffer according to the
operative graphics system.
current path - sequence of graphical objects that can be rendered via stroke or fill
stack - last in, first out data structure
operand stack - primary stack of PostScript environment, upon which operators
recieve and return data
dictionary - collection of key/value pairs
dictionary stack - dictionary objects are activated by placing them on this stack
array - random access data structure
procedure body - array of objects with executable attribute corresponding to stream
of code
font - dictionary of procedures specifically oriented toward the setting of text
type 1 font - font using efficient low level details of Adobe PS environment
type 3 font - font built around standard PostScript model
truetype font - font designed for use in Mac and Windows environments for both
screen and printer
PostScript operator names:
findfont - returns named font according to low level PS system specifics
scalefont - takes font, number and returns face at appropriate size
setfont - defines face as currentfont
mul - takes two numbers, returns product
sin - takes angle, returns sine
cos - takes angle, returns cosine
roll - manipulates objects on stack (see red book for more detail)
for - takes three numbers, start, increment and finish and procedure then executes
procedure given each value in the process.
rand - random number generation operator
neg - takes number, multiplies it by negative one, returns value
currentpoint - returns x, y of current point (end of current path) if there is one
moveto - takes x, y, sets value as current point
lineto - takes x, y, appends, to current path, line segment from current point to x,y,
then sets current point to x, y
rlineto - similar to lineto, but uses x, y as relative offset to current point
curveto - takes x1, y1, x2, y2, x3, y3 (3 points) and appends, to current path, a
bezier curve segment according to values ( currentpoint plus given points) and
finally sets the current point to x3, y3
arc - takes x, y (center), radius, start angle, finish angle and appends arc to
current path (drawing a line segment from current point, if necessary)
stroke - strokes and destroys current path with current gray and line thickness
fill - fills and destroys current path with current gray
gsave - save copy of graphics state variables (including current path)
grestore - restore copy of graphics state variables - note that gsave/grestore can be
nested
translate - takes x, y, changes coordinate system origin (0, 0) to x, y
copypage - print page of current raster buffer, leaving buffer
showpage - print page of current raster buffer, clearing buffer
def - take name and object, store as key/value in current dictionary
array - take integer, return array of appropriate length
bind - take procedure body, recursively replace names with pointers to machine
code (medium level optimizer - don’t worry about it)