Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!tnc!m0154
From: m0154@tnc.UUCP (GUY GARNETT)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Intuition Image structure rendering utilities
Keywords: rendered intuition image PostScript IFF
Message-ID: <776@tnc.UUCP>
Date: 27 Mar 91 22:03:55 GMT
References: <1214@muleshoe.cs.utexas.edu> <768@tnc.UUCP> <1991Mar26.154335.16403@fwi.uva.nl>
Reply-To: m0154@tnc.UUCP (GUY GARNETT)
Organization: The Next Challenge, Fairfax, Va.
Lines: 84

In article <1991Mar26.154335.16403@fwi.uva.nl> robbel@fwi.uva.nl (Robert Belleman) writes:
>m0154@tnc.UUCP (GUY GARNETT) writes:
>>Properly implemented, the conversions facility would be able to
>>support most (or all?) of the current amiga standards (including
>>internal formats, like the Intuituion Image), and be extensible, so
>>that by adding some modules to a drawer somewere, the user could
>>install support for tomorrows formats as well.
>
>Just think about this; for every ~new~ format that comes into existence
>a new conversion utility has to be written to convert into ANY other format
>that exists to that date !!  How long do you think software developers can
>keep that up ??!
>
  I don't think you understood what I was proposing.
I was not proposing that modules be written to support every possible
combination of "input" and "output" file formats.  As you pointed
out, that would require entirely too many modules.

  What I *AM* proposing is that the conversions utility be able to
convert *FROM* almost anything *TO* a limited number of Amiga
"Standards" (about half a dozen would be a good number) like Intuition
Image structures, rendering to RastPorts or BitMaps, IFF (ILBM and
8SVX seem the be most useful), and text (ASCII, ANSI ASCII, IFF FTXT,
and PostScript would be most usefull).  What about IFF DR2D and support for
3D objects? 

  In this way, an Applications programmer need only make his program
understand the applicable formats, and have an interface to the
conversions module.  This way, a data object in any
conversions-supported format could be converted to one of the
"Standard" formats for display and printing in the application.  All
any one programmer has to do is write about half a dozen small
conversion modules (and maybe even fewer) for each custom data format
that his software *CREATES*.  Public Domain programmers will probably
take care of the balance (IFF to whatever convertors, etc).

  The advantage of this method is that support for the conversions
facility is reatively easy to adto an existant program (especially if
it already knows now to deal with ASCII and IFF, let's say). 
Conversion modules should be similarly easy, with each application
needing to supply only a few (and again, these should be short, and
the programmer may be able to re-use code from his application).

>>Sorry for the long post, but this is a good Idea, and we need to get
>>working on implementing this thing.  The Amiga has been without it for
>>far too long.
>
>I agree on that last point; I think the Amiga needs something that the Mac
>has had from the beginning. I believe it's a better idea to work on a Amiga
>version of the QuickDraw library and MAYBE design converters to THIS format.
>Who knows; the format you come up with might even be so good that it will be
>an Amiga standard ...
>
>If you like, look at it as a intermediate graphic format, I don't care ...
>
>>Wildstar
>
>-- Rob
>
>Robert Belleman, University of Amsterdam.
>(robbel@fwi.uva.nl)


I don't think that an Amiga quickdraw is a useful effort.  Existant
programs will not be able to support it without major coding changes,
and this alone would probably doom such an effort to obscurity.

Quickdraw works on the Mac because almost everything destined for the
screen goes through the QuickDraw system at some point.  Althoh this
allows the Mac to do some of its magic, it also places restrictions on
Mac programmers.  Amiga programmers are used to being able to directly
access their screen bitmaps; removing this ability would probabily be
unacceptable.  If nobody used the standard, it would not have the
effect we are looking for (easy interchange of data between programs).

If the set of output formats for the conversion facility is relatively
small and well-chosen, it will become relatively easy to implement
while providing great additional value to the product.  This spells
success to me, and to most software developers (this is the same
reason that Arexx has enjoyed the success it has: an Arexx port is
relatively easy to add to a program, and enhances its value
immensely).

Wildstar