Introduction
The first article in this series, Use of PostScript in
Variable Data Printing, introduced the PostScript language, explained why it was ideal for VDP, and concluded
with a sample PostScript VDP program.
Most of the time, you will want to use logos, background images, and other graphical elements
in your VDP programs. This means working with EPS files. This article explains the EPS format
and provides helpful advice for using EPS files within VDP programs.
EPS File Format
The official EPS reference is located in Adobe Technical Note #5002,
"Encapsulated PostScript File Format Specification".
An EPS is a PostScript language file meant to be used as an illustration;
a graphic component of a larger page. Thus an EPS is "encapsulated" within a larger program. EPS files are
supposed to obey a set of rules which make it possible for a page layout program to determine the size,
colors, fonts, and other characteristics, of the EPS.
Specifically, EPS files use Document Structuring Conventions (DSC, Adobe Tech Note #5001) to
describe these features. These are a set of preformatted comments beginning with two percent signs, for example:
%%Creator: Thomas D. Greer
There are certain operators that are discouraged or not allowed inside EPS files.
Anything that could have an adverse affect on the rest of your document doesn't belong in an EPS.
However, many applications that produce EPS files don't follow these rules!
This includes some very popular illustration and layout programs.
Thumbnail Images
EPS files can contain thumbnail images. This is so you have something to see when you place an
EPS file in a layout program. On a Windows platform, the thumbnail is usually a TIFF; on a Mac it is a PICT.
Remove these if you're using the EPS in a VDP program. They add unnecessary bulk, and may in fact
cause your program to crash (they are meant to be consumed by an application, not a RIP). While it is possible to
remove them manually, it is safer to do this through an application. Open and re-save the EPS with the
"no thumbnail" or "no header" option selected.
Some programs include thumbnails by using binary data at the beginning and end of the EPS program.
This will break your PostScript program if you try to include the EPS. To manually remove these,
you can open the EPS in a text editor, select this binary data, and delete it. Everything prior to
the opening "%!PS-Adobe" comment, and after the final "%%EOF" comment should be discarded.
EPS in PostScript
You may include the EPS file by literally copying the entire code from the EPS into your program.
This is the only option if you're sending the PostScript directly to a RIP or output device.
If you're using PostScript code to produce a PDF, a better option is to use the PostScript "run" operator,
which takes a filename as an argument. Your code will be much easier to maintain if you can pass in a
pathname versus an entire EPS file.
Example 1. The PostScript "run" operator
(c:/vdp/samples/tg_logo.eps) run
Since PostScript is device-independent, the interpreter won't know what operating
system or file structure you have. Use forward slashes instead of backslashes,
this works on Unix, Windows, and Macintosh systems.
Unless you hand-write your EPS files, you have little control over the code inside.
EPS files may alter the current font, color, or coordinate system. They may contain procedures with the
same name as your procedures. The first principle to grasp when using EPS files then, is you must protect
the rest of your program from them. They truly must be "encapsulated", or sealed off from, the containing program.
Whether you use "run" or put the EPS itself in your program, you must perform some basic housekeeping
before and after the EPS file.
The first step is to save the current working state of your program.
This includes all of your definitions, and your current graphics settings, such as font, color, and position.
PostScript makes this very easy and fast, with the "save" operator. The complementary operator is "restore",
which as you might expect, restores the last save.
Example 2. Using "save" and "restore"
save
(c:/vdp/samples/tg_logo.eps) run
restore
Bracketing your EPS file with a save/restore pair protects your program
from any changes the EPS might make. That isn't quite enough, though. Recall there are operators an
EPS file should not use. Many programs do anyway. For example, the operator "showpage" outputs a page,
and sets things up for a fresh new page. It's amazing how many programs put a showpage in their EPS files.
Unless you fix the problem, your page will output as soon as you reach the end of the EPS.
Anything you do after the EPS will end up on a new, separate page.
Ideally, you want showpage to work normally within your program, except when you're running an EPS.
Then, you don't want it to do anything at all.
Another common culprit is the "setpagedevice" operator. This operator expects something
called a "parameter dictionary" as a parameter. "setpagedevice" is used to control page level settings.
Obviously, a graphic file shouldn't be making changes at the page level. Still, many EPS files break the rules
and include calls to setpagedevice.
You want setpagedevice to work normally, except when you're running an EPS,
in which case you want it to discard the parameter dictionary and move on.
Example 3. fixing "showpage" and "setpagedevice"
save
/showpage {} def
/setpagedevice /pop load def
(c:/vdp/samples/tg_logo.eps) run
restore
Let's walk through this a line at a time:
1. save
Saves all your current definitions and graphics state.
2. /showpage {} def
Defines showpage as an empty, do-nothing procedure. If your EPS performs a showpage, nothing will happen.
3. /setpagedevice /pop load def
Sets setpagedevice equal to the "pop" operator. "Pop" takes whatever parameter
is current and throws it away. So if your EPS uses setpagedevice, the parameter dictionary containing
the page-level settings is discarded and the program moves on to the next instruction.
4.(c:/vdp/samples/tg_logo.eps) run
Draws the EPS on the page
5. restore
Restores our original settings. This will restore showpage and setpagedevice to their original function.
Image Placement and Bounding Box
One of the most important DSC comments in an EPS file is the %%BoundingBox comment.
This comment is followed by a series of 4 numbers representing a rectangle into which the EPS image fits.
The numbers are in PostScript points (there are 72 points per inch).
The first number is the lower left X coordinate, the second is the lower left Y coordinate, followed
by the X Y values for the upper right of the rectangle.
Ideally, the first two numbers should be 0, 0. Thus a one inch square EPS file should have the comment:
%%BoundingBox: 0 0 72 72
Sadly, most illustration programs center the image on the current working art board,
which is usually a letter-sized page. When the artist exports the image as an EPS, the lower left corner
is offset by an arbitrary amount, based on where the image was on the screen. This presents a problem for
a PostScript programmer trying to precisely position the picture on the page (say that three times fast!).
You can fix this with an illustration application. Select the entire image and move the image
until the lower left corner of the image coincides with the lower left corner of the "page" or "art board".
Manually altering the BoundingBox comment won't work, it's just an informational comment after all,
not actual programming code.
Alternatively, you can adjust the placement of the EPS with the "translate" operator.
Imagine a set of crosshairs, centered on the lower left corner of your page. You have an x-axis running
along the bottom, and a y-axis along the left side. Translate moves the crosshairs. The trick to positioning an
EPS image is to move the crosshairs so that "0,0" is at the lower-left corner of where you want the EPS to be,
then draw the EPS.
Let's say you have a one inch square EPS. You want to position this at the top right of
your page, with an 18-point margin. A letter-size page is 612 points wide by 792 points tall.
To calculate the lower left corner of the EPS image position, subtract its width
(72 points) plus your margin (18 points) from 612. 612 - (72 + 18) = 522. Do the same thing for the height;
subtract your height plus your margin, 90, from the top, 792, leaving 702.
So you must "translate" to 522, 702, then draw your image:
Example 4. positioning an EPS with "translate"
save
/showpage {} def
/setpagedevice /pop load def
522 702 translate
(c:/vdp/samples/tg_logo.eps) run
restore
This is simple if the EPS is well-made, with a bounding box set to "0 0 ...".
If you have an EPS with an arbitrary bounding box, you can compensate with a second translate.
Imagine our one inch square EPS has the following bounding box:
%%BoundingBox: 270 360 342 432
This isn't uncommon, as this would draw the image in the center of a letter-sized page.
To compensate for this, you can do a second translate.
Example 5. compensating with "translate"
save
/showpage {} def
/setpagedevice /pop load def
522 702 translate % position we want the EPS
-270 -360 translate % compensate for improper bbox
(c:/vdp/samples/tg_logo.eps) run
restore
Scaling
Occasionally a single EPS file is meant to be used at varying sizes.
For example, you may be provided with a single high-quality EPS logo file. The logo is to be used on
letterhead and a business card, even though the business card uses a smaller logo. You can scale your
file within an illustration program, or you can use PostScript code to do this for you.
To scale the EPS image, you use the PostScript "scale" operator. It takes two parameters,
a horizontal scale value, and a vertical scale value. The value is a decimal, with "1" being 100%, or no scale.
To make an EPS twice as big, you would do a "2 2 scale".
You should do your scale after your translate(s). Recall that translate moves the "crosshairs".
Scale stretches them. If you stretch them before you move them, you'll have a difficult time knowing how
far to move them, since the coordinates themselves have been stretched. Confused?
Just remember the rule: translate, rotate, scale, or "TRS". Making your coordinate changes in
this order keeps things nice and tidy.
Let's go back to our sample one inch square EPS, only this time we need to scale it down a uniform 75%.
Example 6. scaling an EPS
save
/showpage {} def
/setpagedevice /pop load def
522 702 translate
.75 .75 scale
(c:/vdp/samples/tg_logo.eps) run
restore
Note, I didn't adjust the margins in the last example. If you still want 18 point margins,
recall that the EPS will be 75% smaller. You'll need to account for that when you calculate your translate coordinates!
In effect, there are 25% more points per inch, so you'll subtract 72 times .75, plus your 18 point margin, from the edge.
I know, it's confusing. That's why we let PostScript do the math for us.
Example 7. calculating coordinates
save
/showpage {} def
/setpagedevice /pop load def
612 72 .75 mul 18 add sub
792 72 .75 mul 18 add sub
translate
.75 .75 scale
(c:/vdp/samples/tg_logo.eps) run
restore
The Stack
Example 7 introduced some pretty odd-looking math. PostScript is a stack-based language.
This means you pile all your operands and parameters up first, then use an operator to consume them.
So to add two numbers together, you would place the two numbers on the stack: 2 2. To add them together, use the "add" operator.
"Add" expects two numbers on the stack. If it doesn't find them, you'll get an error. It consumes two numbers,
adds them together, and leaves the result on the stack.
Look again at the code: 612 72 .75 mul 18 add sub. We put three numbers on the stack, 612, 72, .75.
Then we perform the "mul", or multiplication, operator. It multiplies 72 and .75, leaving the result on the stack.
Now our stack has 612 and 54. Next we put 18 on the stack, giving us 612, 54, and 18. "add" adds 54 and 18 together,
giving us a stack with 612 and 72. "sub" subtracts 72 from 612, leaving our final coordinate, 540, on the stack.
It will eventually be consumed by the translate operator.
Conclusion
VDP requires collaboration between designers and programmers. Let the artists do what they do best,
design beautiful graphics. This article explained how to take the resulting EPS files and incorporate them within a
PostScript program.
The next article will continue the discussion of EPS files, as we take a look at Caching
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.
