2 "EA IFF 85" Standard for Interchange Format Files
4 Document Date: January 14, 1985
5 From: Jerry Morrison, Electronic Arts
6 Status of Standard: Released and in use
10 Standards are Good for Software Developers
12 As home computer hardware evolves to better and better media machines,
13 the demand increases for higher quality, more detailed data. Data
14 development gets more expensive, requires more expertise and better
15 tools, and has to be shared across projects. Think about several ports
16 of a product on one CD-ROM with 500M Bytes of common data!
18 Development tools need standard interchange file formats. Imagine
19 scanning in images of "player" shapes, moving them to a paint program
20 for editing, then incorporating them into a game. Or writing a theme
21 song with a Macintosh score editor and incorporating it into an Amiga
22 game. The data must at times be transformed, clipped, filled out,
23 and moved across machine kinds. Media projects will depend on data
24 transfer from graphic, music, sound effect, animation, and script
27 Standards are Good for Software Users
29 Customers should be able to move their own data between independently
30 developed software products. And they should be able to buy data libraries
31 usable across many such products. The types of data objects to exchange
32 are open-ended and include plain and formatted text, raster and structured
33 graphics, fonts, music, sound effects, musical instrument descriptions,
36 The problem with expedient file formats typically memory dumps is
37 that they're too provincial. By designing data for one particular
38 use (e.g. a screen snapshot), they preclude future expansion (would
39 you like a full page picture? a multi-page document?). In neglecting
40 the possibility that other programs might read their data, they fail
41 to save contextual information (how many bit planes? what resolution?).
42 Ignoring that other programs might create such files, they're intolerant
43 of extra data (texture palette for a picture editor), missing data
44 (no color map), or minor variations (smaller image). In practice,
45 a filed representation should rarely mirror an in-memory representation.
46 The former should be designed for longevity; the latter to optimize
47 the manipulations of a particular program. The same filed data will
48 be read into different memory formats by different programs.
50 The IFF philosophy: "A little behind-the-scenes conversion when programs
51 read and write files is far better than NxM explicit conversion utilities
52 for highly specialized formats."
54 So we need some standardization for data interchange among development
55 tools and products. The more developers that adopt a standard, the
56 better for all of us and our customers.
60 Here is our offering: Electronic Arts' IFF standard for Interchange
61 File Format. The full name is "EA IFF 1985". Alternatives and justifications
62 are included for certain choices. Public domain subroutine packages
63 and utility programs are available to make it easy to write and use
64 IFF-compatible programs.
66 Part 1 introduces the standard. Part 2 presents its requirements and
67 background. Parts 3, 4, and 5 define the primitive data types, FORMs,
68 and LISTs, respectively, and how to define new high level types. Part
69 6 specifies the top level file structure. Appendix A is included for
70 quick reference and Appendix B names the committee responsible for
75 American National Standard Additional Control Codes for Use with ASCII,
76 ANSI standard 3.64-1979 for an 8-bit character set. See also ISO standard
77 2022 and ISO/DIS standard 6429.2.
79 Amiga[tm] is a trademark of Commodore-Amiga, Inc.
81 C, A Reference Manual, Samuel P. Harbison and Guy L. Steele Jr., Tartan
82 Laboratories. Prentice-Hall, Englewood Cliffs, NJ, 1984.
84 Compiler Construction, An Advanced Course, edited by F. L. Bauer and
85 J. Eickel (Springer-Verlag, 1976). This book is one of many sources
86 for information on recursive descent parsing.
88 DIF Technical Specification (c)1981 by Software Arts, Inc. DIF[tm] is
89 the format for spreadsheet data interchange developed by Software
91 DIF[tm] is a trademark of Software Arts, Inc.
93 Electronic Arts[tm] is a trademark of Electronic Arts.
95 "FTXT" IFF Formatted Text, from Electronic Arts. IFF supplement document
98 Inside Macintosh (c) 1982, 1983, 1984, 1985 Apple Computer, Inc., a
99 programmer's reference manual.
100 Apple(R) is a trademark of Apple Computer, Inc.
101 Macintosh[tm] is a trademark licensed to Apple Computer, Inc.
103 "ILBM" IFF Interleaved Bitmap, from Electronic Arts. IFF supplement
104 document for a raster image format.
106 M68000 16/32-Bit Microprocessor Programmer's Reference Manual(c) 1984,
107 1982, 1980, 1979 by Motorola, Inc.
109 PostScript Language Manual (c) 1984 Adobe Systems Incorporated.
110 PostScript[tm] is a trademark of Adobe Systems, Inc.
111 Times and Helvetica(R) are trademarks of Allied Corporation.
113 InterScript: A Proposal for a Standard for the Interchange of Editable
114 Documents (c)1984 Xerox Corporation.
115 Introduction to InterScript (c) 1985 Xerox Corporation.
119 2. Background for Designers
121 Part 2 is about the background, requirements, and goals for the standard.
122 It's geared for people who want to design new types of IFF objects.
123 People just interested in using the standard may wish to skip this
128 A standard should be long on prescription and short on overhead. It
129 should give lots of rules for designing programs and data files for
130 synergy. But neither the programs nor the files should cost too much
131 more than the expedient variety. While we're looking to a future with
132 CD-ROMs and perpendicular recording, the standard must work well on
135 For program portability, simplicity, and efficiency, formats should
136 be designed with more than one implementation style in mind. (In practice,
137 pure stream I/O is adequate although random access makes it easier
138 to write files.) It ought to be possible to read one of many objects
139 in a file without scanning all the preceding data. Some programs need
140 to read and play out their data in real time, so we need good compromises
141 between generality and efficiency.
143 As much as we need standards, they can't hold up product schedules.
144 So we also need a kind of decentralized extensibility where any software
145 developer can define and refine new object types without some "standards
146 authority" in the loop. Developers must be able to extend existing
147 formats in a forward- and backward-compatible way. A central repository
148 for design information and example programs can help us take full
149 advantage of the standard.
151 For convenience, data formats should heed the restrictions of various
152 processors and environments. E.g. word-alignment greatly helps 68000
153 access at insignificant cost to 8088 programs.
155 Other goals include the ability to share common elements over a list
156 of objects and the ability to construct composite objects containing
157 other data objects with structural information like directories.
159 And finally, "Simple things should be simple and complex things should
160 be possible." Alan Kay.
164 Let's think ahead and build programs that read and write files for
165 each other and for programs yet to be designed. Build data formats
166 to last for future computers so long as the overhead is acceptable.
167 This extends the usefulness and life of today's programs and data.
169 To maximize interconnectivity, the standard file structure and the
170 specific object formats must all be general and extensible. Think
171 ahead when designing an object. It should serve many purposes and
172 allow many programs to store and read back all the information they
173 need; even squeeze in custom data. Then a programmer can store the
174 available data and is encouraged to include fixed contextual details.
175 Recipient programs can read the needed parts, skip unrecognized stuff,
176 default missing data, and use the stored context to help transform
181 IFF addresses these needs by defining a standard file structure, some
182 initial data object types, ways to define new types, and rules for
183 accessing these files. We can accomplish a great deal by writing programs
184 according to this standard, but don't expect direct compatibility
185 with existing software. We'll need conversion programs to bridge the
186 gap from the old world.
188 IFF is geared for computers that readily process information in 8-bit
189 bytes. It assumes a "physical layer" of data storage and transmission
190 that reliably maintains "files" as strings of 8-bit bytes. The standard
191 treats a "file" as a container of data bytes and is independent of
192 how to find a file and whether it has a byte count.
194 This standard does not by itself implement a clipboard for cutting
195 and pasting data between programs. A clipboard needs software to mediate
196 access, to maintain a "contents version number" so programs can detect
197 updates, and to manage the data in "virtual memory".
201 The basic problem is how to represent information in a way that's
202 program-independent, compiler- independent, machine-independent, and
205 The computer science approach is "data abstraction", also known as
206 "objects", "actors", and "abstract data types". A data abstraction
207 has a "concrete representation" (its storage format), an "abstract
208 representation" (its capabilities and uses), and access procedures
209 that isolate all the calling software from the concrete representation.
210 Only the access procedures touch the data storage. Hiding mutable
211 details behind an interface is called "information hiding". What data
212 abstraction does is abstract from details of implementing the object,
213 namely the selected storage representation and algorithms for manipulating
216 The power of this approach is modularity. By adjusting the access
217 procedures we can extend and restructure the data without impacting
218 the interface or its callers. Conversely, we can extend and restructure
219 the interface and callers without making existing data obsolete. It's
220 great for interchange!
222 But we seem to need the opposite: fixed file formats for all programs
223 to access. Actually, we could file data abstractions ("filed objects")
224 by storing the data and access procedures together. We'd have to encode
225 the access procedures in a standard machine-independent programming
226 language la PostScript. Even still, the interface can't evolve freely
227 since we can't update all copies of the access procedures. So we'll
228 have to design our abstract representations for limited evolution
229 and occasional revolution (conversion).
231 In any case, today's microcomputers can't practically store data abstractions.
232 They can do the next best thing: store arbitrary types of data in
233 "data chunks", each with a type identifier and a length count. The
234 type identifier is a reference by name to the access procedures (any
235 local implementation). The length count enables storage-level object
236 operations like "copy" and "skip to next" independent of object type.
238 Chunk writing is straightforward. Chunk reading requires a trivial
239 parser to scan each chunk and dispatch to the proper access/conversion
240 procedure. Reading chunks nested inside other chunks requires recursion,
241 but no lookahead or backup.
243 That's the main idea of IFF. There are, of course, a few other detailsI
247 Where our needs are similar, we borrow from existing standards.
249 Our basic need to move data between independently developed programs
250 is similar to that addressed by the Apple Macintosh desk scrap or
251 "clipboard" [Inside Macintosh chapter "Scrap Manager"]. The Scrap
252 Manager works closely with the Resource Manager, a handy filer and
253 swapper for data objects (text strings, dialog window templates, pictures,
254 fontsI) including types yet to be designed [Inside Macintosh chapter
255 "Resource Manager"]. The Resource Manager is a kin to Smalltalk's
258 We will probably write a Macintosh desk accessory that converts IFF
259 files to and from the Macintosh clipboard for quick and easy interchange
260 with programs like MacPaint and Resource Mover.
262 Macintosh uses a simple and elegant scheme of 4-character "identifiers"
263 to identify resource types, clipboard format types, file types, and
264 file creator programs. Alternatives are unique ID numbers assigned
265 by a central authority or by hierarchical authorities, unique ID numbers
266 generated by algorithm, other fixed length character strings, and
267 variable length strings. Character string identifiers double as readable
268 signposts in data files and programs. The choice of 4 characters is
269 a good tradeoff between storage space, fetch/compare/store time, and
270 name space size. We'll honor Apple's designers by adopting this scheme.
272 "PICT" is a good example of a standard structured graphics format
273 (including raster images) and its many uses [Inside Macintosh chapter
274 "QuickDraw"]. Macintosh provides QuickDraw routines in ROM to create,
275 manipulate, and display PICTs. Any application can create a PICT by
276 simply asking QuickDraw to record a sequence of drawing commands.
277 Since it's just as easy to ask QuickDraw to render a PICT to a screen
278 or a printer, it's very effective to pass them between programs, say
279 from an illustrator to a word processor. An important feature is the
280 ability to store "comments" in a PICT which QuickDraw will ignore.
281 Actually, it passes them to your optional custom "comment handler".
283 PostScript, Adobe's print file standard, is a more general way to
284 represent any print image (which is a specification for putting marks
285 on paper) [PostScript Language Manual]. In fact, PostScript is a full-fledged
286 programming language. To interpret a PostScript program is to render
287 a document on a raster output device. The language is defined in layers:
288 a lexical layer of identifiers, constants, and operators; a layer
289 of reverse polish semantics including scope rules and a way to define
290 new subroutines; and a printing-specific layer of built-in identifiers
291 and operators for rendering graphic images. It is clearly a powerful
292 (Turing equivalent) image definition language. PICT and a subset of
293 PostScript are candidates for structured graphics standards.
295 A PostScript document can be printed on any raster output device (including
296 a display) but cannot generally be edited. That's because the original
297 flexibility and constraints have been discarded. Besides, a PostScript
298 program may use arbitrary computation to supply parameters like placement
299 and size to each operator. A QuickDraw PICT, in comparison, is a more
300 restricted format of graphic primitives parameterized by constants.
301 So a PICT can be edited at the level of the primitives, e.g. move
302 or thicken a line. It cannot be edited at the higher level of, say,
303 the bar chart data which generated the picture.
305 PostScript has another limitation: Not all kinds of data amount to
306 marks on paper. A musical instrument description is one example. PostScript
307 is just not geared for such uses.
309 "DIF" is another example of data being stored in a general format
310 usable by future programs [DIF Technical Specification]. DIF is a
311 format for spreadsheet data interchange. DIF and PostScript are both
312 expressed in plain ASCII text files. This is very handy for printing,
313 debugging, experimenting, and transmitting across modems. It can have
314 substantial cost in compaction and read/write work, depending on use.
315 We won't store IFF files this way but we could define an ASCII alternate
316 representation with a converter program.
318 InterScript is Xerox' standard for interchange of editable documents
319 [Introduction to InterScript]. It approaches a harder problem: How
320 to represent editable word processor documents that may contain formatted
321 text, pictures, cross-references like figure numbers, and even highly
322 specialized objects like mathematical equations? InterScript aims
323 to define one standard representation for each kind of information.
324 Each InterScript-compatible editor is supposed to preserve the objects
325 it doesn't understand and even maintain nested cross-references. So
326 a simple word processor would let you edit the text of a fancy document
327 without discarding the equations or disrupting the equation numbers.
329 Our task is similarly to store high level information and preserve
330 as much content as practical while moving it between programs. But
331 we need to span a larger universe of data types and cannot expect
332 to centrally define them all. Fortunately, we don't need to make programs
333 preserve information that they don't understand. And for better or
334 worse, we don't have to tackle general-purpose cross-references yet.
338 3. Primitive Data Types
340 Atomic components such as integers and characters that are interpretable
341 directly by the CPU are specified in one format for all processors.
342 We chose a format that's most convenient for the Motorola MC68000
343 processor [M68000 16/32-Bit Microprocessor Programmer's Reference
346 N.B.: Part 3 dictates the format for "primitive" data types where and
347 only where used in the overall file structure and standard kinds of
348 chunks (Cf. Chunks). The number of such occurrences will be small
349 enough that the costs of conversion, storage, and management of processor-
350 specific files would far exceed the costs of conversion during I/O by "foreign"
351 programs. A particular data chunk may be specified with a different
352 format for its internal primitive types or with processor- or environment-
353 speci fic variants if necessary to optimize local usage. Since that hurts
354 data interchange, it's not recommended. (Cf. Designing New Data Sections,
359 All data objects larger than a byte are aligned on even byte addresses
360 relative to the start of the file. This may require padding. Pad bytes
361 are to be written as zeros, but don't count on that when reading.
363 This means that every odd-length "chunk" (see below) must be padded
364 so that the next one will fall on an even boundary. Also, designers
365 of structures to be stored in chunks should include pad fields where
366 needed to align every field larger than a byte. Zeros should be stored
367 in all the pad bytes.
369 Justification: Even-alignment causes a little extra work for files
370 that are used only on certain processors but allows 68000 programs
371 to construct and scan the data in memory and do block I/O. You just
372 add an occasional pad field to data structures that you're going to
373 block read/write or else stream read/write an extra byte. And the
374 same source code works on all processors. Unspecified alignment, on
375 the other hand, would force 68000 programs to (dis)assemble word and
376 long-word data one byte at a time. Pretty cumbersome in a high level
377 language. And if you don't conditionally compile that out for other
378 processors, you won't gain anything.
382 Numeric types supported are two's complement binary integers in the
383 format used by the MC68000 processor high byte first, high word first the
384 reverse of 8088 and 6502 format. They could potentially include signed
385 and unsigned 8, 16, and 32 bit integers but the standard only uses
388 UBYTE 8 bits unsigned
390 UWORD 16 bits unsigned
393 The actual type definitions depend on the CPU and the compiler. In
394 this document, we'll express data type definitions in the C programming
395 language. [See C, A Reference Manual.] In 68000 Lattice C:
397 typedef unsigned char UBYTE; /* 8 bits unsigned */
398 typedef short WORD; /* 16 bits signed */
399 typedef unsigned short UWORD; /* 16 bits unsigned */
400 typedef long LONG; /* 32 bits signed */
404 The following character set is assumed wherever characters are used,
405 e.g. in text strings, IDs, and TEXT chunks (see below).
407 Characters are encoded in 8-bit ASCII. Characters in the range NUL
408 (hex 0) through DEL (hex 7F) are well defined by the 7-bit ASCII standard.
409 IFF uses the graphic group RJS (SP, hex 20) through R~S (hex 7E).
411 Most of the control character group hex 01 through hex 1F have no
412 standard meaning in IFF. The control character LF (hex 0A) is defined
413 as a "newline" character. It denotes an intentional line break, that
414 is, a paragraph or line terminator. (There is no way to store an automatic
415 line break. That is strictly a function of the margins in the environment
416 the text is placed.) The control character ESC (hex 1B) is a reserved
417 escape character under the rules of ANSI standard 3.64-1979 American
418 National Standard Additional Control Codes for Use with ASCII, ISO
419 standard 2022, and ISO/DIS standard 6429.2.
421 Characters in the range hex 7F through hex FF are not globally defined
422 in IFF. They are best left reserved for future standardization. But
423 note that the FORM type FTXT (formatted text) defines the meaning
424 of these characters within FTXT forms. In particular, character values
425 hex 7F through hex 9F are control codes while characters hex A0 through
426 hex FF are extended graphic characters like , as per the ISO and
427 ANSI standards cited above. [See the supplementary document "FTXT"
432 A "creation date" is defined as the date and time a stream of data
433 bytes was created. (Some systems call this a "last modified date".)
434 Editing some data changes its creation date. Moving the data between
435 volumes or machines does not.
437 The IFF standard date format will be one of those used in MS-DOS,
438 Macintosh, or Amiga DOS (probably a 32-bit unsigned number of seconds
439 since a reference point). Issue: Investigate these three.
443 A "type ID", "property name", "FORM type", or any other IFF identifier
444 is a 32-bit value: the concatenation of four ASCII characters in the
445 range R S (SP, hex 20) through R~S (hex 7E). Spaces (hex 20) should
446 not precede printing characters; trailing spaces are ok. Control characters
451 IDs are compared using a simple 32-bit case-dependent equality test.
453 Data section type IDs (aka FORM types) are restriced IDs. (Cf. Data
454 Sections.) Since they may be stored in filename extensions (Cf. Single
455 Purpose Files) lower case letters and punctuation marks are forbidden.
456 Trailing spaces are ok.
458 Carefully choose those four characters when you pick a new ID. Make
459 them mnemonic so programmers can look at an interchange format file
460 and figure out what kind of data it contains. The name space makes
461 it possible for developers scattered around the globe to generate
462 ID values with minimal collisions so long as they choose specific
463 names like "MUS4" instead of general ones like "TYPE" and "FILE".
464 EA will "register" new FORM type IDs and format descriptions as they're
465 devised, but collisions will be improbable so there will be no pressure
466 on this "clearinghouse" process. Appendix A has a list of currently
469 Sometimes it's necessary to make data format changes that aren't backward
470 compatible. Since IDs are used to denote data formats in IFF, new
471 IDs are chosen to denote revised formats. Since programs won't read
472 chunks whose IDs they don't recognize (see Chunks, below), the new
473 IDs keep old programs from stumbling over new data. The conventional
474 way to chose a "revision" ID is to increment the last character if
475 it's a digit or else change the last character to a digit. E.g. first
476 and second revisions of the ID "XY" would be "XY1" and "XY2". Revisions
477 of "CMAP" would be "CMA1" and "CMA2".
481 Chunks are the building blocks in the IFF structure. The form expressed
486 LONG ckSize; /* sizeof(ckData) */
487 UBYTE ckData[/* ckSize */];
490 We can diagram an example chunk a "CMAP" chunk containing 12 data
495 ckData: | 0, 0, 0, 32 | --------
496 | 0, 0, 64, 0 | 12 bytes
497 | 0, 0, 64, 0 | ---------
500 The fixed header part means "Here's a type ckID chunk with ckSize
503 The ckID identifies the format and purpose of the chunk. As a rule,
504 a program must recognize ckID to interpret ckData. It should skip
505 over all unrecognized chunks. The ckID also serves as a format version
506 number as long as we pick new IDs to identify new formats of ckData
509 The following ckIDs are universally reserved to identify chunks with
510 particular IFF meanings: "LIST", "FORM", "PROP", "CAT ", and "
511 ". The special ID " " (4 spaces) is a ckID for "filler" chunks,
512 that is, chunks that fill space but have no meaningful contents. The
513 IDs "LIS1" through "LIS9", "FOR1" through "FOR9", and "CAT1" through
514 "CAT9" are reserved for future "version number" variations. All IFF-compatible
515 software must account for these 23 chunk IDs. Appendix A has a list
518 The ckSize is a logical block size how many data bytes are in ckData.
519 If ckData is an odd number of bytes long, a 0 pad byte follows which
520 is not included in ckSize. (Cf. Alignment.) A chunk's total physical
521 size is ckSize rounded up to an even number plus the size of the header.
522 So the smallest chunk is 8 bytes long with ckSize = 0. For the sake
523 of following chunks, programs must respect every chunk's ckSize as
524 a virtual end-of-file for reading its ckData even if that data is
525 malformed, e.g. if nested contents are truncated.
527 We can describe the syntax of a chunk as a regular expression with
528 "#" representing the ckSize, i.e. the length of the following {braced}
529 bytes. The "[0]" represents a sometimes needed pad byte. (The regular
530 expressions in this document are collected in Appendix A along with
531 an explanation of notation.)
533 Chunk ::= ID #{ UBYTE* } [0]
535 One chunk output technique is to stream write a chunk header, stream
536 write the chunk contents, then random access back to the header to
537 fill in the size. Another technique is to make a preliminary pass
538 over the data to compute the size, then write it out all at once.
540 Strings, String Chunks, and String Properties
542 In a string of ASCII text, LF denotes a forced line break (paragraph
543 or line terminator). Other control characters are not used. (Cf. Characters.)
545 The ckID for a chunk that contains a string of plain, unformatted
546 text is "TEXT". As a practical matter, a text string should probably
547 not be longer than 32767 bytes. The standard allows up to 231 - 1
550 When used as a data property (see below), a text string chunk may
551 be 0 to 255 characters long. Such a string is readily converted to
552 a C string or a Pascal STRING[255]. The ckID of a property must be
553 the property name, not "TEXT".
555 When used as a part of a chunk or data property, restricted C string
556 format is normally used. That means 0 to 255 characters followed by
557 a NUL byte (ASCII value 0).
561 Data properties specify attributes for following (non-property) chunks.
562 A data property essentially says "identifier = value", for example
563 "XY = (10, 200)", telling something about following chunks. Properties
564 may only appear inside data sections ("FORM" chunks, cf. Data Sections)
565 and property sections ("PROP" chunks, cf. Group PROP).
567 The form of a data property is a special case of Chunk. The ckID is
568 a property name as well as a property type. The ckSize should be small
569 since data properties are intended to be accumulated in RAM when reading
570 a file. (256 bytes is a reasonable upper bound.) Syntactically:
574 When designing a data object, use properties to describe context information
575 like the size of an image, even if they don't vary in your program.
576 Other programs will need this information.
578 Think of property settings as assignments to variables in a programming
579 language. Multiple assignments are redundant and local assignments
580 temporarily override global assignments. The order of assignments
581 doesn't matter as long as they precede the affected chunks. (Cf. LISTs,
582 CATs, and Shared Properties.)
584 Each object type (FORM type) is a local name space for property IDs.
585 Think of a "CMAP" property in a "FORM ILBM" as the qualified ID "ILBM.CMAP".
586 Property IDs specified when an object type is designed (and therefore
587 known to all clients) are called "standard" while specialized ones
588 added later are "nonstandard".
592 Issue: A standard mechanism for "links" or "cross references" is very
593 desirable for things like combining images and sounds into animations.
594 Perhaps we'll define "link" chunks within FORMs that refer to other
595 FORMs or to specific chunks within the same and other FORMs. This
596 needs further work. EA IFF 1985 has no standard link mechanism.
598 For now, it may suffice to read a list of, say, musical instruments,
599 and then just refer to them within a musical score by index number.
603 Issue: We may need a standard form for references to other files.
604 A "file ref" could name a directory and a file in the same type of
605 operating system as the ref's originator. Following the reference
606 would expect the file to be on some mounted volume. In a network environment,
607 a file ref could name a server, too.
609 Issue: How can we express operating-system independent file refs?
611 Issue: What about a means to reference a portion of another file?
612 Would this be a "file ref" plus a reference to a "link" within the
619 The first thing we need of a file is to check: Does it contain IFF
620 data and, if so, does it contain the kind of data we're looking for?
621 So we come to the notion of a "data section".
623 A "data section" or IFF "FORM" is one self-contained "data object"
624 that might be stored in a file by itself. It is one high level data
625 object such as a picture or a sound effect. The IFF structure "FORM"
626 makes it self- identifying. It could be a composite object like a
627 musical score with nested musical instrument descriptions.
631 A data section is a chunk with ckID "FORM" and this arrangement:
633 FORM ::= "FORM" #{ FormType (LocalChunk | FORM | LIST | CAT)*
636 LocalChunk ::= Property | Chunk
638 The ID "FORM" is a syntactic keyword like "struct" in C. Think of
639 a "struct ILBM" containing a field "CMAP". If you see "FORM" you'll
640 know to expect a FORM type ID (the structure name, "ILBM" in this
641 example) and a particular contents arrangement or "syntax" (local
642 chunks, FORMs, LISTs, and CATs). (LISTs and CATs are discussed in
643 part 5, below.) A "FORM ILBM", in particular, might contain a local
644 chunk "CMAP", an "ILBM.CMAP" (to use a qualified name).
646 So the chunk ID "FORM" indicates a data section. It implies that the
647 chunk contains an ID and some number of nested chunks. In reading
648 a FORM, like any other chunk, programs must respect its ckSize as
649 a virtual end-of-file for reading its contents, even if they're truncated.
651 The FormType (or FORM type) is a restricted ID that may not contain
652 lower case letters or punctuation characters. (Cf. Type IDs. Cf. Single
655 The type-specific information in a FORM is composed of its "local
656 chunks": data properties and other chunks. Each FORM type is a local
657 name space for local chunk IDs. So "CMAP" local chunks in other FORM
658 types may be unrelated to "ILBM.CMAP". More than that, each FORM type
659 defines semantic scope. If you know what a FORM ILBM is, you'll know
660 what an ILBM.CMAP is.
662 Local chunks defined when the FORM type is designed (and therefore
663 known to all clients of this type) are called "standard" while specialized
664 ones added later are "nonstandard".
666 Among the local chunks, property chunks give settings for various
667 details like text font while the other chunks supply the essential
668 information. This distinction is not clear cut. A property setting
669 cancelled by a later setting of the same property has effect only
670 on data chunks in between. E.g. in the sequence:
672 prop1 = x (propN = value)* prop1 = y
674 where the propNs are not prop1, the setting prop1 = x has no effect.
676 The following universal chunk IDs are reserved inside any FORM: "LIST",
677 "FORM", "PROP", "CAT ", "JJJJ", "LIS1" through "LIS9", "FOR1" through
678 "FOR9", and "CAT1" through "CAT9". (Cf. Chunks. Cf. Group LIST. Cf.
679 Group PROP.) For clarity, these universal chunk names may not be FORM
682 Part 5, below, talks about grouping FORMs into LISTs and CATs. They
683 let you group a bunch of FORMs but don't impose any particular meaning
684 or constraints on the grouping. Read on.
688 A FORM chunk inside a FORM is a full-fledged data section. This means
689 you can build a composite object like a multi-frame animation sequence
690 from available picture FORMs and sound effect FORMs. You can insert
691 additional chunks with information like frame rate and frame count.
693 Using composite FORMs, you leverage on existing programs that create
694 and edit the component FORMs. Those editors may even look into your
695 composite object to copy out its type of component, although it'll
696 be the rare program that's fancy enough to do that. Such editors are
697 not allowed to replace their component objects within your composite
698 object. That's because the IFF standard lets you specify consistency
699 requirements for the composite FORM such as maintaining a count or
700 a directory of the components. Only programs that are written to uphold
701 the rules of your FORM type should create or modify such FORMs.
703 Therefore, in designing a program that creates composite objects,
704 you are strongly requested to provide a facility for your users to
705 import and export the nested FORMs. Import and export could move the
706 data through a clipboard or a file.
708 Here are several existing FORM types and rules for defining new ones.
712 An FTXT data section contains text with character formatting information
713 like fonts and faces. It has no paragraph or document formatting information
714 like margins and page headers. FORM FTXT is well matched to the text
715 representation in Amiga's Intuition environment. See the supplemental
716 document "FTXT" IFF Formatted Text.
720 "ILBM" is an InterLeaved BitMap image with color map; a machine-independent
721 format for raster images. FORM ILBM is the standard image file format
722 for the Commodore-Amiga computer and is useful in other environments,
723 too. See the supplemental document "ILBM" IFF Interleaved Bitmap.
727 The data chunk inside a "PICS" data section has ID "PICT" and holds
728 a QuickDraw picture. Issue: Allow more than one PICT in a PICS? See
729 Inside Macintosh chapter "QuickDraw" for details on PICTs and how
730 to create and display them on the Macintosh computer.
732 The only standard property for PICS is "XY", an optional property
733 that indicates the position of the PICT relative to "the big picture".
734 The contents of an XY is a QuickDraw Point.
736 Note: PICT may be limited to Macintosh use, in which case there'll
737 be another format for structured graphics in other environments.
739 Other Macintosh Resource Types
741 Some other Macintosh resource types could be adopted for use within
742 IFF files; perhaps MWRT, ICN, ICN#, and STR#.
744 Issue: Consider the candidates and reserve some more IDs.
746 Designing New Data Sections
748 Supplemental documents will define additional object types. A supplement
749 needs to specify the object's purpose, its FORM type ID, the IDs and
750 formats of standard local chunks, and rules for generating and interpreting
751 the data. It's a good idea to supply typedefs and an example source
752 program that accesses the new object. See "ILBM" IFF Interleaved Bitmap
755 Anyone can pick a new FORM type ID but should reserve it with Electronic
756 Arts at their earliest convenience. [Issue: EA contact person? Hand
757 this off to another organization?] While decentralized format definitions
758 and extensions are possible in IFF, our preference is to get design
759 consensus by committee, implement a program to read and write it,
760 perhaps tune the format, and then publish the format with example
761 code. Some organization should remain in charge of answering questions
762 and coordinating extensions to the format.
764 If it becomes necessary to revise the design of some data section,
765 its FORM type ID will serve as a version number (Cf. Type IDs). E.g.
766 a revised "VDEO" data section could be called "VDE1". But try to get
767 by with compatible revisions within the existing FORM type.
769 In a new FORM type, the rules for primitive data types and word-alignment
770 (Cf. Primitive Data Types) may be overriden for the contents of its
771 local chunks but not for the chunk structure itself if your documentation
772 spells out the deviations. If machine-specific type variants are needed,
773 e.g. to store vast numbers of integers in reverse bit order, then
774 outline the conversion algorithm and indicate the variant inside each
775 file, perhaps via different FORM types. Needless to say, variations
778 In designing a FORM type, encapsulate all the data that other programs
779 will need to interpret your files. E.g. a raster graphics image should
780 specify the image size even if your program always uses 320 x 200
781 pixels x 3 bitplanes. Receiving programs are then empowered to append
782 or clip the image rectangle, to add or drop bitplanes, etc. This enables
783 a lot more compatibility.
785 Separate the central data (like musical notes) from more specialized
786 information (like note beams) so simpler programs can extract the
787 central parts during read-in. Leave room for expansion so other programs
788 can squeeze in new kinds of information (like lyrics). And remember
789 to keep the property chunks manageably short let's say 2 256 bytes.
791 When designing a data object, try to strike a good tradeoff between
792 a super-general format and a highly-specialized one. Fit the details
793 to at least one particular need, for example a raster image might
794 as well store pixels in the current machine's scan order. But add
795 the kind of generality that makes it usable with foreseeable hardware
796 and software. E.g. use a whole byte for each red, green, and blue
797 color value even if this year's computer has only 4-bit video DACs.
798 Think ahead and help other programs so long as the overhead is acceptable.
799 E.g. run compress a raster by scan line rather than as a unit so future
800 programs can swap images by scan line to and from secondary storage.
802 Try to design a general purpose "least common multiple" format that
803 encompasses the needs of many programs without getting too complicated.
804 Let's coalesce our uses around a few such formats widely separated
805 in the vast design space. Two factors make this flexibility and simplicity
806 practical. First, file storage space is getting very plentiful, so
807 compaction is not a priority. Second, nearly any locally-performed
808 data conversion work during file reading and writing will be cheap
809 compared to the I/O time.
811 It must be ok to copy a LIST or FORM or CAT intact, e.g. to incorporate
812 it into a composite FORM. So any kind of internal references within
813 a FORM must be relative references. They could be relative to the
814 start of the containing FORM, relative from the referencing chunk,
815 or a sequence number into a collection.
817 With composite FORMs, you leverage on existing programs that create
818 and edit the components. If you write a program that creates composite
819 objects, please provide a facility for your users to import and export
820 the nested FORMs. The import and export functions may move data through
821 a separate file or a clipboard.
823 Finally, don't forget to specify all implied rules in detail.
827 5. LISTs, CATs, and Shared Properties
829 Data often needs to be grouped together like a list of icons. Sometimes
830 a trick like arranging little images into a big raster works, but
831 generally they'll need to be structured as a first class group. The
832 objects "LIST" and "CAT" are IFF-universal mechanisms for this purpose.
834 Property settings sometimes need to be shared over a list of similar
835 objects. E.g. a list of icons may share one color map. LIST provides
836 a means called "PROP" to do this. One purpose of a LIST is to define
837 the scope of a PROP. A "CAT", on the other hand, is simply a concatenation
840 Simpler programs may skip LISTs and PROPs altogether and just handle
841 FORMs and CATs. All "fully-conforming" IFF programs also know about
842 "CAT ", "LIST", and "PROP". Any program that reads a FORM inside a
843 LIST must process shared PROPs to correctly interpret that FORM.
847 A CAT is just an untyped group of data objects.
849 Structurally, a CAT is a chunk with chunk ID "CAT " containing a "contents
850 type" ID followed by the nested objects. The ckSize of each contained
851 chunk is essentially a relative pointer to the next one.
853 CAT ::= "CAT " #{ ContentsType (FORM | LIST | CAT)* }
854 ContentsType ::= ID -- a hint or an "abstract data type" ID
856 In reading a CAT, like any other chunk, programs must respect it's
857 ckSize as a virtual end-of-file for reading the nested objects even
858 if they're malformed or truncated.
860 The "contents type" following the CAT's ckSize indicates what kind
861 of FORMs are inside. So a CAT of ILBMs would store "ILBM" there. It's
862 just a hint. It may be used to store an "abstract data type". A CAT
863 could just have blank contents ID ("JJJJ") if it contains more than
866 CAT defines only the format of the group. The group's meaning is open
867 to interpretation. This is like a list in LISP: the structure of cells
868 is predefined but the meaning of the contents as, say, an association
869 list depends on use. If you need a group with an enforced meaning
870 (an "abstract data type" or Smalltalk "subclass"), some consistency
871 constraints, or additional data chunks, use a composite FORM instead
872 (Cf. Composite FORMs).
874 Since a CAT just means a concatenation of objects, CATs are rarely
875 nested. Programs should really merge CATs rather than nest them.
879 A LIST defines a group very much like CAT but it also gives a scope
880 for PROPs (see below). And unlike CATs, LISTs should not be merged
881 without understanding their contents.
883 Structurally, a LIST is a chunk with ckID "LIST" containing a "contents
884 type" ID, optional shared properties, and the nested contents (FORMs,
885 LISTs, and CATs), in that order. The ckSize of each contained chunk
886 is a relative pointer to the next one. A LIST is not an arbitrary
887 linked list the cells are simply concatenated.
889 LIST ::= "LIST" #{ ContentsType PROP* (FORM | LIST | CAT)* }
894 PROP chunks may appear in LISTs (not in FORMs or CATs). They supply
895 shared properties for the FORMs in that LIST. This ability to elevate
896 some property settings to shared status for a list of forms is useful
897 for both indirection and compaction. E.g. a list of images with the
898 same size and colors can share one "size" property and one "color
899 map" property. Individual FORMs can override the shared settings.
901 The contents of a PROP is like a FORM with no data chunks:
903 PROP ::= "PROP" #{ FormType Property* }
905 It means, "Here are the shared properties for FORM type <<FormType>."
907 A LIST may have at most one PROP of a FORM type, and all the PROPs
908 must appear before any of the FORMs or nested LISTs and CATs. You
909 can have subsequences of FORMs sharing properties by making each subsequence
912 Scoping: Think of property settings as variable bindings in nested
913 blocks of a programming language. Where in C you could write:
915 TEXT_FONT text_font = Courier; /* program's global default */
918 TEXT_FONT text_font = TimesRoman; /* shared setting */
921 TEXT_FONT text_font = Helvetica; /* local setting */
922 Print("Hello "); /* uses font Helvetica */
926 Print("there."); /* uses font TimesRoman */
930 An IFF file could contain:
934 FONT {TimesRoman} /* shared setting */
938 FONT {Helvetica} /* local setting */
939 CHRS {Hello } /* uses font Helvetica */
943 CHRS {there.} /* uses font TimesRoman */
947 The shared property assignments selectively override the reader's
948 global defaults, but only for FORMs within the group. A FORM's own
949 property assignments selectively override the global and group-supplied
950 values. So when reading an IFF file, keep property settings on a stack.
951 They're designed to be small enough to hold in main memory.
953 Shared properties are semantically equivalent to copying those properties
954 into each of the nested FORMs right after their FORM type IDs.
958 Optional "properties for LIST" store the origin of the list's contents
959 in a PROP chunk for the fake FORM type "LIST". They are the properties
960 originating program "OPGM", processor family "OCPU", computer type
961 "OCMP", computer serial number or network address "OSN ", and user
962 name "UNAM". In our imperfect world, these could be called upon to
963 distinguish between unintended variations of a data format or to work
964 around bugs in particular originating/receiving program pairs. Issue:
965 Specify the format of these properties.
967 A creation date could also be stored in a property but let's ask that
968 file creating, editing, and transporting programs maintain the correct
969 date in the local file system. Programs that move files between machine
970 types are expected to copy across the creation dates.
974 6. Standard File Structure
976 File Structure Overview
978 An IFF file is just a single chunk of type FORM, LIST, or CAT. Therefore
979 an IFF file can be recognized by its first 4 bytes: "FORM", "LIST",
980 or "CAT ". Any file contents after the chunk's end are to be ignored.
982 Since an IFF file can be a group of objects, programs that read/write
983 single objects can communicate to an extent with programs that read/write
984 groups. You're encouraged to write programs that handle all the objects
985 in a LIST or CAT. A graphics editor, for example, could process a
986 list of pictures as a multiple page document, one page at a time.
988 Programs should enforce IFF's syntactic rules when reading and writing
989 files. This ensures robust data transfer. The public domain IFF reader/writer
990 subroutine package does this for you. A utility program "IFFCheck"
991 is available that scans an IFF file and checks it for conformance
992 to IFF's syntactic rules. IFFCheck also prints an outline of the chunks
993 in the file, showing the ckID and ckSize of each. This is quite handy
994 when building IFF programs. Example programs are also available to
995 show details of reading and writing IFF files.
997 A merge program "IFFJoin" will be available that logically appends
998 IFF files into a single CAT group. It "unwraps" each input file that
999 is a CAT so that the combined file isn't nested CATs.
1001 If we need to revise the IFF standard, the three anchoring IDs will
1002 be used as "version numbers". That's why IDs "FOR1" through "FOR9",
1003 "LIS1" through "LIS9", and "CAT1" through "CAT9" are reserved.
1005 IFF formats are designed for reasonable performance with floppy disks.
1006 We achieve considerable simplicity in the formats and programs by
1007 relying on the host file system rather than defining universal grouping
1008 structures like directories for LIST contents. On huge storage systems,
1009 IFF files could be leaf nodes in a file structure like a B-tree. Let's
1010 hope the host file system implements that for us!
1012 Thre are two kinds of IFF files: single purpose files and scrap files.
1013 They differ in the interpretation of multiple data objects and in
1014 the file's external type.
1016 Single Purpose Files
1018 A single purpose IFF file is for normal "document" and "archive" storage.
1019 This is in contrast with "scrap files" (see below) and temporary backing
1020 storage (non-interchange files).
1022 The external file type (or filename extension, depending on the host
1023 file system) indicates the file's contents. It's generally the FORM
1024 type of the data contained, hence the restrictions on FORM type IDs.
1026 Programmers and users may pick an "intended use" type as the filename
1027 extension to make it easy to filter for the relevant files in a filename
1028 requestor. This is actually a "subclass" or "subtype" that conveniently
1029 separates files of the same FORM type that have different uses. Programs
1030 cannot demand conformity to its expected subtypes without overly restricting
1031 data interchange since they cannot know about the subtypes to be used
1032 by future programs that users will want to exchange data with.
1034 Issue: How to generate 3-letter MS-DOS extensions from 4-letter FORM
1037 Most single purpose files will be a single FORM (perhaps a composite
1038 FORM like a musical score containing nested FORMs like musical instrument
1039 descriptions). If it's a LIST or a CAT, programs should skip over
1040 unrecognized objects to read the recognized ones or the first recognized
1041 one. Then a program that can read a single purpose file can read something
1042 out of a "scrap file", too.
1046 A "scrap file" is for maximum interconnectivity in getting data between
1047 programs; the core of a clipboard function. Scrap files may have type
1048 "IFF " or filename extension ".IFF".
1050 A scrap file is typically a CAT containing alternate representations
1051 of the same basic information. Include as many alternatives as you
1052 can readily generate. This redundancy improves interconnectivity in
1053 situations where we can't make all programs read and write super-general
1054 formats. [Inside Macintosh chapter "Scrap Manager".] E.g. a graphically-
1055 annotated musical score might be supplemented by a stripped down 4-voice
1056 melody and by a text (the lyrics).
1058 The originating program should write the alternate representations
1059 in order of "preference": most preferred (most comprehensive) type
1060 to least preferred (least comprehensive) type. A receiving program
1061 should either use the first appearing type that it understands or
1062 search for its own "preferred" type.
1064 A scrap file should have at most one alternative of any type. (A LIST
1065 of same type objects is ok as one of the alternatives.) But don't
1066 count on this when reading; ignore extra sections of a type. Then
1067 a program that reads scrap files can read something out of single
1070 Rules for Reader Programs
1072 Here are some notes on building programs that read IFF files. If you
1073 use the standard IFF reader module "IFFR.C", many of these rules and
1074 details will be automatically handled. (See "Support Software" in
1075 Appendix A.) We recommend that you start from the example program
1076 "ShowILBM.C". You should also read up on recursive descent parsers.
1077 [See, for example, Compiler Construction, An Advanced Course.]
1079 % The standard is very flexible so many programs can exchange
1080 data. This implies a program has to scan the file and react to what's
1081 actually there in whatever order it appears. An IFF reader program
1084 % For interchange to really work, programs must be willing to
1085 do some conversion during read-in. If the data isn't exactly what
1086 you expect, say, the raster is smaller than those created by your
1087 program, then adjust it. Similarly, your program could crop a large
1088 picture, add or drop bitplanes, and create/discard a mask plane. The
1089 program should give up gracefully on data that it can't convert.
1091 % If it doesn't start with "FORM", "LIST", or "CAT ", it's not
1094 % For any chunk you encounter, you must recognize its type ID
1095 to understand its contents.
1097 % For any FORM chunk you encounter, you must recognize its FORM
1098 type ID to understand the contained "local chunks". Even if you don't
1099 recognize the FORM type, you can still scan it for nested FORMs, LISTs,
1100 and CATs of interest.
1102 % Don't forget to skip the pad byte after every odd-length chunk.
1104 % Chunk types LIST, FORM, PROP, and CAT are generic groups. They
1105 always contain a subtype ID followed by chunks.
1107 % Readers ought to handle a CAT of FORMs in a file. You may treat
1108 the FORMs like document pages to sequence through or just use the
1111 % Simpler IFF readers completely skip LISTs. "Fully IFF-conforming"
1112 readers are those that handle LISTs, even if just to read the first
1113 FORM from a file. If you do look into a LIST, you must process shared
1114 properties (in PROP chunks) properly. The idea is to get the correct
1115 data or none at all.
1117 % The nicest readers are willing to look into unrecognized FORMs
1118 for nested FORM types that they do recognize. For example, a musical
1119 score may contain nested instrument descriptions and an animation
1120 file may contain still pictures.
1122 Note to programmers: Processing PROP chunks is not simple! You'll
1123 need some background in interpreters with stack frames. If this is
1124 foreign to you, build programs that read/write only one FORM per file.
1125 For the more intrepid programmers, the next paragraph summarizes how
1126 to process LISTs and PROPs. See the general IFF reader module "IFFR.C"
1127 and the example program "ShowILBM.C" for details.
1129 Allocate a stack frame for every LIST and FORM you encounter and initialize
1130 it by copying the stack frame of the parent LIST or FORM. At the top
1131 level, you'll need a stack frame initialized to your program's global
1132 defaults. While reading each LIST or FORM, store all encountered properties
1133 into the current stack frame. In the example ShowILBM, each stack
1134 frame has a place for a bitmap header property ILBM.BMHD and a color
1135 map property ILBM.CMAP. When you finally get to the ILBM's BODY chunk,
1136 use the property settings accumulated in the current stack frame.
1138 An alternate implementation would just remember PROPs encountered,
1139 forgetting each on reaching the end of its scope (the end of the containing
1140 LIST). When a FORM XXXX is encountered, scan the chunks in all remembered
1141 PROPs XXXX, in order, as if they appeared before the chunks actually
1142 in the FORM XXXX. This gets trickier if you read FORMs inside of FORMs.
1144 Rules for Writer Programs
1146 Here are some notes on building programs that write IFF files, which
1147 is much easier than reading them. If you use the standard IFF writer
1148 module "IFFW.C" (see "Support Software" in Appendix A), many of these
1149 rules and details will automatically be enforced. See the example
1150 program "Raw2ILBM.C".
1152 % An IFF file is a single FORM, LIST, or CAT chunk.
1154 % Any IFF-85 file must start with the 4 characters "FORM", "LIST",
1155 or "CAT ", followed by a LONG ckSize. There should be no data after
1158 % Chunk types LIST, FORM, PROP, and CAT are generic. They always
1159 contain a subtype ID followed by chunks. These three IDs are universally
1160 reserved, as are "LIS1" through "LIS9", "FOR1" through "FOR9", "CAT1"
1161 through "CAT9", and " ".
1163 % Don't forget to write a 0 pad byte after each odd-length chunk.
1165 % Four techniques for writing an IFF group: (1) build the data
1166 in a file mapped into virtual memory, (2) build the data in memory
1167 blocks and use block I/O, (3) stream write the data piecemeal and
1168 (don't forget!) random access back to set the group length count,
1169 and (4) make a preliminary pass to compute the length count then stream
1172 % Do not try to edit a file that you don't know how to create.
1173 Programs may look into a file and copy out nested FORMs of types that
1174 they recognize, but don't edit and replace the nested FORMs and don't
1175 add or remove them. That could make the containing structure inconsistent.
1176 You may write a new file containing items you copied (or copied and
1177 modified) from another IFF file, but don't copy structural parts you
1180 % You must adhere to the syntax descriptions in Appendex A. E.g.
1181 PROPs may only appear inside LISTs.
1186 Appendix A. Reference
1190 The following C typedefs describe standard IFF structures. Declarations
1191 to use in practice will vary with the CPU and compiler. For example,
1192 68000 Lattice C produces efficient comparison code if we define ID
1193 as a "LONG". A macro "MakeID" builds these IDs at compile time.
1195 /* Standard IFF types, expressed in 68000 Lattice C. */
1197 typedef unsigned char UBYTE; /* 8 bits unsigned */
1198 typedef short WORD; /* 16 bits signed */
1199 typedef unsigned short UWORD; /* 16 bits unsigned */
1200 typedef long LONG; /* 32 bits signed */
1202 typedef char ID[4]; /* 4 chars in ' ' through '~' */
1206 LONG ckSize; /* sizeof(ckData) */
1207 UBYTE ckData[/* ckSize */];
1210 /* ID typedef and builder for 68000 Lattice C. */
1211 typedef LONG ID; /* 4 chars in ' ' through '~' */
1212 #define MakeID(a,b,c,d) ( (a)<<<<24 | (b)<<<<16 | (c)<<<<8 | (d) )
1214 /* Globally reserved IDs. */
1215 #define ID_FORM MakeID('F','O','R','M')
1216 #define ID_LIST MakeID('L','I','S','T')
1217 #define ID_PROP MakeID('P','R','O','P')
1218 #define ID_CAT MakeID('C','A','T',' ')
1219 #define ID_FILLER MakeID(' ',' ',' ',' ')
1223 Here's a collection of the syntax definitions in this document.
1225 Chunk ::= ID #{ UBYTE* } [0]
1229 FORM ::= "FORM" #{ FormType (LocalChunk | FORM | LIST | CAT)*
1232 LocalChunk ::= Property | Chunk
1234 CAT ::= "CAT " #{ ContentsType (FORM | LIST | CAT)* }
1235 ContentsType ::= ID -- a hint or an "abstract data type" ID
1237 LIST ::= "LIST" #{ ContentsType PROP* (FORM | LIST | CAT)* }
1238 PROP ::= "PROP" #{ FormType Property* }
1240 In this extended regular expression notation, the token "#" represents
1241 a ckSize LONG count of the following {braced} data bytes. Literal
1242 items are shown in "quotes", [square bracketed items] are optional,
1243 and "*" means 0 or more instances. A sometimes-needed pad byte is
1248 This is a table of currently defined chunk IDs. We may also borrow
1249 some Macintosh IDs and data formats.
1252 FORM, LIST, PROP, CAT.
1253 Future revision group chunk IDs
1254 FOR1 I FOR9, LIS1 I LIS9, CAT1 I CAT9.
1256 (The above group chunk IDs may not be used for FORM type IDs.)
1257 (Lower case letters and punctuation marks are forbidden in FORM
1259 8SVX 8-bit sampled sound voice, ANBM animated bitmap, FNTR raster
1260 font, FNTV vector font, FTXT formatted text, GSCR general-use musical
1261 score, ILBM interleaved raster bitmap image, PDEF Deluxe Print page
1262 definition, PICS Macintosh picture, PLBM (obsolete), USCR Uhuru Sound
1263 Software musical score, UVOX Uhuru Sound Software Macintosh voice,
1264 SMUS simple musical score, VDEO Deluxe Video Construction Set video.
1267 PROP LIST property IDs
1268 OPGM, OCPU, OCMP, OSN, UNAM.
1274 These public domain C source programs are available for use in building
1275 IFF-compatible programs:
1277 IFF.H, IFFR.C, IFFW.C
1279 IFF reader and writer package.
1280 These modules handle many of the details of reliably
1281 reading and writing IFF files.
1283 IFFCheck.C This handy utility program scans an IFF file, checks
1284 that the contents are well formed, and prints an outline
1287 PACKER.H, Packer.C, UnPacker.C
1289 Run encoder and decoder used for ILBM files.
1291 ILBM.H, ILBMR.C, ILBMW.C
1293 Reader and writer support routines for raster image
1294 FORM ILBM. ILBMR calls IFFR and UnPacker. ILBMW calls
1298 Example caller of IFFR and ILBMR modules. This
1299 Commodore-Amiga program reads and displays a FORM ILBM.
1301 Example ILBM writer program. As a demonstration, it
1302 reads a raw raster image file and writes the image
1303 as a FORM ILBM file.
1305 Example ILBM reader program. Reads a FORM ILBM file
1306 and writes it into a raw raster image.
1308 REMALLOC.H, Remalloc.c
1310 Memory allocation routines used in these examples.
1312 INTUALL.H generic "include almost everything" include-file
1313 with the sequence of includes correctly specified.
1315 READPICT.H, ReadPict.c
1317 given an ILBM file, read it into a bitmap and
1320 PUTPICT.H, PutPict.c
1322 given a bitmap and a color map, save it as
1325 GIO.H, Gio.c generic I/O speedup package. Attempts to speed
1326 disk I/O by buffering writes and reads.
1328 giocall.c sample call to gio.
1330 ilbmdump.c reads in ILBM file, prints out ascii representation
1331 for including in C files.
1333 bmprintc.c prints out a C-language representation of data for
1340 Here's a box diagram for an example IFF file, a raster image FORM
1341 ILBM. This FORM contains a bitmap header property chunk BMHD, a color
1342 map property chunk CMAP, and a raster data chunk BODY. This particular
1343 raster is 320 x 200 pixels x 3 bit planes uncompressed. The "0" after
1344 the CMAP chunk represents a zero pad byte; included since the CMAP
1345 chunk has an odd length. The text to the right of the diagram shows
1346 the outline that would be printed by the IFFCheck utility program
1347 for this particular file.
1349 +-----------------------------------+
1350 |'FORM' 24070 | FORM 24070 IBLM
1351 +-----------------------------------+
1353 +-----------------------------------+
1354 | +-------------------------------+ |
1355 | | 'BMHD' 20 | | .BMHD 20
1356 | | 320, 200, 0, 0, 3, 0, 0, ... | |
1357 | + ------------------------------+ |
1358 | | 'CMAP' 21 | | .CMAP 21
1359 | | 0, 0, 0; 32, 0, 0; 64,0,0; .. | |
1360 | +-------------------------------+ |
1362 +-----------------------------------+
1363 |'BODY' 24000 | .BODY 24000
1365 +-----------------------------------+
1367 This second diagram shows a LIST of two FORMs ILBM sharing a common
1368 BMHD property and a common CMAP property. Again, the text on the right
1369 is an outline a la IFFCheck.
1372 +-----------------------------------------+
1373 |'LIST' 48114 | LIST 48114 AAAA
1374 +-----------------------------------------+
1375 |'AAAA' | .PROP 62 ILBM
1376 | +-----------------------------------+ |
1378 | +-----------------------------------+ |
1380 | +-----------------------------------+ |
1381 | | +-------------------------------+ | |
1382 | | | 'BMHD' 20 | | | ..BMHD 20
1383 | | | 320, 200, 0, 0, 3, 0, 0, ... | | |
1384 | | | ------------------------------+ | |
1385 | | | 'CMAP' 21 | | | ..CMAP 21
1386 | | | 0, 0, 0; 32, 0, 0; 64,0,0; .. | | |
1387 | | +-------------------------------+ | |
1389 | +-----------------------------------+ |
1390 | +-----------------------------------+ |
1391 | |'FORM' 24012 | | .FORM 24012 ILBM
1392 | +-----------------------------------+ |
1394 | +-----------------------------------+ |
1395 | | +-----------------------------+ | |
1396 | | |'BODY' 24000 | | | ..BODY 24000
1397 | | |0, 0, 0, ... | | |
1398 | | +-----------------------------+ | |
1399 | +-----------------------------------+ |
1400 | +-----------------------------------+ |
1401 | |'FORM' 24012 | | .FORM 24012 ILBM
1402 | +-----------------------------------+ |
1404 | +-----------------------------------+ |
1405 | | +-----------------------------+ | |
1406 | | |'BODY' 24000 | | | ..BODY 24000
1407 | | |0, 0, 0, ... | | |
1408 | | +-----------------------------+ | |
1409 | +-----------------------------------+ |
1410 +-----------------------------------------+
1414 Appendix B. Standards Committee
1416 The following people contributed to the design of this IFF standard:
1418 Bob "Kodiak" Burns, Commodore-Amiga
1419 R. J. Mical, Commodore-Amiga
1420 Jerry Morrison, Electronic Arts
1421 Greg Riker, Electronic Arts
1422 Steve Shaw, Electronic Arts
1423 Barry Walsh, Commodore-Amiga