Go to the first, previous, next, last section, table of contents.
This chapter is devoted to the information which is only relevant to 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.
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
Duplex boolean
ManualFeed boolean
OutputFaceUp boolean
Tumble boolean
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
setmanualfeed boolean
setduplexmode boolean
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:
setgray
setrgbcolor
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.
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
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.
There are three things that define a face:
%Face: face real-font-name sizeThis 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.
true to BG:
0.8 0.8 0 true BG
BG with
false:
false BG
BG, call FG with an RGB ratio:
0 0.5 0 FG
UL requires a boolean argument, depending whether you want
or not the current face to be underlined.
true UL
BX let's a face have a box drawn around.
Prologue files for a2ps must have `pro' as suffix. Documentation (reported with `--list-prologues') can be included in the comment part:
Documentation This prologue is the same as the prologue code(pb)code, but using the bold version of the fonts. EndDocumentation % code follows this line
See section 5.1 Documentation Format, for more on the format.
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
Show
} bind def
/K {
false BG
0 0 0.8 FG
%Face: Keyword_strong Courier-Bold bfs
Show
} bind def
and turn it into:
/k {
0.2 1 0.2 true BG
1 0.2 1 FG
%Face: Keyword Helvetica bfs
Show
} bind def
/K {
0.4 0.2 0 true BG
0.5 1 1 FG
%Face: Keyword_strong Times-BoldItalic bfs
Show
} 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:
%%BeginSetup % The font for line numbering /f# /Helvetica findfont bfs .6 mul scalefont def %%EndSetup
Let it be in Times, twice bigger than the body font.
%%BeginSetup % The font for line numbering /f# /Times-Roman findfont bfs 2 mul scalefont def %%EndSetup
How about its foreground color?
% Function print line number (<string> # -)
/# {
gsave
sx cw mul 2 div neg 0 rmoveto
f# setfont
0.8 0.1 0.1 FG
c-show
grestore
} 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.