RE: is PostScript platform-independent?

[Ted Harding]

On 24-Aug-98 Jeff Kingston wrote:
> Uwe wrote:
>  
>> [PostScript is a] a widely available, rock solid, platform independent,
>> ... PDL
>  
> I once said the same thing to a correspondent, whose reply was that
> postScript *was itself* a platform, hence was in no way platform-
> independent.  As I recall he had a HP printer of some kind with its
> own (technically inferior) PDL.  From his point of view, PostScript
> was a particular, proprietary, platform that he didn't own.
>  
> I've also come to the view that Lout's reliance on PostScript for
> features such as diagrams and graphs shows that Lout has some
> fundamental deficiencies.  A document layout language ought to be
> able to handle diagrams and graphs, and lay them out to the point
> where the device just has to be told "draw this shape here, fill
> that outline there", etc.  In fact, I think that one way forward
> from here is to look at the things that Lout passes down to
> PostScript and ask "what would a language need to have in order
> to be able to do these things itself, without losing the many
> good things that Lout offers now?"

Hi Jeff, and all,

In my view PostScript, and the "device-independent" internals of a formatting
package, overlap, but it should not be considered that either necessarily
subsumes the other (by "internals" I include e.g. the primary output of TeX as
a .dvi file, or e.g. the direct output of (di)troff prior to postprocessing for
a particular device, as well as, e.g., whatever internal streams get converted
to PostScript by Lout prior to output).

At one extreme, a minimal set of PostScript functions (the bitmap rastering)
can be used to render anything that a program orders to be printed. Here,
any processing that PostScript might have done is taken over by the program,
which has to work everything out itself. PostScript's programming-language
capability is almost superfluous in this context.

At the other extreme, a program may generate a minimal POstScript file which
however throws a very heavy computational load on the PostScript interpreter
device. As a nice (though somewhat "toy") example of this, have a close look at
the ghostscript example file

  /usr/share/ghostscript/5.10/examples/escher.ps

(or wherever it precisely is on your system). At the very start of the PS code
is a line

  /nlayers 1 def

First, view the file as it is. Then alter this line to, say,

  /nlayers 4 def

and view it again. This file relates intimately to PostScript as a full
programming language. In fact, scattered through the file are several parameters
which could be modified for different effects. I could write (say in awk) a
variety of very tiny programs to produce a variety of Escher diagrams.

When you say, Jeff, that
> A document layout language ought to be
> able to handle diagrams and graphs, and lay them out to the point
> where the device just has to be told "draw this shape here, fill
> that outline there", etc.
I might be tempted to respond "Well, one of my little awk programs for playing
with escher.ps is doing just that". A bit devil's advocate, but you take the
point: it depends on what you mean by "shape", "outline" etc.

Part of the argument underlying the issue you raise depends on the fact of life
that _most_ rendering devices have very primitive resources compared with
PostScript, so all those people who have them need a filter to break the
PostScript down to the elements that their devices understand. Now ghostcript
does a pretty reasonable job on rasterising PS for a great variety of devices
(with the exception that if you only have the public-domain ghostscript fonts
the results can look a bit rough). That exception aside, I don't really see the
logical difference between, on the one hand, using PS as the primary output
(call it device-independent if you will -- I do think that's really a
superficial terminology question; after all, a printer that takes a TeX .dvi
file as direct input is quite conceivable: is .dvi then device-independent?)
and then converting that to whatever the rendering device understands; and,on
the other hand, producing a so-called "device-independent" output stream from
the formatting program and then post-processing that to suit the end-device.

For these reasons, I would NOT agree that
> Lout's reliance on PostScript for
> features such as diagrams and graphs shows that Lout has some
> fundamental deficiencies.

PostScript is a perfectly good way of telling the outside world what you want.
Before, however, the outside world can execute this, an interpreter may,
according to circumstances,  need to intervene. Converters between PS and X
should be the responsibility of whoever makes X, or of people who make it their
business to write converters (like Alladdin for ghostscript).

There is an analogy with machine translation between human languages. You can
set yourself the (N-1)*(N-1) tasks of writing converters between each directed
pair of languages out of a repertoire of N languages; or you can set yourself
the 2*N tasks of writing the N translators into a "neutral" representation NR
and the N translators out of NR. The latter is economical as soon as N>3. The
hard bit is setting up a sufficiently general NR.

When every one of M separate formatting programs has to incorporate N
converters for each of N devices, you can similarly compare the M*N converters
required for this, with the M+N converters required to first output PostScript
and then convert PostScript. PostScript is already sufficiently general to
serve as a Neutral Representation. What alternative NR would you use? TeX's
.dvi? How, in principle, is this different from using PostScript (except by
being much more restricted -- try doing "escher.ps" in .dvi!). The fact that
some respected DTP programs produce absolutely lousy PostScript is NOT an
intrinsic defect of PS itself, nor an argument against using it.

Comments welcome!

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Date: 25-Aug-98                                       Time: 02:10:56
--------------------------------------------------------------------