Path: utzoo!attcan!uunet!samsung!gem.mps.ohio-state.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Response to DR2D format specification Message-ID: Date: 20 Nov 89 00:54:01 GMT References: <14491@well.UUCP> <9310004@hpfcso.HP.COM> Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 187 In-Reply-To: cunniff@hpfcso.HP.COM's message of 15 Nov 89 23:29:32 GMT *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.