Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!agate!ig!uwmcsd1!marque!gryphon!richard From: richard@gryphon.CTS.COM (Richard Sexton) Newsgroups: comp.sys.amiga.tech Subject: A modest proposal (was IFF/Quickdraw) Keywords: PostScript Message-ID: <4083@gryphon.CTS.COM> Date: 18 May 88 21:38:26 GMT Organization: Trailing Edge Technology, Redondo Beach, Ca. Lines: 123 In article <53552@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <132@amtfocus.UUCP> jeffle@amtfocus.UUCP (Jeff Leitheiser) writes: >> I agree that there NEEDS to be ONE standard for storing semi-intelligent >> graphics....is postscript the answer? I'm not an expert on postscript, >> but what about 3D objects? Yes, most of what people do today is 2D, but >> the real power of computer graphics is the use of 3D models that you >> can build, rotate, and analyze BEFORE you worry about the traditional >> 1,2,3 or 4 view drawing... > >Whoa! There are several problems here that everyone is trying to solve >with *one* solution. (You may recall during the IPC discussion the same >phenomena occurred). The two big ones in Jeff's message are "rendering >to the screen" and "storing object definitions". > >Rendering to the Screen : > >The Amiga screen rendering routines are raster based and fast. This >works well with the screen because they operate at the full resolution >of the screen. This is not true for printers because chances are that >the routines do *not* work at the printers resolution. Apple's solution >to this (which is the current yardstick) was to define a set of >graphic primitives that were implemented in *both* the machine and >the printer. Each rendering to the hosts resolution. They also included >a quickdraw to PostScript translation scheme so that the images could be >sent to the LaserWriter as well. (Anyone remember InterPress?) Anyway, >the problem is to provide a set of graphics calls that can be directed >at *any* device and they will render on that device at the maximum >resolution of that device. The sub problems come in the form : Are these >commands or are they simple values? Can you define the appropriate >subset of commands that give you the require capabilities? etc. > >PostScript was suggested as the drawing language but in case you haven't >noticed, even Apple doesn't use native PostScript on the Macintosh because >it cannot be rendered quickly enough. So the goal becomes to come up with >a flexible drawing language that can be rendered quickly, but contains >sufficient flexibility that most (where most is arbitrarily set to 85%) >of the things you want to render, can be, without resorting to 'going >around' the language. NOTE : For screens and printers etc two dimensions >are sufficient. Thank god. Somebody else understands this too. For inclusion into IFF files, I propose that types (or hunks or whatever the appropos terminology is) be invented that correspond directly to PS primitives. What we end up with then, is essentially Amiga quickdraw, except we dont call it quickdraw. To render an 'amiga quickdraw/PS/IFF' file: 1) To the screen: there already exists an Amiga PostScript previewer. Thats the hard part. The conversion from 'amiga quickdraw/PS/IFF' file to PostScript commands is trivial. 2) To a plotter: Fancy text manipulations, and clipping is the most problematic issue here, as I see it. The rest is trivial. 3) To bitmapped printers: Use the output of 1) 4) Object oriented printers: Right now this means PostScript printers. Again. The conversion to PS is trivial. Besides printers there are phototypesetters, and soon there will be a PostScript color film recorder. If you look at the trend in peripheral, over the last 10 years, and where the peripherals industry is going, you will notice that more and more intelligence is being built into peripherals, and this is especially true of printers. It will not be long before PostScript dot matrix printers appear, but that would be telling. The single biggest advantage to PostScript (besides the fact it precludes the mac weenies from jibing us any further on it) is that THE PERIPHERAL DOES THE RASTERIZATION. If there were any NAPLPS or CGI/CGM or what have you peripherals, that "spoke" these standards, they might be worthy of consideration. But there arn't, and it's not. And despite what K*nt thinks, PostScript is more of a standard (via encapsulated PostScript) than CGI/CGM simple because of installed base. Applications that can handle EPS abound on EVERY computer, they have to - thats where the industry is moving. NAPLPS is a joke. Is has a very limited domain, and conforming with it buys us nothing. >Storing Objects and such : > >This is the area that Jeff expounds upon and I agree it could use some >standardization. The Videoscape 3D and Sculpt 3D people seem to have >the most to gain at the moment however all of us would benefit if one >3D object specification format existed. Jeffs 'scaled' integers is an >excellent approach and it would make 3d objects *much* easier to use. >Consider a 3d format that consisted of one floating point number >(the "units") and all other numbers in integers. All packages could >scale the object to the precision of the floating point format they >used. Oh please. Lets get 2D objects working first. While the temptation is great to standardize 3D, I think it is a bad idea for two reasons: 1) Lets get some feedback with our experience with 2D. 2) There is a line of reasoning that says: "Well shoot, if we're gonna do 2D, we may as well do 3D". "And if we're gonna do 3D we may as well render it fully as a solid not just as a wireframe". "And if we're gonna render solids, we may as well have shading". "And if we've got shading, we may as well have light sources" Pretty soon we end up trying to implement Dore, when all we wanted to do in the first place was do have a simple standard for sharing 2D objects. One thing at a time please. It's much easier that way. -- Have a nice day or Klortho will rip your nuts off. richard@gryphon.CTS.COM rutgers!marque!gryphon!richard