Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!sun-barr!newstop!sun!angel!henry
From: henry%angel@Sun.COM (Henry McGilton -- Software Products)
Newsgroups: comp.lang.postscript
Subject: Bad PostScript
Keywords: PostScript
Message-ID: <128431@sun.Eng.Sun.COM>
Date: 27 Nov 89 22:15:32 GMT
Sender: news@sun.Eng.Sun.COM
Distribution: na
Lines: 108



The several people who have posted notes on `bad'
PostScript certainly have some good points.

Before getting into all the problems I've personally had to
debug, here are a couple of philosophical issues:

    1.  A PostScript program should have ZERO assumptions built
	in as to where it will end up.  That means that the 
	writer should certainly NOT assume the resulting
	PostScript will end up being printed on any kind of
	printing device -- it might just be included as part
	of another PostScript program.

    2.  Most of the `bugs' I've actually debugged were a result
	of the programmer either violating issue (1) from
	above, apparently not reading the PostScript
	Reference Book, or apparently having read the book
	and having failed to implement PostScript according
	to the book.

PostScript against which I've had to build firewalls
included some or all of the following problems:

Control-C characters at the end of the PostScript file, on
the assumption that the PostScript was destined for a
printer in an environment where there is no print manager.
For all you people out in PC/MS-DROSS land, DO NOT put
control-C characters at the end of EPS files.  The Adobe
Red Book is very clear on this topic.  This horse was
flogged beyond death some time ago, and as far as I'm
concerned, Adobe's position that control-C characters are
in the purview of the print manager not the application, is
the correct one.  Now, let's bury the horse once and for all.

Control-Z characters at the end of the PostScript file, on
the assumption that the PostScript was destined for a text
file in PC environment.  Control-Z is an end of file only
in the MS-DROSS and CP/M world.  Other systems (such as
UNIX) do it right.  End of file is a state of mind, not a
special character.  DO NOT put control-Z characters at the
end of EPS files.

EPS 1.2 files containing a binary header, but no preview
image.  Look chaps, if all that's in the file is the
PostScript, why bother with the binary header at all?  The
Adobe spec is not crystal clear on this issue, I admit, but
it never occurred to me that somebody would include the
binary header just so they could indicate that the preview
image didn't exist.

PostScript files consisting of one giant line, as long as
the file, with no reasonable line breaks.  Most editors
(certainly vi) can't deal with huge one-line files, and
I've had to retrain my fingers to use EMACS.  I've seen
plenty of these weirdos.  If you couldn't edit the
PostScript, how in the world did you developers out there
ever debug the PostScript?  From what I've seen, you
probably didn't.

Using the  { < . . . > } sequence to get sampled image data
onto the stack as the procedure argument to the  image
operator.  This only works up to a certain point, and then
breaks, resulting in plenty of debugging time on the part
of the consumer, not the developer.  Use the
readhexstring  operator and do it right next time, please.

Using printer-specific setup procedures like  letter  and
legal  and  a4  and so on.  Even if you really really must
do these things, at least put them inside a save/restore pair.

Wiring the characteristics of specific printers into your
application.  I recently had to shred the innards of a
program that assumed the generated PostScript was destined
for American standard letter size paper on an Apple
LaserWriter model I, complete with 1/4 inch margins around
the edges where the engine won't mark.  Use the Printer
Description Files that Adobe supplies.  Course, if UNIX had
anything like a print manager, a lot of these problems
could be taken away from the applications.

Failing to realise that the  clip  operators add to the
path and don't do an implicit  newpath  the way that
stroke  and  fill  do.

Not using dictionaries when they should.

By far the most frustration has come from the existence of
an old, out of date, obsolete, ossified, interim version of
the EPSF 2.0 specification that somehow escaped from
Adobe when it was only half assed.  By the time the
specification was fully assed, every implementor and their
dog had written EPSI to that specification, resulting in
lots of trouble for those who had waited patiently for the
real 2.0 specification.  All you people out there who have
the EPSF 2.0 specification dated 11th May 1987, would you
do us all a favor: eat the damned thing with a champagne
chaser, then ask the Adobe file server for the latest 2.0
specification dated sometime in 1989, and implement to that
specification.  Would you all do that, please?

	............... Henry
+------------------+------------------------+---------------------------+
| Henry McGilton   | I saw the future,      | arpa: hmcgilton@sun.com   |
| Sun Microsystems | and it didn't work.    | uucp: ...!sun!angel!henry |
| Mt. View, CA     |                        |                           |
+------------------+------------------------+---------------------------+