Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!husc7!hadeishi
From: hadeishi@husc7.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Posting of CSNEWS 'AMIGA' discussion, entry #189.
Message-ID: <1897@husc6.UUCP>
Date: Wed, 6-May-87 12:13:06 EDT
Article-I.D.: husc6.1897
Posted: Wed May  6 12:13:06 1987
Date-Received: Fri, 8-May-87 01:45:58 EDT
References: <44CSNEWS@MAINE> <1835@cbmvax.cbmvax.cbm.UUCP>
Sender: news@husc6.UUCP
Reply-To: hadeishi@husc7.UUCP (Mitsuharu Hadeishi)
Organization: Harvard Univ. Science Center
Lines: 23
Summary: IFF structure padding


	Carolyn's recent posting regarding astronomical FORMs
reminds me of a fact that not everyone is aware of:  a correct IFF
reader will ONLY read the amount of data specified in the Chunk
header, even if that chunk is "supposed" to have more data in it.
Thus, an IFF writer can write just the first few fields of a
structure, and as long as the Chunk header is written with the
right length, the reader should read the first few fields.  For
example, DPaint saves brushes without saving the entire BMHD
chunk; just the fields relevant to a brush.  Thus, if you are
planning to use your FORM and the various data chunks defined
in the FORM for various purposes of different levels of complexity,
you should place the data in your FORM design that is to be used
most generally and most often near the top of your structure, and
the more esoteric and less-used data toward the bottom.  I.e.,
if in particular you have two uses, on which requires less data
than the other, you should place all the data for one use at the
top, and add extra data near the bottom.  A similar effect can be
had with multiple Chunk definitions, but this is an easy and
simple way to design flexibility without cluttering up your FORM's
data chunk design.

					-Mitsu