🚀 go-pugleaf

In a previous posting I opined that a major reason for PostScript's success
was that it comprised 90% of a badly-needed graphics standard and that the
industry was more interested in immediate products than in wangling over that
last 10%.

IMHO the major impediment to PostScript's use as a graphics standard is the
simple fact that it is essentially impractical to use PostScript as INPUT
to a graphics program.  The only processing a program can do to incoming
PostScript is to wrap it up in a different graphics environment and output
the whole mess to a PostScript imager.

That one can perform such a wide variety of tasks by doing this graphics
environment-fiddling is a great testament to the elegance, power, and
generality of the PostScript language.  However, it is not practical to read
a PostScript description of an object and then calculate the centroid and
moments of intertia.  It is not practical to read a PostScript description
of a sprocket and build the numerical milling machine control commands to
manufacture that sprocket.

These are real-world things that real-world people want to be able to do.

A similar argument can be made about many of the kitchen-sink graphics
standards.  A program to INPUT standardized data turns out to be huge and
ungainly due to the sheer number of different primitives it must understand.
If one subsets the standard, one risks introducing incompatabilities with
systems that produce or require primitives that were subsetted out.

-- 
Sig     DS.L    ('ZBen')       ; Ben Cranston <zben@Trantor.UMD.EDU>
* Network Infrastructures Group, Computer Science Center
* University of Maryland at College Park
* of Ulm