Introduction
Most people in the printing industry think of PostScript as a graphics format,
application output, a page description language, a type of font, or the internal language of RIPs
and digital printers. All of that is true. The reason it's true is because PostScript is fundamentally
a powerful programming language.
This aspect of PostScript is largely ignored, for a variety of reasons.
Not many programmers spend time in the prepress shop. Besides, Adobe was more concerned about using PostScript
to create the Desktop Publishing industry, than in marketing PostScript to the IT community.
The Variable Data Printing (VDP) market is maturing. With this maturity we see a host of new
standards, devices, and applications. We also find considerable confusion about which set of these tools to use.
In this article, I'll show you how using PostScript as a programming language can address the challenges of VDP.
Hello World
Likely the only PostScript you've seen is output by QuarkXpress or Adobe Illustrator.
It's daunting to understand, to say the least. But VDP programming is a different challenge than writing code to
support all the features of a full-blown application. PostScript code doesn't need to be nearly so complex!
Let's look at a simple PostScript program. In the time-honored tradition, we'll write a
program that produces a single page with the text "Hello world". You can write PostScript code in any text editor,
and then use a tool such as Acrobat Distiller or GhostScript, an open-source (free) program, to process the file.
Example 1. "Hello world" PostScript program
%!PS
/Times-Roman 24 selectfont
10 600 moveto
(Hello world) show
showpage
Simple, isn't it? You can tell just by looking at this code what it's going to do:
print the text "Hello world" in 24-point Times-Roman at a certain position on the page.
(The "%!PS" at the top tells the RIP this is a PostScript program.)
When you consider that the text "Hello world" could be read from a data file, stored in a variable,
and drawn (or not) based on a condition, you can see that PostScript is ideal for VDP programming.
PostScript Coordinates
PostScript uses a Cartesian (x,y) coordinate system. The origin, or 0,0 coordinate,
is at the bottom left corner of the page. X increases to the right, and Y increases up the page.
The default units are "points". There are 72 points to the inch. So the instruction 10 600 moveto means,
"move to a spot 10 points to the right, and 600 points up".
A Deeper Look at PostScript
What features of PostScript make it particularly well suited to VDP?
PostScript is designed to be a Page Description language, meaning it can draw images and text.
There are three features that deserve special mention:
[1] Text manipulation. Of course PostScript can put text on the page.
PostScript can also search, convert, combine, read, write, save, and perform decisions upon, text strings.
[2] Conditionals. As with other programming languages, PostScript can make decisions
based on conditions: IF this is true, then do this; ELSE, do that. PostScript has several different
mechanisms for conditional processing.
[3] Caching. If you follow current trends, you've heard a lot about caching
and reusable content. Caching has been part of PostScript since 1991! Caching is the ability to interpret a set of
drawing instructions once, and "cache" the result for use later in the job.
A good example is a logo. A PostScript program can define or include the logo once, in such a way that the
interpreter will RIP the logo one time and cache it for repeated use throughout the job.
Think about it! If someone told you there was a programming language that
• needed no license or special software to use,
• supported PostScript fonts,
• supported CMYK colors, Pantone Colors, color separations, etc.,
• could read data from a file (raw data, text files, XML),
• supported caching of reusable content, and
• was already fully supported by your current output devices,
you'd probably think "It's about time!" It's been there all along with PostScript.
Workflow
So how do you use it? In a typical VDP workflow, data is mapped onto a template,
data records are selected and merged with the template, and PostScript is output as the final result.
Someone on the "graphics side" of the house uses a layout or illustration
program to create the templates and save them as EPS files (see "EPS files").
Meanwhile, someone on the "IT side" selects data and exports it into the format
required by your VDP application.
Once you have the data and the template, someone maps the data onto the template
using a sophisticated and expensive VDP software application. The application merges the data onto the
templates and outputs a PostScript file to produce the job.
This is an oversimplified description, but serves to illustrate that VDP
requires an interaction between technical people and artistic people,
and that PostScript is used extensively in the process.
Who is the "someone" who runs the VDP application? That's often a difficult question to answer!
In a "PostScript workflow", however, we eliminate the question itself.
The designers design the templates and the variability within the job.
The techs provide the data and the PostScript. The data can be put inside the PostScript program
and sent directly to your output device.
In fact, the PostScript code could be stored in a database right along with the variable data.
The data could be collected through a website, where your users fill out a form or upload a file.
The web program combines the data with the PostScript to produce PDF proofs in real-time - but that's another article!
EPS files
EPS files are PostScript programs that obey certain rules. An EPS draws a single image,
which can include text and graphics. Specially formatted comments in the EPS tell layout
programs if the EPS contains fonts, uses special colors, and so on. EPS files may contain a small TIFF or PICT
thumbnail image for a layout application to use. EPS files may be scaled, positioned, skewed, rotated, and reused
within a PostScript program. Be careful, since not all applications obey the rules when they create EPS files!
A future article will detail how to prepare and use EPS files in your PostScript programs.
Variable Data PostScript Program
Let's write a simple variable data PostScript program. We won't have any background
images or color in this sample, though EPS files can be included in PostScript programs (see "EPS files").
The program prints a name and address on the page; one page per data record.
You're not expected to understand everything in this program; it's an example of how efficient and
straightforward PostScript can be for VDP.
Example 2. Typical Variable Data PostScript program
%!PS
<< /PageSize [360 216] >> setpagedevice
/x 36 def
/yPos 180 def
/ptSize 12 def
/txtFont /Times-Roman findfont ptSize scalefont def
/leading ptSize 1.2 mul def
/y {yPos leading sub dup /yPos exch def} bind def
/drawAddress
{ txtFont setfont
{ dup length 0 gt
{ x y moveto show } { pop } ifelse
} forall
} bind def
/doJob
{ count
{ drawAddress showpage
/yPos 180 def
} repeat
} bind def
% Begin Variable Data
[(Thomas D. Greer) (706 N. Main St.) (Suite 100) (Newton, KS 67114)]
[(John Doe) (123 Anystreet) () (Anytown, USA)]
% End Variable Data
doJob
This is a typical VDP PostScript program. The top section sets up page size, margins,
leading, font, point size, and defines instructions for how to draw the data on the page.
These instructions are robust enough to deal with missing or empty data, such as our blank second address in
the "John Doe" record. The code implements the rules set by the designers.
The bottom portion of the program contains the data, in any format the programmer desires.
Here I've put the data inside PostScript arrays. An array is a way of putting a set of data into a single container.
Arrays start with "[" and end with "]".
Experiment with this! Add as many arrays as you like to the program, following the format shown.
The last instruction, "doJob", runs the program.
Conclusion
PostScript is a robust, full-featured programming language, perfect for VDP programming.
In the aggressive, data-driven print market, you need every advantage.
PostScript can be a powerful tool in your VDP arsenal.
About the Author
Thomas D. Greer has years of experience in the printing business.
He held the position of Director of Development for Consolidated Graphics, where he wrote the COIN eCommerce platform.
Prior to that he was Vice-President of Technology of a large printing company acquired by Consolidated Graphics,
where he was responsible for the development of a completely custom-written plant management system still in use.
Today Thomas provides consulting, development, implementation, and training services to commercial printers.
He can be reached on the web at www.tgreer.com.
