Path: utzoo!attcan!uunet!cs.utexas.edu!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!tank!ncar!noao!stsci!berry
From: berry@stsci.EDU (Jim Berry)
Newsgroups: comp.sys.amiga.tech
Subject: Re: DeluxePaint III and IFF
Message-ID: <634@stsci.edu>
Date: 23 Jun 89 18:37:24 GMT
References: <111101@sun.Eng.Sun.COM>
Distribution: na
Organization: Space Telescope Science Institute, Baltimore, MD 21218
Lines: 29

From article <111101@sun.Eng.Sun.COM>, by raz%kilowatt@Sun.COM (Steve -Raz- Berry):
> In article <10102@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes:
:>> EA decided in it's infinite wisdom, and to my chargin, to allow
:>> chunks of odd sizes. This screwed up my primitive IFF parsing so that
:>> iff2sun would probably only work half of the time (yech).

:>No!  Someone tell me this isn't true.  First, someone verify that
:>Dpaint III does generate BROKEN IFF files in this manner.  Second,
:>where and when was the standard `revised'?  I think this is a bug in
:>Dpaint III if they are really doing this, and I will be seriously
:>pissed if they've made this change . . .

:  But does this mean that the IFF format is broken? I didn't think so.
: I though that IFF chunks were allowed to be of any length, it just so
: happened that everybody wrote ILBMs with chunks of an even size, so I
: didn't notice the problem until I got a bug report (and code fix).

No, chunks ARE allowed to have odd sizes, but if they do, there must
be a pad byte at the end.  Note that this is NOT the same as requiring
even chunk sizes (the pad byte is not part of the chunk)

To tell you the truth, though, I've always assumed that chunks were
even-sized too.

-- 
------------------------------------------------------------------------------
Jim Berry                         | UUCP:{arizona,decvax,hao}!noao!stsci!berry
Space Telescope Science Institute | ARPA:   berry@stsci.edu
Baltimore, Md. 21218              | SPAM:   SCIVAX::BERRY, KEPLER::BERRY