(a2ps.info)Good and Bad PostScript

---

Next: Page Device Options Up: PostScript

---

Enter node , (file) or (file)node

8.1 Foreword: Good and Bad PostScript
=====================================

To read this section, the reader must understand what DSC are (Note:
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.