Related Info: Quickdraw Print Manager

The Postscript Programming Language

A tutorial introduction to PostScript

By Gregor Koomey, Albany, New York

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 (especially 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)