Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.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: <768@tnc.UUCP>
Date: 25 Mar 91 17:35:08 GMT
Article-I.D.: tnc.768
References: <1214@muleshoe.cs.utexas.edu>
Reply-To: m0154@tnc.UUCP (GUY GARNETT)
Organization: The Next Challenge, Fairfax, Va.
Lines: 86


This is a Dard Good Idea!

Because I like this idea so much, I will write up the spec, if no one
else volunteers to (there are many other people on this group who are
much more qualified to do it than I am).

I have a couple of observations:

How about generalising it to a conversions utility.  One of the good
features of the Mac is that it has such a thing built into its
clipboard; you can clip something out of one program, and paste it
into another, usually without worring about it.

If implemented as an independent task (perhaps with a support
library), the conversions module could be made even more flexable. 
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.

Here is what I am thinking of:  A host process which manages one or
more message ports (for receiving conversion requests).  A shared
library of conversion tools (routines for managing conversion
requests, the conversion message ports, and support routines for the
convertors) to reduce the memory consumption of the whole thing, and a
set of convertors.

Each convertor supports one kind (or a limited set of similar
kinds) of conversion (for example, PostScript to Image, or another one
which converts DR2D to IFF).  Each one has some parameters which it
uses to control the conversion, and input and output data formats.
The conversion facility maintains a list of convertors, and can load
them from disk, order them to shut down or start a conversion, and
generally provides overall management.  (Presumabley, the it
can scan the convertors on disk to determine which kinds of
conversions it can support; no reason to require all of the convertors
to be loaded in RAM at once).

This would also allow programs (like word processors or DTP software)
to request a printer-resolution version of an "unknown" format.  The
program would simply request a conversion into a bitmap at the
appropriate resolution, and then include the bitmap with the rest of
the printer data.  A set of convertors which output PostScript would
allow printing on PostScript laser printers.

Items for Discussion: Programmer's interface - how to request
conversions, how to present the item to be converted, and select
conversion options.  There needs to be a standard interface, because a
program written to use the conversion facility may need to convert a
format which didn't exist when the convertor or the application
program was written.

Convertor interface - So that applications programmers can write a set
of convertors for their product.  Again, a standard interface, so that
the convertor will work with products which haven't been created yet.

Developer Co-Operation - For this scheme to work, each software
developer will need to create a set of convertors for their product
(for example, ProWrite to IFF, ProWrite to PostScript, ProWrite to
ASCII, ProWrite to FTXT, etc).  While this is a little extra work, it
will (hopefully) add value to your product.  If your (Word Processor,
Paint Program, Cad Package, Spreadsheet, whatever) supports the
Conversion Facility, then people who own a (DTP Program, etc ..) which
also supports it will want to buy your product (since they know that
they can then exchange data between the two programs).

"Hot Conversions" - What about when two Conversion Facility using
applications are running at once?  Should they be able to pass data
from application-to-application through the convertor (so you can edit
that bitmap, and pass it back, for example).

Additional Standards: Do some additional standard formats need to be
defined (for example, what do you do with formatted text? or what
about 3D objects?.

My feeling is that the first three items (Programmer and Convertor
interface, and Developer Co-Operation) are critical.  The other two
(Hot Conversions and Additional Standards) can safely be shelved.

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.

Wildstar