Path: utzoo!mnetor!uunet!husc6!mailrus!umix!nancy!eecae!super.upenn.edu!eniac.seas.upenn.edu!ranjit From: ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) Newsgroups: comp.sys.amiga Subject: A Modest Proposal (IFF QuickDraw) Message-ID: <4607@super.upenn.edu> Date: 10 May 88 19:30:59 GMT Sender: news@super.upenn.edu Reply-To: ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) Organization: University of Pennsylvania Lines: 79 Summary: We need a standard for simple structured graphics The problem: We don't have a standard for the transfer of "structured graphics," that is, pictures described as sets of drawing commands rather than as bitmaps. The primary motivation for such a standard is to allow charts, diagrams, etc. to be imported into word-processors or other programs and still be printed at the maximum resolution of a given output device. For the right sorts of pictures, this method gives not only better output, but also more efficient storage. Such a standard should provide, at a minimum, the following: arbitrary text lines and patterned lines (arbitrary thickness) rectangles and filled rectangles ovals and filled ovals polygons and filled polygons support for color inclusion of bitmaps By some coincidence, there already is such a standard: Apple QuickDraw. So called "PICT" images consist of, effectively, a script recording a sequence of calls to the graphics library. An additional potentially useful feature is the ability to insert arbitrary comments, which can be used to notate the file for human consumption, or to pass system-exclusing information. See Inside Macintosh for more details - I'm not that well informed myself. Why QuickDraw? Because it's there, already in use on millions of machines. I'll be the first to admit that it's limited - for instance, there is no support for splines, and color support is minimal. However, for a very large number of common tasks, this standard provides all the necessary power. For example: statistical or scientific graphs and charts, diagrams, simple tricks with text (for posters, letterhead, and such), simple cartoons, electronic schematics, fancy signatures, borders, many architectural plans, and more - think of anything you can do with MacDraw. There certainly should be work on a more powerful standard, one which can take advantage of more of the power of PostScript, but meanwhile, QuickDraw could come in handy. How? We would need to implement those graphics primitives available in the Mac libraries but not in the Amiga libraries: rounded rectangles, clipping to arbitrary regions, and such. There would still be a lot of function without these features, in fact, but it would be nice to have compatibility. We may also want to extend it to support operations to which we have grown accustomed on the Amiga, such as minterm block operations, and those which are supposedly coming, like Color Fonts, and expand color support. (If I'm not mistaken, Color Quickdraw has a limit of 8 colors - which isn't bad, still. It could be it was 8 bitplanes, which is more than we need (for now!).) It would be nice to have a quickdraw.library which, as a layer over the graphics.library, provides the functionality to "record" and "playback" QuickDraw images in a Mac compatible way. Given such a library, a program with the functionality of MacDraw would not be far behind. (Not to malign such programs as Aegis Draw - but sometimes these are too powerful for many uses - and besides, they can't export their graphics to a word-processor as structured graphics, which is the whole point.) QuickDraw could easily be given an IFF wrapper: take the QD data and call it 'PICT' or something like that. For purists, QuickDraw could even be stored in an IFF-like way, containing chunks like MOVE, x, y, or CIRC, x, y, r. The recursive nature of IFF would accomodate the heirarchical grouping possible in QuickDraw. But that seems like more than we need. SO: whaddya think? Please send comments to me or to c.s.amiga (or c.s.a.tech?) as you see fit. This is our chance to nip a new Standards Committee (i.e. four people flaming each other on the net) in the bud... - Ranjit (ranjit@eniac.seas.upenn.edu) === === === Pa! Molly's dead! She ate some leaves! === === === "Trespassers w" ranjit@eniac.seas.upenn.edu ucbvax!rutgers!super!eniac!... Ranjit Bhatnagar, Graduate Student Molly's not dead, she's only sleeping.