Next: Page Device Options, Up: PostScript [Contents][Index]
To read this section, the reader must understand what DSC are (see 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 beginning 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 criticized 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.
Next: Page Device Options, Up: PostScript [Contents][Index]