Go to the first, previous, next, last section, table of contents.

8 PostScript

This chapter is devoted to the information which is only relevant to PostScript.

8.1 Foreword: Good and Bad PostScript

To read this section, the reader must understand what DSC are (see section A Glossary).

Why are there good PostScript files, easy to post-process, and bad files that none of my tools seem to understand? They print fine though!

Once you understood that PostScript is not a page description format (like PDF is), you'll have understood most of the problem. Let's imagine for a second that you are a word processor.

The user asks you to print his/her 100 page document in PostScript. Up to page 50, there are few different fonts used. Then, on pages 51 to 80, there are now many different heavy fonts.

When/where will you download the fonts?

The most typical choice, sometimes called Optimize for Speed, is, once you arrived to page 51, to download those fonts once for the rest of the document. The global processing chain will have worked quite quickly: little effort from the software, same from the printer; better yet: you can start sending the file to the printer even before it is finished! The problem is that this is not DSC conformant, and it is easy to understand why: if somebody wants to print only the page 60, then s/he will lack the three fonts which were defined in page 51... This document is not page independent.

Another choice is to download the three fonts in each page ranging from 51 to 80, that is the PostScript file contains 30 times the definition of each font. It is easy for the application to do that, but the file is getting real big, and the printer will have to interpret 30 times the same definitions of fonts. But it is DSC conformant! And you can still send the file while you make it.

Now you understand why

Non DSC conformant files are not necessarily badly designed files from broken applications.

They are files meant to be sent directly to the printer (they are still perfect PostScript files after all!), they are not meant to be post-processed. And the example clearly shows why they are right.

There is a third possibility, sometimes called Optimize for Portability: downloading the three fonts in the prologue of the document, i.e., the section before the first page where are given all the common definitions of the whole file. This is a bit more complicated to implement (the prologue, which is issued first though, grows at the same time as you process the file), and cannot be sent concurrently with the processing (you have to process the whole file to design the prologue). This file is small (the fonts are downloaded once only), and DSC conformant. Well, there are problems, of course... You need to wait before sending the output, it can be costly for the computer (which cannot transfer as it produces), and for the printer (you've burnt quite a lot of RAM right since the begining just to hold fonts that won't be used before page 51... This can be a real problem for small printers).

This is what a2ps does.

If should be clear that documents optimized for speed should never escape the way between the computer and the printer: no post-processing is possible.

What you should remember is that some applications offer the possibility to tune the PostScript output, and they can be praised for that. Unfortunately, when these very same applications don't automatically switch to "Optimize for Portability" when you save the PostScript file, and they can be critized for that.

So please, think of the people after you: if you create a PostScript file meant to be exchanged, read, printed, etc; by other people: give sane DSC conformant, optimized for portability files.

8.2 Page Device Options

Page device is a PostScript level 2 feature that offers an uniform interface to control printer's output device. a2ps protects all page device options inside an if block so they have no effect in level 1 interpreters. Although all level 2 interpreters support page device, they do not have to support all page device options. For example some printers can print in duplex mode and some can not. Refer to the documentation of your printer for supported options.

Here are some usable page device options which can be selected with the `-S' option (`--setpagedevice'). For a complete listing, see PostScript Language Reference Manual: section 4.11 Device Setup.

Collate boolean
how output is organized when printing multiple copies
Duplex boolean
duplex (two side) printing
ManualFeed boolean
manual feed paper tray
OutputFaceUp boolean
print output `face up' or `face down'
Tumble boolean
how opposite sides are positioned in duplex printing

8.3 Statusdict Options

The statusdict is a special storage entity in PostScript (called a dictionary), in which some variables and operators determine the behavior of the printer. This is an historic horror that existed before page device definitions were defined. They are even more printer dependent, and are provided only for the people who don't have a level printer. In any case, refer to the documentation of your printer for supported options.

Here are some statusdict definitions in which you might be interested:

manualfeed boolean
Variable which determine that the manual fed paper tray will be used. Use is `--statusdict=manualfeed::true'.
setmanualfeed boolean
Idem as the previous point, but use is `--statusdict=setmanualfeed:true'.
setduplexmode boolean
If boolean, then print Duplex. Use if `--statusdict=setduplexmode:true'.

8.4 Colors in PostScript

Nevertheless, here are some tips on how to design your PostScript styles. It is strongly recommended to use `gray.pro' or `color.pro' as a template.

There are two PostScript instructions you might want to use in your new PostScript prologue:

this instruction must be preceded by a number between 0 (black) and 1 (white). It defines the gray level used.
this instruction must be preceded by three numbers between 0 (0 %) and 1 (100%). Those three numbers are related to red, green and blue proportions used to designate a color.

a2ps uses two upper level procedures, BG and FG, but both use an argument as in setrgbcolor. So if you wanted a gray shade, just give three times the same ratio.

8.5 a2ps PostScript Files

a2ps uses several types of PostScript files. Some are standards, such as font files, and others are meant for a2ps only.

All a2ps files have two parts, one being the comments, and the other being the content, separated by the following line:

% code follows this line

8.6 Designing PostScript Prologues

It is pretty known that satisfying the various human tastes is an NEXPTIME-hard problem, so a2ps offers ways to customize its output through the prologue files. But since the authors feel a little small against NEXPTIME, they agreed on the fact that you are the one who will design the look you like.

Hence in this section, you will find what you need to know to be able to customize a2ps output.

Basically, a2ps uses faces which are associated to their "meaning" in the text. a2ps let's you change the way the faces look.

8.6.1 Definition of the faces

There are three things that define a face:

Its font
You should never call the font by yourself, because sometimes a2ps may decide that another font would be better. This is what happens for instance if a font does not support the encoding you use. Hence, never set the font by yourself, but ask a2ps to do it. This is done through a line:
%Face: face real-font-name size
This line tells a2ps that the font of face is real-font-name. It will replace this line by the correct PostScript line to call the needed font, and will do everything needed to set up the font. The size of the text body is bfs.
Its background color
There are two cases:
  1. You want a background color, then give the RGB (see section 8.4 Colors in PostScript) ratio and true to BG:
    0.8 0.8 0 true BG
  2. You don't want a background color, then call BG with false:
    false BG
Its foreground color
As BG, call FG with an RGB ratio:
0 0.5 0 FG
Its underlining
UL requires a boolean argument, depending whether you want or not the current face to be underlined.
true UL
Its boxing
Requiring a boolean, BX let's a face have a box drawn around.

8.6.2 Prologue File Format

Prologue files for a2ps must have `pro' as suffix. Documentation (reported with `--list-prologues') can be included in the comment part:

This prologue is the same as the prologue code(pb)code, but using
the bold version of the fonts.
% code follows this line

See section 5.1 Documentation Format, for more on the format.

8.6.3 A step by step example

We strongly suggest our readers not to start from scratch, but to copy one of the available styles (see the result of `a2ps --list=prologues'), to drop it in one of a2ps directories (say `$HOME/.a2ps', and to patch it until you like it.

Here, we will start from `color.pro', trying to give it a funky look.

Say you want the keywords to be in Helvetica, drawn in a flashy pink on a light green. And strong keywords, in Times Bold Italic in brown on a soft Hawaiian sea green (you are definitely a fine art amateur).

Then you need to look for `k' and `K':

/k {
  false BG
  0 0 0.9 FG
%Face: Keyword Courier bfs
} bind def

/K {
  false BG
  0 0 0.8 FG
%Face: Keyword_strong Courier-Bold bfs
} bind def

and turn it into:

/k {
  0.2 1 0.2 true BG
  1 0.2 1 FG
%Face: Keyword Helvetica bfs
} bind def

/K {
  0.4 0.2 0 true BG
  0.5 1 1 FG
%Face: Keyword_strong Times-BoldItalic bfs
} bind def

Waouh! It looks great!

A bit trickier: let change the way the line numbers are printed.

First, let's look for the font definition:

% The font for line numbering
/f# /Helvetica findfont bfs .6 mul scalefont def

Let it be in Times, twice bigger than the body font.

% The font for line numbering
/f# /Times-Roman findfont bfs 2 mul scalefont def

How about its foreground color?

% Function print line number (<string> # -)
/# {
    sx cw mul 2 div neg 0 rmoveto
    f# setfont
    0.8 0.1 0.1 FG
} bind def

Let it be blue. Now you know the process: just put `0 0 1' as FG arguments.

Go to the first, previous, next, last section, table of contents.