Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!munnari!stcns3!mikb From: mikb@stcns3.stc.oz (Mike Benson) Newsgroups: comp.sys.amiga Subject: Re: Structured Graphics Standard Summary: Use a REAL standard Keywords: standards, GKS, !Quickdraw Message-ID: <877@stcns3.stc.oz> Date: 21 Sep 88 06:01:27 GMT References: <5053@netnews.upenn.edu>Reply-To: mikb@stcns3.stc.oz (Mike Benson) Organization: Alcatel-STC Australia, North Sydney, AUSTRALIA Lines: 69 In article mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >> *Excerpts from ext.nn.comp.sys.amiga: 8-Sep-88 Structured Graphics Standard* >> *Ranjit Bhatnagar@eniac.s (1411)* > >> 4 or 5 months ago I posted a message suggesting that we need a >> structured graphics standard for SIMPLE graphics - lines, filled >> polygons and ellipses, and multi-font text. I suggested that as long >> as Apple already invented Quickdraw, we might as well use that -it's >> simple, relatively easy to implement (all we're missing is RoundRects >> and arbitrary regions - ok, the latter ain't so easy) - and there's >> 400 zillion people out there using MacDraw. The overall net response >> was "nawww, we can do better than that." > > >My response at the time (after checking with my MacFriends) was that the >Quickdraw PICT format was documented by Apple for debugging purposes only. The >actual code to manipulate PICTS is part of the Apple ROMs and is subject to >change without notice. Developers are actively discouraged from writing code >to manipulate PICTS directly. > >Hence, it is impossible to write an Amiga PICT reader and guarantee it to be >compatible with Apple PICTS present and future. > >If you wish to use PICT as a basis for an Amiga standard, then do so. But >don't try to push PICT on us for compatibility reasons, which (in my opinion) >are the only really compelling arguments for using PICT. > > --M It would appear from this that using Quickdraw PICT is inappropriate as a "standard" for structured graphics, because it's proprietary. OK, what about one of the internationally approved graphics standards, like GKS? GKS, via something called Workstation Independent Storage, and using a related standard called the Computer Graphics Metafile provides a device-independent way of handling graphic structures (called segments) which can be stored, transferred, printed, transformed, combined (a segment can consist of a combination of primitives and instances of other segments) and (even) displayed. It handles lines, areas and text in different colours and patterns, and best of all, most of the basic drawing primitives are already available as ROM kernel routines. Why not go with a real standard for once, instead of running to the first vendor who happens to define a format? The idea of a structured graphics standard is not a bad one, but I think that it would be better to use a non-proprietary standard, which will, I think, do most of what you want, rather than make yourself a slave to the whims of a vendor. > >Michael Portuesi / Information Technology Center / Carnegie Mellon University >ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas > Mike Benson Newsgroups: comp.sys.amiga Subject: Re: Structured Graphics Standard Summary: Expires: References: <5053@netnews.upenn.edu> Sender: Reply-To: mikb@stcns3.stc.oz (Mike Benson) Followup-To: Distribution: Organization: Alcatel-STC Australia, North Sydney, AUSTRALIA Keywords: -- Mike Benson +---------------+ mikb@stcns3.stc.OZ.AU Alcatel-STC Pty Ltd | CAVEAT | 11th Floor, 5 Blue St | LECTOR | Any clod can have the facts, North Sydney NSW 2060 AUSTRALIA +---------------+ but having opinions is an art.