shr@maxwell.ece.cmu.edu (Scott H. Robinson) (11/27/89)
I agree, generation of bad PostScript seems to be reaching epidemic
proportions )-: My experience is primarily based on the insertion of
PostScript figures in TeX/LaTeX documents. In fact, I wrote a suite of scripts
to aid in the figure insertion -- the design of which was completely driven by
the need to repair such atrocities.
A cheap test:
Can the figure be included and printed in a TeX/LaTeX document with
relative positioning on the page? Are translation, rotation, and
scaling of the figure possible? Even better, can figures be included
recursively in themselves? (Visual inspection is invariably what
happens as well.)
Below, I've listed the problems I've seen and had to hack around. Maybe
they'll be useful to the future author of pslint(1) or anyone thinking about
buying new PS-generating software.
Failures seem to occur during all phases:
-figure insertion (e.g. bad %%BoundingBox.)
-queuing and printer initialization.
-PostScript interpretation/execution (printing).
The most frequent failure (to insert) mechanisms I've seen are:
1) Missing/malformed structuring conventions.
(e.g. '%%BoundingBox: ? ? ? ?' or no %%BoundingBox.)
2) Transformation matrix/stack blasting.
(e.g. initmatrix, initgraphics, setmatrix, clear)
Other Problems:
- Use of unprotected printer-specific instructions
(e.g. use of Apple-Printer-specific instructions.)
-Quite often document generation systems seem to make the assumption that
their PS output will NOT be included in other documents. Wrong! Sometimes it
is necessary to do this to overcome various memory limitations or formatting
restrictions (e.g. you might want a super-wide table to be shown in landscape
mode in a portrait-mode document.) This bad assumption probably leads to all
of the problems listed here.
-Many preamble definitions are made outside of a dictionary (i.e. no
dictionary in the preamble.) Hence, when numerous definitions are made, you
get a ``dictfull'' error when including the figure in another document and
then executing the resulting PostScript.
-Multiple versions of a dictionary that are not downward compatible. (e.g.
Apple's LaserPrep5.[0,2] files: 'md' dictionary.) This can be a problem if you
have many figures generated with different versions of the dictionary. (The
time & space intensive solution is to load the dictionary each time you need
it - gag. Stream editing the dictionary name to a version-specific name and
loading them just once at the top is best...)
-Other potential problems? Structuring convention inheritance: when you
include a figure in a document, should the set of fonts used by the figure and
similar static structuring information be propagated to the document's
%%DocumentFonts, %%PageFonts, etc?
Similarly, when including a figure, the assembling program should
disable/assimilate other structuring comments in the figure that might mess up
smart queuing software. I've encountered this in some configurations of the
CAPS (Columbia AppleTalk Printing Software). For example, when CAPS sees an
end-of-document marker, it terminates the file transmission. When printing,
this leads to truncated documents if it finds an end-of-document marker at the
end of any figure included in the document before the true end of the
document.
After writing most of this message, I just looked in Nelson Beebe's "TeX DVI
Driver Family Status", (second ed. 1, July 1989). He lists the following
"deprecated PostScript operators" (Table 7) for files that are to be included
as figures:
banddevice, copypage, erasepage, exitserver, framedevice,
grestoreall, initclip, initgraphics, initmatrix, note, nulldevice,
quit, renderbands, setdevice, setmatrix, setpageparams, setsccbatch,
setscreen, settransfer.
I haven't seen the EPSF format specs, but these are probably listed there...
He also talks about some of the problems I've listed above too.
Scott H. Robinson ECE Department
(412) 268-6639 Carnegie Mellon University
ARPANET: shr@husky.ece.cmu.edu Pittsburgh, PA. 15213 U.S.A.
UUCP: {...decvax}!vax135!ucbvax!shr@husky.ece.cmu.edu