🚀 go-pugleaf

*sigh*  somewhat ill-prepared to jump in here, not having my IFF specs
onhand, operating from memory and on general principles.  Hope this
post makes it through the system; my infrequent posts over the last
few months seem to have found their way to the bit bucket...

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

Stuart> Storing coordinates in floating point is not an ideal choice.

On 15 Nov 89 23:29:32 GMT, cunniff@hpfcso.HP.COM (Ross Cunniff) said:

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

You seem to have missed the point; what is important is not
flexibility for manipulation and calculation so much as flexibility
for interchange.  This is to be an _Interchange_ File Format, so it
should be designed for maximum transportability.  Regardless of the
usefulness of floating point numbers, extra code is required to handle
them.  No sense in forcing a program which would use fixed point to
handle floating point for the IFF file when it has no other use for
floating point.  It's sort of like creating an IFF format which uses
EBCDIC for text because you want to be creating the data on an IBM
mainframe -- sure, it's more convenient, but less workable, in the
long run...

Ross> Your point about calculations is invalidated below.

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

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

Integers certainly ARE more natural than floating point, from the
perspective of the processor -- the 68000 certainly can't deal with
IEEE as easily as fixed point...  Yes, you can compile in the IEEE
code, but it increases code size and complexity, which is an
undesirable consequence if the program has no use for floating point
internally...

Stuart> I think that the layer information does not belong in the data
Stuart> for each object, but rather as a property of a whole
Stuart> collection of objects.  I will spell this out later on.

Ross> The layer information of objects inside groups is ignored, but
Ross> might become meaningful if the objects are later ungrouped.

I'd also suggest using PROPs in a LIST -- more "IFF-like"...

Stuart> The bounding box information simply doesn't belong here.  What
Stuart> useful purpose does it serve in the file?  None.

I don't think it harms anything to include it...  the only harm is in
DEPENDING on it to exist and be accurate.  Definitely should be an
optional chunk.

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

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

Don't use a separate FORM; use a chunk in FORM DR2D with the data
followed by the nested ILBM FORM (within that RAST chunk)...

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

Never depend on security through obscurity...

Stuart> [...] look at the FTXT.FONS chunk.  Better yet, use it!

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

Still less flexible.  Besides, from what I recall of FTXT.FONS, it
shouldn't matter if you're storing names of PostScript fonts instead of
Amiga fonts...

Ross> OK.  Now for the most serious objections:

Stuart> This one is a serious, serious problem.  [...]

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

Stuart>  There are probably better ways waiting to be discovered.

Ross> How about:

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

Please bear in mind that these bits of data (DSYM, XTRN, etc.) have no
meaning beyond the context of the FORM DR2D, and that FORMs are a
top-level construct.  Apart from the general undesirability of
cluttering the FORM namespace, you would have little use for an IFF
file consisting solely of FORM XTRN, ne?

The "right" way to do it is similar -- Use FORM DR2D nested, and have
the nested ones contain the XTRN/DSYM/whatever chunks, and further
nested FORM DR2D chunks if need be.

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

Well, I couldn't you write a reader for the old format and a
reader/writer for the revised one, so you could just convert them all?

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

I agree here.

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

The point is that it completely violates the IFF guidelines -- it's
not a question of making the generic reader flexible enough.
Compromising the IFF guidelines would defeat its entire intended
purpose.

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

Well, I'm not Stuart, but I thought I'd toss in my thoughts.  Good
luck with fixing it up (please do!).  Cheers!

Deven
-- 
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2151 12th St. Apt. 4, Troy, NY 12180   Phone:  (518) 274-0327
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.