Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!cunniff
From: cunniff@hpfcso.HP.COM (Ross Cunniff)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Response to DR2D format specification
Message-ID: <9310004@hpfcso.HP.COM>
Date: 15 Nov 89 23:29:32 GMT
Article-I.D.: hpfcso.9310004
References: <14491@well.UUCP>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 273

shf@well.UUCP (Stuart H. Ferguson) writes:

>| Coordinates are specified in IEEE format (see note 1 for a
>| description of the IEEE format).

>Storing coordinates in floating point is not an ideal choice.  For some
>things floating point numbers are essential, but not for drawings.  The
>advantage that floating point numbers have over fixed point is that they
>are valid over a much greater range, and are therefore useful for 
>calculations involving multiplications.  Fixed point numbers, however,
>are more accurate and operations on them are faster, but fixed within a 
>narrow range.  This makes them more appropriate for calculations 
>involving additions and subtractions.  Since coordinates of greatly 
>differing magnitude cannot be mixed in the same drawing, and the edges
>of a drawing provide a natural boundary for the scale of the numbers, and
>the fact that vectors are often added and rarely multiplied, fixed point 
>coordinates (integers) are a more natural choice for drawings.

I disagree.  Floating point numbers are infinitely  more flexible
than integers.  Fixed point numbers are *not necessarily* more
flexible than floating point.  Why can't coordinates of greatly differing
magnitude be mixed in the same drawing?  What if I want to specify
coordinates in millimeters?  What if I wanted objects of great detail
spread across a large distance (a map of the solar system, perhaps)?

Your point about calculations is invalidated below.

>This does not mean that any given program couldn't use floating point
>numbers internally.  It just means that the Interchange format for drawings
>would use the more natural fixed point notation for exchanging data
>between varied applications, some which use floating point interanlly
>and some which do not.  But none are required to parse it when they don't
>have to.

You just proved my point - 'This does not mean that any given program
couldn't use fixed point numbers internally'.  Integers are no more natural
than floating point.  Your point about 'parsing' is a red herring -
nearly all computers (except maybe some DEC computers :-) use IEEE
as their 'natural' floating point format, and both Amiga C compilers
are the same.  IEEE is actually not terribly hard to translate.

>WhichLayer is somewhat ambigious.  Can you have, for example, a group
>with components in more than one layer?  If so, what does it mean?
>The "use a symbol" chunk has its own WhichLayer field, as do each of
>the components of the symbol.  Which layer wins?  I think that the
>layer information does not belong in the data for each object, but 
>rather as a property of a whole collection of objects.  I will spell
>this out later on.

The layer information of objects inside groups is ignored, but
might become meaningful if the objects are later ungrouped.  It
depends on the application.  One application might use that layer
information, where another might reset it to the layer information
of the parent group.

>The bounding box information simply doesn't belong here.  What useful
>purpose does it serve in the file?  None.  It does make it much more 
>difficult for simple programs to write one of these files, because it 
>makes them compute the bounding box for each object, even if they don't 
>*use* that information themselves.  Because the box includes the line 
>width, mitering makes this a non-trivial calculation.  In fact, because 
>there's no specified limit on the length of a miter, the bounding box is
>_undefined_ in the general case.

I should have specified that the miter limit is assumed to be the PostScript
default - 10x line width, if I remember correctly (I left my info at home).
As for useful purposes, a display program could trivially decide whether
an object is visible in its current viewport and not display objects
which are obscured.  Bounding boxes are *extremely* useful pieces of
information.  I would be willing to extend the meaning of these numbers
as follows:

	"If any of the coordinates of the bounding box have a bit pattern
	equivalent to the constant INDICATOR, the bounding box information
	is not valid and must be created by the reading program, if it
	is necessary."

>| /* 8x8 bitmap fill patterns */ /* OBSOLETE */
>
>If it's obsolete, why publish it?

The "OBSOLETE" should have read "OBSOLETE?"  We haven't decided how
useful this is in an object-oriented program.  All Mac programs seem
to have them (a powerful clue...)

>| XTRN (0x4554524E)	/* Externally controlled group */
>
>It would help transportability if there was some clue what this chunk
>was about.

On the Amiga, an externally controlled group is one where for each
manipulation performed on that group (i.e., resizing, rotating, moving,
etc.) the ARexx macro named 'ApplName' is called with appropriate flags,
etc.  This turns out to be useful for all sorts of things (like
dimension lines; or bar charts where twiddling the size can change
the numbers in a spreadsheet, for example).  Other systems will have
to make their own interpretations of an XTRN.  Note that the XTRN
objects are easily displayed, since none of the callback stuff determines
how they *look*.

This should be better documented in any case.

>| /* Color map */
>I assume (since it's not specified) that the colors are in R G B order
>with 0=min intensity and 255=max intensity.  If so, then this chunk is
>the same as the ILBM.CMAP chunk, which is probably a good thing.

Yep.  Exactly the same (except that all 8 bits of each of R G and B are
potentially significant...)

| RAST (0x52415354)	/* Raster image */

>With the exception of virtual coordinates and size, this is just like a
>simplified ILBM.  Using nested ILBM's here would facilitate 
>transportability and would serve the IFF charter a lot better.  Again,
>the "Closest" array is information that is best computed by the target
>application and should not be stored in the file.  Same reasons apply
>as for the bounding box.

Have you any idea how long it can take to calculate the closest colors in a
large bitmap?  I might consider, however, a chunk that looks like:

	FORM {
		RAST	(put virtual coordinates and 'closest' stuff here)
		FORM {
			ILBM
			...	(etc)
		}
	}

See below on the difficulties of us changing the format this drastically.


>| Note that most chunks have
>| both a chunk Size and an object Count.  I know this is redundant;
>| however, this allows the data structures to be extended in a
>| compatible manner if it should become necessary in the far future.

This paragraph should probably be deleted.  I don't see any particular
objection to having the counts in the chunks, though.


>| PREF (0x50524546)	/* Application preferences */
>
>First of all, it looks like some of this information would be of general
>interest and would be better to be stored in documented chunks. The
>Copyright "(c) " chunk already exists in SMUS, for example.

True, true.  I'll consider it...


>[...] If ProVector is 
>willing to deal with this possibility, then it can certainly *request*
>that other programs leave this chunk intact.  Don't expect competitors to
>leave it in though.  :-)

True, it's a risk.  Documenting some of them might reduce that risk
(or it might just tempt the competition :-)

>Dumping all the font names in one big lump is not a very flexible way
>to indicate fonts, from an IFF standpoint.  For example, there is no
>way to selectively override a single font in a nested FORM.  For a better,
>more IFF-like way to specify fonts, look at the FTXT.FONS chunk.  Better
>yet, use it!

Well, for one thing, these fonts are *not* the standard Amiga fonts.
Also, it's very nice to have a list of the fonts all in one place.  Note
that it simplifies text objects, since all they have to include is an index
into the font table to tell which font they use.


OK.  Now for the most serious objections:
>| NOTE 4: The  data in a FILL,  DSYM  or  GRUP chunk is a series of nested
>| 	object chunks.  All object chunks except DSYM, CMAP, PATT, FILL,
>| 	and FONT are allowed in a DSYM or GRUP.

>This one is a serious, serious problem.  This type of nesting is not 
>supported by IFF, and is inconsistent with the provided mechanism.  While
>there is no technical reason why the content of the chunks couldn't be
>defined this way, doing so flys in the face of a consistent IFF 
>philosophy.  These nested chunks cannot, for example, be read by the
>generic iffparse.library, since the library was designed to deal with
>standard IFF nesting constructs.  Reading this would require every
>programmer to code their own custom reader, and would futher set back
>any progress toward providing general IFF parsing tools.

True.  I hadn't considered generic IFF parsers when I wrote this.

> There are probably better ways waiting to be discovered.

How about:

	FORM {
		DR2D
		...	(a bunch of objects)
		FORM {
			GRUP	(has an object header)
			...	(a bunch of objects)
		}
		FORM {
			XTRN	(has the same XTRN header)
			...	(the objects for the XTRN)
		}
		FORM {
			FILL	(might have object count for grins)
			...	(the possible FILL objects)
		}
		FORM {
			DSYM	(might have object count for grins)
			...	(the object in the symbol)
		}
		...	(other objects...)
	}

I actually rather like this; I'm not sure we'll be able to change it though.
We have on the order of 3-5 different companies working on importing
our file format at this point (I'll not name names).  We'll have to
talk with them and determine how far along they are toward implementing
the readers.

>The basic point is that the nesting *must* look something like this 
>in order to be IFF.  The mechanism specified in note 4 is vaguely
>like IFF, but it isn't, and never will be.  If this format is released 
>in its current form, I will certainly do everything I can to prevent it 
from ever being accepted as a Commodore standard IFF FORM.  The damage
>to IFF integrity would be too great.

Oh, I don't know that it would be *that* great...  Is iffparse.library
not flexible enough to do something like this:

	Chunk = ReadIFFChunk( ReaderFunc, (void *)InFile );
	if (Chunk->Generic.ID == GRUP) {
		for( i = 0; i < Chunk->Grup.NumObjs; i++ ) {
			SubChunk = ReadIFFChunk( MemReaderFunc, (void *)Chunk );
		}
	}

Actually, I don't know how iffparse.library works at all, as you can
probably tell :-)  Let me know how off-base I am...

>On a more positive note .. I mentioned earlier that there is a more
>IFF-ish way to encode layers.  Rather than having the layer number as
>a parameter in each object in the file, the layer ID could be a
>property chunk with the file organized as a list of drawings, one in 
>each layer.

I don't particularly like this.  It makes moving objects around from
layer to layer rather difficult.  

>This takes full advantage of the built-in IFF semantics for lexically
>scoped properties within LIST's.  It is, of course, somewhat harder
>to read, but not that much.

I think it is quite a bit harder to read, myself.  This was one of the
hot points of discussion when the format was originally posted.  The
consensus was that 16-bit layer id's on each object was a better
way to go.

>So let's hear from you Ross.  I'm sure that there's a way to make this
>format more in the spirit of IFF without holding up your delivery 
>schedule too much.  I'd be glad to work with you on this one.  A few 
>conversations should be all it takes.

Sorry it took so long to respond - business trips and all.  I'm looking
forward to the next set of comments...

>		Stuart Ferguson		(shf@well.UUCP)
>		Action by HAVOC		(ferguson@metaphor.com)

				Ross Cunniff
				Hewlett-Packard Colorado Language Lab
				...{ucbvax,hplabs}!hpfcla!cunniff
				cunniff%hpfcrt@hplabs.HP.COM