Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!killer!elg
From: elg@killer.UUCP (Eric Green)
Newsgroups: comp.sys.amiga
Subject: Re: A Modest Proposal (IFF QuickDraw)
Message-ID: <4054@killer.UUCP>
Date: 12 May 88 06:02:15 GMT
References: <4607@super.upenn.edu>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 59

in article <4607@super.upenn.edu>, ranjit@eniac.seas.upenn.edu (Ranjit Bhatnagar) says:
> 
> 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. 

One motivation is for interfacing with laser printers and, especially,
plotters. My brother recently laid out a PC board. He used an IBM PC clone. It
was the only machine around that had a program that supported his company's
plotter (his company doesn't have any CAD workstations -- heck, they were
laying out PC boards by hand until recently, times are tough in the oil
business!). 

So adding an additional device to the Amiga, such as, hmm, "PLT:", which
prints these vector-oriented "plottings" to a high resolution device, may be
a necessity. I don't know if the printer.device could handle such output in
such a manner as to not lose resolution.

Another reason would be incorporation of graphics images into text files, a'
la' Macintosh. This is one of the problems impeding the success of the Amiga
(and PC Drones) in the desktop publishing industry. It seems immediately
obvious that such files would consist of text hunks, picture hunks, and
formatting hunks. And, in order to interface with high-resolution output
devices, the picture hunks would need scaling information -- they most
probably would not fit on a screen (I am currently working with a frame
grabber card that returns full RGB pictures, and displays a HAM-mode or hires
reduction of it to let you know what it generally looks like -- if there was a
suitable output device, you could process camera-ready copy quite readily).

I don't think that QuickDraw is the solution to the graphics images/text files
problem. IFF would seem to solve that quite readily, with a couple more
imbellishments. 

Another problem: Data transfer between CAD programs. Unfortunately, I don't
think it'll happen. A drafting program has little business talking to a PC
board layout program. One talks in terms of x,y and lines connecting them,
along with text here and there. The other talks in terms of nodelists and
such. A QuickDraw-like language might be good for data interchange between
drafting programs, but I haven't seen much of a hue and cry for it.

> 	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.

Hmm. A possibility. It does seem that we do need some IFF extensions to deal
with CAD programs and desktop publishing. I'm not sure that QuickDraw is the
answer, though.  

--
    Eric Lee Green                     {cuae2,ihnp4}!killer!elg
         Snail Mail P.O. Box 92191 Lafayette, LA 70509              
"Is a dream a lie that don't come true, or is it something worse?"