Path: utzoo!attcan!uunet!husc6!think!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!andrew.cmu.edu!mp1u+ From: mp1u+@andrew.cmu.edu (Michael Portuesi) Newsgroups: comp.sys.amiga Subject: Re: A Modest Proposal (IFF QuickDraw) Message-ID: Date: 16 May 88 21:01:51 GMT References: <1760@van-bc.UUCP> Organization: Carnegie Mellon Lines: 60 In-Reply-To: <1760@van-bc.UUCP> > *Excerpts from ext.nn.comp.sys.amiga: 14-May-88 A Modest Proposal (IFF* > *Quic.. Larry Phillips@lpami.van (1633)* > By further coincidence, PostScript is an established standard, fits all the > criteria, and in addition, is supported on a great many more machines than > 'PICT'. Wouldn't it make more sense to use PostSript as the structured > graphics standard of choice? I think we are going to see some amazing > things this year at SIGGRAPH that will fit right in with this. And I think using PostScript as a structured graphics standard is stupid, for the following reasons: 1) PostScript is incredibly difficult to interpret. This will make using programs that use PostScript for an intermediate file storage format much more difficult to write, since you will have to interpret PostScript into a data structure that the computer can efficiently use, then reinterpret the whole thing back again when you save the picture. It makes much more sense just to save the data structure using a standardized format. 2) Often, programs will want to do intelligent things with the output of a structured graphics program. For example, a circuit analysis program can directly read a standardized file format and prepare parts lists, generate wire-wrap diagrams, and even provide circuit simulation. A chemical analysis program may be able to read an output file and translate the diagrams into chemical notation or English names. If you save the data as PostScript, how do you encode the semantic structure of these diagrams in a standardized manner so that a post-processor can make sense of it? With a structured graphics standard, it is easy to encode "objects" such as NAND gates or benzene rings. With PostScript, trying to interpret such semantic information would be next to impossible. 3) Saving an intermediate representation of an image as its printed output will be quite limiting when you want to output the picture on a device that doesn't understand that printed representation. For example, let's say you save the drawing in PostScript. Now what do you do when your application has to produce this output on the plotter? You essentially have to write a PostScript compiler whose output is the language the plotter understands. And you either have to write one of these compilers for every output device you want to support, or else write an incredibly complex "portable compiler" that can interpret PostScript and produce output for a grammar describing an output device. It is much, much simpler to simply encode the objects as geometric forms and generate the output device commands from that (which is what Aegis Draw does, if I understand correctly). Note that I am *not* belittling PostScript as a standard for graphics output. I think *any* structured graphics program worth using had better produce PostScript output. But it should also be able to adapt itself to other output devices, and using the PostScript paradigm to represent structured graphics is going to get you in big trouble in this regard. Deflector shields up, photon torpedoes standing by. --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"