zben@umd5.umd.edu (Ben Cranston) (03/05/90)
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