Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!Teknowledge.COM!polya!rokicki
From: rokicki@polya.Stanford.EDU (Tomas G. Rokicki)
Newsgroups: comp.lang.postscript
Subject: Re: Bad PostScript
Message-ID: <12890@polya.Stanford.EDU>
Date: 27 Nov 89 23:11:27 GMT
References: <12877@polya.Stanford.EDU> <7093@pt.cs.cmu.edu>
Organization: Computer Science Department, Stanford University
Lines: 71

> >What I propose is that Adobe (or some enlightened soul) attempt to write
> >a `validation' program.  This simple C program would ..
> I don't see how it could possibly be simple.  From what little I understand
> of PostScript, it would have to be nearly the entire interpreter.
> Plus additional code for dealing with document structuring conventions.

Nope, I'm thinking of just an empirical test.  The C program would not even
look at the PostScript, it would just interpret and strip or pass along the
structuring conventions, as appropriate.  (It should check them for validity
to a certain degree as well.)  But it would act as a minimal importation
program---ie, generate some trivial printed output of its own both before
and after the imported graphic, and scale, position, and possibly rotate
the included graphic appropriately.  It could serve as the basis of a
program's EPS importation ability.

> The only problem is when you write some code, and try to run it through
> your compiler or interpreter.  The machine will point out your most
> obvious mistakes.

This doesn't work for the structuring conventions.  Most spoolers only
interpret/handle/check a few of the structured comments, and many
incorrectly handle some of the ones they attempt to interpret.  Heck,
many spoolers probably completely ignore the structuring conventions;
this is why we are in the existing sad state.

Hell, old Adobe interpreters used to allow you to do all sorts of illegal
things---like modifying supposedly read-only font dictionaries.

> Perhaps we, and the developers whose software generate PostScript, rely
> too heavily on the machine to expose our shortcomings and misunderstandings.

Absolutely---empirical programming strikes again.

> I just don't think that Adobe can, or should be, the police force for
> every possible company that generates or pretends to generate PostScript.

No, but Adobe, as the highly-paid standard bearer, has the responsibility
to establish the standards.  This is the basis of my complaints with
Adobe.  PostScript is a great contribution to computing, but it needs care
and attention.  It needs rigidly defined standards and test suites to check
those standards.  It needs carefully designed extensions to meet new needs.
But Adobe sat on its hands for all the years it had the monopoly.  Adobe
has done very little for PostScript since the original LaserWriter
interpreter.  Now that the clones are coming, PostScript is in danger of
splintering, due to almost-compatible interpreters and differing
interpretations of the loosely-worded specifications Adobe has made available.
The elegant, clean, beautiful PostScript language is becoming a rat's nest,
mostly due to the poor structuring conventions.

> What they should, and perhaps already do, is to consult and offer
> tools or services that will help the software house generate better
> more robust PostScript.  I suspect that we are in agreement here.

Sounds good to me.

> But where we differ is that I think that Adobe might want to keep
> these tools proprietary and as trade secrets.  And I suspect that
> you would like to see them brought out into the public.

By keeping these tools proprietary, they are hurting their own standards.
The shitty PostScript generated by today's applications illustrates
that beyond any doubt.

> Oh well, I've rambled for much too long.

I sure as hell haven't.  But your points are good, and help temper the
violence of my anger.  See you on the bit stream!

> Dale Moore

-tom