|
@@ -0,0 +1,1424 @@
|
|
|
+
|
|
|
+
|
|
|
+"EA IFF 85" Standard for Interchange Format Files
|
|
|
+
|
|
|
+Document Date: January 14, 1985
|
|
|
+From: Jerry Morrison, Electronic Arts
|
|
|
+Status of Standard: Released and in use
|
|
|
+
|
|
|
+1. Introduction
|
|
|
+
|
|
|
+Standards are Good for Software Developers
|
|
|
+
|
|
|
+As home computer hardware evolves to better and better media machines,
|
|
|
+the demand increases for higher quality, more detailed data. Data
|
|
|
+development gets more expensive, requires more expertise and better
|
|
|
+tools, and has to be shared across projects. Think about several ports
|
|
|
+of a product on one CD-ROM with 500M Bytes of common data!
|
|
|
+
|
|
|
+Development tools need standard interchange file formats. Imagine
|
|
|
+scanning in images of "player" shapes, moving them to a paint program
|
|
|
+for editing, then incorporating them into a game. Or writing a theme
|
|
|
+song with a Macintosh score editor and incorporating it into an Amiga
|
|
|
+game. The data must at times be transformed, clipped, filled out,
|
|
|
+and moved across machine kinds. Media projects will depend on data
|
|
|
+transfer from graphic, music, sound effect, animation, and script
|
|
|
+tools.
|
|
|
+
|
|
|
+Standards are Good for Software Users
|
|
|
+
|
|
|
+Customers should be able to move their own data between independently
|
|
|
+developed software products. And they should be able to buy data libraries
|
|
|
+usable across many such products. The types of data objects to exchange
|
|
|
+are open-ended and include plain and formatted text, raster and structured
|
|
|
+graphics, fonts, music, sound effects, musical instrument descriptions,
|
|
|
+and animation.
|
|
|
+
|
|
|
+The problem with expedient file formats typically memory dumps is
|
|
|
+that they're too provincial. By designing data for one particular
|
|
|
+use (e.g. a screen snapshot), they preclude future expansion (would
|
|
|
+you like a full page picture? a multi-page document?). In neglecting
|
|
|
+the possibility that other programs might read their data, they fail
|
|
|
+to save contextual information (how many bit planes? what resolution?).
|
|
|
+Ignoring that other programs might create such files, they're intolerant
|
|
|
+of extra data (texture palette for a picture editor), missing data
|
|
|
+(no color map), or minor variations (smaller image). In practice,
|
|
|
+a filed representation should rarely mirror an in-memory representation.
|
|
|
+The former should be designed for longevity; the latter to optimize
|
|
|
+the manipulations of a particular program. The same filed data will
|
|
|
+be read into different memory formats by different programs.
|
|
|
+
|
|
|
+The IFF philosophy: "A little behind-the-scenes conversion when programs
|
|
|
+read and write files is far better than NxM explicit conversion utilities
|
|
|
+for highly specialized formats."
|
|
|
+
|
|
|
+So we need some standardization for data interchange among development
|
|
|
+tools and products. The more developers that adopt a standard, the
|
|
|
+better for all of us and our customers.
|
|
|
+
|
|
|
+Here is "EA IFF 1985"
|
|
|
+
|
|
|
+Here is our offering: Electronic Arts' IFF standard for Interchange
|
|
|
+File Format. The full name is "EA IFF 1985". Alternatives and justifications
|
|
|
+are included for certain choices. Public domain subroutine packages
|
|
|
+and utility programs are available to make it easy to write and use
|
|
|
+IFF-compatible programs.
|
|
|
+
|
|
|
+Part 1 introduces the standard. Part 2 presents its requirements and
|
|
|
+background. Parts 3, 4, and 5 define the primitive data types, FORMs,
|
|
|
+and LISTs, respectively, and how to define new high level types. Part
|
|
|
+6 specifies the top level file structure. Appendix A is included for
|
|
|
+quick reference and Appendix B names the committee responsible for
|
|
|
+this standard.
|
|
|
+
|
|
|
+References
|
|
|
+
|
|
|
+American National Standard Additional Control Codes for Use with ASCII,
|
|
|
+ANSI standard 3.64-1979 for an 8-bit character set. See also ISO standard
|
|
|
+2022 and ISO/DIS standard 6429.2.
|
|
|
+
|
|
|
+Amiga[tm] is a trademark of Commodore-Amiga, Inc.
|
|
|
+
|
|
|
+C, A Reference Manual, Samuel P. Harbison and Guy L. Steele Jr., Tartan
|
|
|
+Laboratories. Prentice-Hall, Englewood Cliffs, NJ, 1984.
|
|
|
+
|
|
|
+Compiler Construction, An Advanced Course, edited by F. L. Bauer and
|
|
|
+J. Eickel (Springer-Verlag, 1976). This book is one of many sources
|
|
|
+for information on recursive descent parsing.
|
|
|
+
|
|
|
+DIF Technical Specification (c)1981 by Software Arts, Inc. DIF[tm] is
|
|
|
+the format for spreadsheet data interchange developed by Software
|
|
|
+Arts, Inc.
|
|
|
+DIF[tm] is a trademark of Software Arts, Inc.
|
|
|
+
|
|
|
+Electronic Arts[tm] is a trademark of Electronic Arts.
|
|
|
+
|
|
|
+"FTXT" IFF Formatted Text, from Electronic Arts. IFF supplement document
|
|
|
+for a text format.
|
|
|
+
|
|
|
+Inside Macintosh (c) 1982, 1983, 1984, 1985 Apple Computer, Inc., a
|
|
|
+programmer's reference manual.
|
|
|
+Apple(R) is a trademark of Apple Computer, Inc.
|
|
|
+Macintosh[tm] is a trademark licensed to Apple Computer, Inc.
|
|
|
+
|
|
|
+"ILBM" IFF Interleaved Bitmap, from Electronic Arts. IFF supplement
|
|
|
+document for a raster image format.
|
|
|
+
|
|
|
+M68000 16/32-Bit Microprocessor Programmer's Reference Manual(c) 1984,
|
|
|
+1982, 1980, 1979 by Motorola, Inc.
|
|
|
+
|
|
|
+PostScript Language Manual (c) 1984 Adobe Systems Incorporated.
|
|
|
+PostScript[tm] is a trademark of Adobe Systems, Inc.
|
|
|
+Times and Helvetica(R) are trademarks of Allied Corporation.
|
|
|
+
|
|
|
+InterScript: A Proposal for a Standard for the Interchange of Editable
|
|
|
+Documents (c)1984 Xerox Corporation.
|
|
|
+Introduction to InterScript (c) 1985 Xerox Corporation.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+2. Background for Designers
|
|
|
+
|
|
|
+Part 2 is about the background, requirements, and goals for the standard.
|
|
|
+It's geared for people who want to design new types of IFF objects.
|
|
|
+People just interested in using the standard may wish to skip this
|
|
|
+part.
|
|
|
+
|
|
|
+What Do We Need?
|
|
|
+
|
|
|
+A standard should be long on prescription and short on overhead. It
|
|
|
+should give lots of rules for designing programs and data files for
|
|
|
+synergy. But neither the programs nor the files should cost too much
|
|
|
+more than the expedient variety. While we're looking to a future with
|
|
|
+CD-ROMs and perpendicular recording, the standard must work well on
|
|
|
+floppy disks.
|
|
|
+
|
|
|
+For program portability, simplicity, and efficiency, formats should
|
|
|
+be designed with more than one implementation style in mind. (In practice,
|
|
|
+pure stream I/O is adequate although random access makes it easier
|
|
|
+to write files.) It ought to be possible to read one of many objects
|
|
|
+in a file without scanning all the preceding data. Some programs need
|
|
|
+to read and play out their data in real time, so we need good compromises
|
|
|
+between generality and efficiency.
|
|
|
+
|
|
|
+As much as we need standards, they can't hold up product schedules.
|
|
|
+So we also need a kind of decentralized extensibility where any software
|
|
|
+developer can define and refine new object types without some "standards
|
|
|
+authority" in the loop. Developers must be able to extend existing
|
|
|
+formats in a forward- and backward-compatible way. A central repository
|
|
|
+for design information and example programs can help us take full
|
|
|
+advantage of the standard.
|
|
|
+
|
|
|
+For convenience, data formats should heed the restrictions of various
|
|
|
+processors and environments. E.g. word-alignment greatly helps 68000
|
|
|
+access at insignificant cost to 8088 programs.
|
|
|
+
|
|
|
+Other goals include the ability to share common elements over a list
|
|
|
+of objects and the ability to construct composite objects containing
|
|
|
+other data objects with structural information like directories.
|
|
|
+
|
|
|
+And finally, "Simple things should be simple and complex things should
|
|
|
+be possible." Alan Kay.
|
|
|
+
|
|
|
+Think Ahead
|
|
|
+
|
|
|
+Let's think ahead and build programs that read and write files for
|
|
|
+each other and for programs yet to be designed. Build data formats
|
|
|
+to last for future computers so long as the overhead is acceptable.
|
|
|
+This extends the usefulness and life of today's programs and data.
|
|
|
+
|
|
|
+To maximize interconnectivity, the standard file structure and the
|
|
|
+specific object formats must all be general and extensible. Think
|
|
|
+ahead when designing an object. It should serve many purposes and
|
|
|
+allow many programs to store and read back all the information they
|
|
|
+need; even squeeze in custom data. Then a programmer can store the
|
|
|
+available data and is encouraged to include fixed contextual details.
|
|
|
+Recipient programs can read the needed parts, skip unrecognized stuff,
|
|
|
+default missing data, and use the stored context to help transform
|
|
|
+the data as needed.
|
|
|
+
|
|
|
+Scope
|
|
|
+
|
|
|
+IFF addresses these needs by defining a standard file structure, some
|
|
|
+initial data object types, ways to define new types, and rules for
|
|
|
+accessing these files. We can accomplish a great deal by writing programs
|
|
|
+according to this standard, but don't expect direct compatibility
|
|
|
+with existing software. We'll need conversion programs to bridge the
|
|
|
+gap from the old world.
|
|
|
+
|
|
|
+IFF is geared for computers that readily process information in 8-bit
|
|
|
+bytes. It assumes a "physical layer" of data storage and transmission
|
|
|
+that reliably maintains "files" as strings of 8-bit bytes. The standard
|
|
|
+treats a "file" as a container of data bytes and is independent of
|
|
|
+how to find a file and whether it has a byte count.
|
|
|
+
|
|
|
+This standard does not by itself implement a clipboard for cutting
|
|
|
+and pasting data between programs. A clipboard needs software to mediate
|
|
|
+access, to maintain a "contents version number" so programs can detect
|
|
|
+updates, and to manage the data in "virtual memory".
|
|
|
+
|
|
|
+Data Abstraction
|
|
|
+
|
|
|
+The basic problem is how to represent information in a way that's
|
|
|
+program-independent, compiler- independent, machine-independent, and
|
|
|
+device-independent.
|
|
|
+
|
|
|
+The computer science approach is "data abstraction", also known as
|
|
|
+"objects", "actors", and "abstract data types". A data abstraction
|
|
|
+has a "concrete representation" (its storage format), an "abstract
|
|
|
+representation" (its capabilities and uses), and access procedures
|
|
|
+that isolate all the calling software from the concrete representation.
|
|
|
+Only the access procedures touch the data storage. Hiding mutable
|
|
|
+details behind an interface is called "information hiding". What data
|
|
|
+abstraction does is abstract from details of implementing the object,
|
|
|
+namely the selected storage representation and algorithms for manipulating
|
|
|
+it.
|
|
|
+
|
|
|
+The power of this approach is modularity. By adjusting the access
|
|
|
+procedures we can extend and restructure the data without impacting
|
|
|
+the interface or its callers. Conversely, we can extend and restructure
|
|
|
+the interface and callers without making existing data obsolete. It's
|
|
|
+great for interchange!
|
|
|
+
|
|
|
+But we seem to need the opposite: fixed file formats for all programs
|
|
|
+to access. Actually, we could file data abstractions ("filed objects")
|
|
|
+by storing the data and access procedures together. We'd have to encode
|
|
|
+the access procedures in a standard machine-independent programming
|
|
|
+language la PostScript. Even still, the interface can't evolve freely
|
|
|
+since we can't update all copies of the access procedures. So we'll
|
|
|
+have to design our abstract representations for limited evolution
|
|
|
+and occasional revolution (conversion).
|
|
|
+
|
|
|
+In any case, today's microcomputers can't practically store data abstractions.
|
|
|
+They can do the next best thing: store arbitrary types of data in
|
|
|
+"data chunks", each with a type identifier and a length count. The
|
|
|
+type identifier is a reference by name to the access procedures (any
|
|
|
+local implementation). The length count enables storage-level object
|
|
|
+operations like "copy" and "skip to next" independent of object type.
|
|
|
+
|
|
|
+Chunk writing is straightforward. Chunk reading requires a trivial
|
|
|
+parser to scan each chunk and dispatch to the proper access/conversion
|
|
|
+procedure. Reading chunks nested inside other chunks requires recursion,
|
|
|
+but no lookahead or backup.
|
|
|
+
|
|
|
+That's the main idea of IFF. There are, of course, a few other detailsI
|
|
|
+
|
|
|
+Previous Work
|
|
|
+
|
|
|
+Where our needs are similar, we borrow from existing standards.
|
|
|
+
|
|
|
+Our basic need to move data between independently developed programs
|
|
|
+is similar to that addressed by the Apple Macintosh desk scrap or
|
|
|
+"clipboard" [Inside Macintosh chapter "Scrap Manager"]. The Scrap
|
|
|
+Manager works closely with the Resource Manager, a handy filer and
|
|
|
+swapper for data objects (text strings, dialog window templates, pictures,
|
|
|
+fontsI) including types yet to be designed [Inside Macintosh chapter
|
|
|
+"Resource Manager"]. The Resource Manager is a kin to Smalltalk's
|
|
|
+object swapper.
|
|
|
+
|
|
|
+We will probably write a Macintosh desk accessory that converts IFF
|
|
|
+files to and from the Macintosh clipboard for quick and easy interchange
|
|
|
+with programs like MacPaint and Resource Mover.
|
|
|
+
|
|
|
+Macintosh uses a simple and elegant scheme of 4-character "identifiers"
|
|
|
+to identify resource types, clipboard format types, file types, and
|
|
|
+file creator programs. Alternatives are unique ID numbers assigned
|
|
|
+by a central authority or by hierarchical authorities, unique ID numbers
|
|
|
+generated by algorithm, other fixed length character strings, and
|
|
|
+variable length strings. Character string identifiers double as readable
|
|
|
+signposts in data files and programs. The choice of 4 characters is
|
|
|
+a good tradeoff between storage space, fetch/compare/store time, and
|
|
|
+name space size. We'll honor Apple's designers by adopting this scheme.
|
|
|
+
|
|
|
+"PICT" is a good example of a standard structured graphics format
|
|
|
+(including raster images) and its many uses [Inside Macintosh chapter
|
|
|
+"QuickDraw"]. Macintosh provides QuickDraw routines in ROM to create,
|
|
|
+manipulate, and display PICTs. Any application can create a PICT by
|
|
|
+simply asking QuickDraw to record a sequence of drawing commands.
|
|
|
+Since it's just as easy to ask QuickDraw to render a PICT to a screen
|
|
|
+or a printer, it's very effective to pass them between programs, say
|
|
|
+from an illustrator to a word processor. An important feature is the
|
|
|
+ability to store "comments" in a PICT which QuickDraw will ignore.
|
|
|
+Actually, it passes them to your optional custom "comment handler".
|
|
|
+
|
|
|
+PostScript, Adobe's print file standard, is a more general way to
|
|
|
+represent any print image (which is a specification for putting marks
|
|
|
+on paper) [PostScript Language Manual]. In fact, PostScript is a full-fledged
|
|
|
+programming language. To interpret a PostScript program is to render
|
|
|
+a document on a raster output device. The language is defined in layers:
|
|
|
+a lexical layer of identifiers, constants, and operators; a layer
|
|
|
+of reverse polish semantics including scope rules and a way to define
|
|
|
+new subroutines; and a printing-specific layer of built-in identifiers
|
|
|
+and operators for rendering graphic images. It is clearly a powerful
|
|
|
+(Turing equivalent) image definition language. PICT and a subset of
|
|
|
+PostScript are candidates for structured graphics standards.
|
|
|
+
|
|
|
+A PostScript document can be printed on any raster output device (including
|
|
|
+a display) but cannot generally be edited. That's because the original
|
|
|
+flexibility and constraints have been discarded. Besides, a PostScript
|
|
|
+program may use arbitrary computation to supply parameters like placement
|
|
|
+and size to each operator. A QuickDraw PICT, in comparison, is a more
|
|
|
+restricted format of graphic primitives parameterized by constants.
|
|
|
+So a PICT can be edited at the level of the primitives, e.g. move
|
|
|
+or thicken a line. It cannot be edited at the higher level of, say,
|
|
|
+the bar chart data which generated the picture.
|
|
|
+
|
|
|
+PostScript has another limitation: Not all kinds of data amount to
|
|
|
+marks on paper. A musical instrument description is one example. PostScript
|
|
|
+is just not geared for such uses.
|
|
|
+
|
|
|
+"DIF" is another example of data being stored in a general format
|
|
|
+usable by future programs [DIF Technical Specification]. DIF is a
|
|
|
+format for spreadsheet data interchange. DIF and PostScript are both
|
|
|
+expressed in plain ASCII text files. This is very handy for printing,
|
|
|
+debugging, experimenting, and transmitting across modems. It can have
|
|
|
+substantial cost in compaction and read/write work, depending on use.
|
|
|
+We won't store IFF files this way but we could define an ASCII alternate
|
|
|
+representation with a converter program.
|
|
|
+
|
|
|
+InterScript is Xerox' standard for interchange of editable documents
|
|
|
+[Introduction to InterScript]. It approaches a harder problem: How
|
|
|
+to represent editable word processor documents that may contain formatted
|
|
|
+text, pictures, cross-references like figure numbers, and even highly
|
|
|
+specialized objects like mathematical equations? InterScript aims
|
|
|
+to define one standard representation for each kind of information.
|
|
|
+Each InterScript-compatible editor is supposed to preserve the objects
|
|
|
+it doesn't understand and even maintain nested cross-references. So
|
|
|
+a simple word processor would let you edit the text of a fancy document
|
|
|
+without discarding the equations or disrupting the equation numbers.
|
|
|
+
|
|
|
+Our task is similarly to store high level information and preserve
|
|
|
+as much content as practical while moving it between programs. But
|
|
|
+we need to span a larger universe of data types and cannot expect
|
|
|
+to centrally define them all. Fortunately, we don't need to make programs
|
|
|
+preserve information that they don't understand. And for better or
|
|
|
+worse, we don't have to tackle general-purpose cross-references yet.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+3. Primitive Data Types
|
|
|
+
|
|
|
+Atomic components such as integers and characters that are interpretable
|
|
|
+directly by the CPU are specified in one format for all processors.
|
|
|
+We chose a format that's most convenient for the Motorola MC68000
|
|
|
+processor [M68000 16/32-Bit Microprocessor Programmer's Reference
|
|
|
+Manual].
|
|
|
+
|
|
|
+N.B.: Part 3 dictates the format for "primitive" data types where and
|
|
|
+only where used in the overall file structure and standard kinds of
|
|
|
+chunks (Cf. Chunks). The number of such occurrences will be small
|
|
|
+enough that the costs of conversion, storage, and management of processor-
|
|
|
+specific files would far exceed the costs of conversion during I/O by "foreign"
|
|
|
+programs. A particular data chunk may be specified with a different
|
|
|
+format for its internal primitive types or with processor- or environment-
|
|
|
+speci fic variants if necessary to optimize local usage. Since that hurts
|
|
|
+data interchange, it's not recommended. (Cf. Designing New Data Sections,
|
|
|
+in Part 4.)
|
|
|
+
|
|
|
+Alignment
|
|
|
+
|
|
|
+All data objects larger than a byte are aligned on even byte addresses
|
|
|
+relative to the start of the file. This may require padding. Pad bytes
|
|
|
+are to be written as zeros, but don't count on that when reading.
|
|
|
+
|
|
|
+This means that every odd-length "chunk" (see below) must be padded
|
|
|
+so that the next one will fall on an even boundary. Also, designers
|
|
|
+of structures to be stored in chunks should include pad fields where
|
|
|
+needed to align every field larger than a byte. Zeros should be stored
|
|
|
+in all the pad bytes.
|
|
|
+
|
|
|
+Justification: Even-alignment causes a little extra work for files
|
|
|
+that are used only on certain processors but allows 68000 programs
|
|
|
+to construct and scan the data in memory and do block I/O. You just
|
|
|
+add an occasional pad field to data structures that you're going to
|
|
|
+block read/write or else stream read/write an extra byte. And the
|
|
|
+same source code works on all processors. Unspecified alignment, on
|
|
|
+the other hand, would force 68000 programs to (dis)assemble word and
|
|
|
+long-word data one byte at a time. Pretty cumbersome in a high level
|
|
|
+language. And if you don't conditionally compile that out for other
|
|
|
+processors, you won't gain anything.
|
|
|
+
|
|
|
+Numbers
|
|
|
+
|
|
|
+Numeric types supported are two's complement binary integers in the
|
|
|
+format used by the MC68000 processor high byte first, high word first the
|
|
|
+reverse of 8088 and 6502 format. They could potentially include signed
|
|
|
+and unsigned 8, 16, and 32 bit integers but the standard only uses
|
|
|
+the following:
|
|
|
+
|
|
|
+UBYTE 8 bits unsigned
|
|
|
+WORD 16 bits signed
|
|
|
+UWORD 16 bits unsigned
|
|
|
+LONG 32 bits signed
|
|
|
+
|
|
|
+The actual type definitions depend on the CPU and the compiler. In
|
|
|
+this document, we'll express data type definitions in the C programming
|
|
|
+language. [See C, A Reference Manual.] In 68000 Lattice C:
|
|
|
+
|
|
|
+typedef unsigned char UBYTE; /* 8 bits unsigned */
|
|
|
+typedef short WORD; /* 16 bits signed */
|
|
|
+typedef unsigned short UWORD; /* 16 bits unsigned */
|
|
|
+typedef long LONG; /* 32 bits signed */
|
|
|
+
|
|
|
+Characters
|
|
|
+
|
|
|
+The following character set is assumed wherever characters are used,
|
|
|
+e.g. in text strings, IDs, and TEXT chunks (see below).
|
|
|
+
|
|
|
+Characters are encoded in 8-bit ASCII. Characters in the range NUL
|
|
|
+(hex 0) through DEL (hex 7F) are well defined by the 7-bit ASCII standard.
|
|
|
+IFF uses the graphic group RJS (SP, hex 20) through R~S (hex 7E).
|
|
|
+
|
|
|
+Most of the control character group hex 01 through hex 1F have no
|
|
|
+standard meaning in IFF. The control character LF (hex 0A) is defined
|
|
|
+as a "newline" character. It denotes an intentional line break, that
|
|
|
+is, a paragraph or line terminator. (There is no way to store an automatic
|
|
|
+line break. That is strictly a function of the margins in the environment
|
|
|
+the text is placed.) The control character ESC (hex 1B) is a reserved
|
|
|
+escape character under the rules of ANSI standard 3.64-1979 American
|
|
|
+National Standard Additional Control Codes for Use with ASCII, ISO
|
|
|
+standard 2022, and ISO/DIS standard 6429.2.
|
|
|
+
|
|
|
+Characters in the range hex 7F through hex FF are not globally defined
|
|
|
+in IFF. They are best left reserved for future standardization. But
|
|
|
+note that the FORM type FTXT (formatted text) defines the meaning
|
|
|
+of these characters within FTXT forms. In particular, character values
|
|
|
+hex 7F through hex 9F are control codes while characters hex A0 through
|
|
|
+hex FF are extended graphic characters like , as per the ISO and
|
|
|
+ANSI standards cited above. [See the supplementary document "FTXT"
|
|
|
+IFF Formatted Text.]
|
|
|
+
|
|
|
+Dates
|
|
|
+
|
|
|
+A "creation date" is defined as the date and time a stream of data
|
|
|
+bytes was created. (Some systems call this a "last modified date".)
|
|
|
+Editing some data changes its creation date. Moving the data between
|
|
|
+volumes or machines does not.
|
|
|
+
|
|
|
+The IFF standard date format will be one of those used in MS-DOS,
|
|
|
+Macintosh, or Amiga DOS (probably a 32-bit unsigned number of seconds
|
|
|
+since a reference point). Issue: Investigate these three.
|
|
|
+
|
|
|
+Type IDs
|
|
|
+
|
|
|
+A "type ID", "property name", "FORM type", or any other IFF identifier
|
|
|
+is a 32-bit value: the concatenation of four ASCII characters in the
|
|
|
+range R S (SP, hex 20) through R~S (hex 7E). Spaces (hex 20) should
|
|
|
+not precede printing characters; trailing spaces are ok. Control characters
|
|
|
+are forbidden.
|
|
|
+
|
|
|
+typedef CHAR ID[4];
|
|
|
+
|
|
|
+IDs are compared using a simple 32-bit case-dependent equality test.
|
|
|
+
|
|
|
+Data section type IDs (aka FORM types) are restriced IDs. (Cf. Data
|
|
|
+Sections.) Since they may be stored in filename extensions (Cf. Single
|
|
|
+Purpose Files) lower case letters and punctuation marks are forbidden.
|
|
|
+Trailing spaces are ok.
|
|
|
+
|
|
|
+Carefully choose those four characters when you pick a new ID. Make
|
|
|
+them mnemonic so programmers can look at an interchange format file
|
|
|
+and figure out what kind of data it contains. The name space makes
|
|
|
+it possible for developers scattered around the globe to generate
|
|
|
+ID values with minimal collisions so long as they choose specific
|
|
|
+names like "MUS4" instead of general ones like "TYPE" and "FILE".
|
|
|
+EA will "register" new FORM type IDs and format descriptions as they're
|
|
|
+devised, but collisions will be improbable so there will be no pressure
|
|
|
+on this "clearinghouse" process. Appendix A has a list of currently
|
|
|
+defined IDs.
|
|
|
+
|
|
|
+Sometimes it's necessary to make data format changes that aren't backward
|
|
|
+compatible. Since IDs are used to denote data formats in IFF, new
|
|
|
+IDs are chosen to denote revised formats. Since programs won't read
|
|
|
+chunks whose IDs they don't recognize (see Chunks, below), the new
|
|
|
+IDs keep old programs from stumbling over new data. The conventional
|
|
|
+way to chose a "revision" ID is to increment the last character if
|
|
|
+it's a digit or else change the last character to a digit. E.g. first
|
|
|
+and second revisions of the ID "XY" would be "XY1" and "XY2". Revisions
|
|
|
+of "CMAP" would be "CMA1" and "CMA2".
|
|
|
+
|
|
|
+Chunks
|
|
|
+
|
|
|
+Chunks are the building blocks in the IFF structure. The form expressed
|
|
|
+as a C typedef is:
|
|
|
+
|
|
|
+typedef struct {
|
|
|
+ ID ckID;
|
|
|
+ LONG ckSize; /* sizeof(ckData) */
|
|
|
+ UBYTE ckData[/* ckSize */];
|
|
|
+ } Chunk;
|
|
|
+
|
|
|
+We can diagram an example chunk a "CMAP" chunk containing 12 data
|
|
|
+bytes like this:
|
|
|
+ ----------------
|
|
|
+ ckID: | 'CMAP' |
|
|
|
+ ckSize: | 12 |
|
|
|
+ ckData: | 0, 0, 0, 32 | --------
|
|
|
+ | 0, 0, 64, 0 | 12 bytes
|
|
|
+ | 0, 0, 64, 0 | ---------
|
|
|
+ ----------------
|
|
|
+
|
|
|
+The fixed header part means "Here's a type ckID chunk with ckSize
|
|
|
+bytes of data."
|
|
|
+
|
|
|
+The ckID identifies the format and purpose of the chunk. As a rule,
|
|
|
+a program must recognize ckID to interpret ckData. It should skip
|
|
|
+over all unrecognized chunks. The ckID also serves as a format version
|
|
|
+number as long as we pick new IDs to identify new formats of ckData
|
|
|
+(see above).
|
|
|
+
|
|
|
+The following ckIDs are universally reserved to identify chunks with
|
|
|
+particular IFF meanings: "LIST", "FORM", "PROP", "CAT ", and "
|
|
|
+". The special ID " " (4 spaces) is a ckID for "filler" chunks,
|
|
|
+that is, chunks that fill space but have no meaningful contents. The
|
|
|
+IDs "LIS1" through "LIS9", "FOR1" through "FOR9", and "CAT1" through
|
|
|
+"CAT9" are reserved for future "version number" variations. All IFF-compatible
|
|
|
+software must account for these 23 chunk IDs. Appendix A has a list
|
|
|
+of predefined IDs.
|
|
|
+
|
|
|
+The ckSize is a logical block size how many data bytes are in ckData.
|
|
|
+If ckData is an odd number of bytes long, a 0 pad byte follows which
|
|
|
+is not included in ckSize. (Cf. Alignment.) A chunk's total physical
|
|
|
+size is ckSize rounded up to an even number plus the size of the header.
|
|
|
+So the smallest chunk is 8 bytes long with ckSize = 0. For the sake
|
|
|
+of following chunks, programs must respect every chunk's ckSize as
|
|
|
+a virtual end-of-file for reading its ckData even if that data is
|
|
|
+malformed, e.g. if nested contents are truncated.
|
|
|
+
|
|
|
+We can describe the syntax of a chunk as a regular expression with
|
|
|
+"#" representing the ckSize, i.e. the length of the following {braced}
|
|
|
+bytes. The "[0]" represents a sometimes needed pad byte. (The regular
|
|
|
+expressions in this document are collected in Appendix A along with
|
|
|
+an explanation of notation.)
|
|
|
+
|
|
|
+Chunk ::= ID #{ UBYTE* } [0]
|
|
|
+
|
|
|
+One chunk output technique is to stream write a chunk header, stream
|
|
|
+write the chunk contents, then random access back to the header to
|
|
|
+fill in the size. Another technique is to make a preliminary pass
|
|
|
+over the data to compute the size, then write it out all at once.
|
|
|
+
|
|
|
+Strings, String Chunks, and String Properties
|
|
|
+
|
|
|
+In a string of ASCII text, LF denotes a forced line break (paragraph
|
|
|
+or line terminator). Other control characters are not used. (Cf. Characters.)
|
|
|
+
|
|
|
+The ckID for a chunk that contains a string of plain, unformatted
|
|
|
+text is "TEXT". As a practical matter, a text string should probably
|
|
|
+not be longer than 32767 bytes. The standard allows up to 231 - 1
|
|
|
+bytes.
|
|
|
+
|
|
|
+When used as a data property (see below), a text string chunk may
|
|
|
+be 0 to 255 characters long. Such a string is readily converted to
|
|
|
+a C string or a Pascal STRING[255]. The ckID of a property must be
|
|
|
+the property name, not "TEXT".
|
|
|
+
|
|
|
+When used as a part of a chunk or data property, restricted C string
|
|
|
+format is normally used. That means 0 to 255 characters followed by
|
|
|
+a NUL byte (ASCII value 0).
|
|
|
+
|
|
|
+Data Properties
|
|
|
+
|
|
|
+Data properties specify attributes for following (non-property) chunks.
|
|
|
+A data property essentially says "identifier = value", for example
|
|
|
+"XY = (10, 200)", telling something about following chunks. Properties
|
|
|
+may only appear inside data sections ("FORM" chunks, cf. Data Sections)
|
|
|
+and property sections ("PROP" chunks, cf. Group PROP).
|
|
|
+
|
|
|
+The form of a data property is a special case of Chunk. The ckID is
|
|
|
+a property name as well as a property type. The ckSize should be small
|
|
|
+since data properties are intended to be accumulated in RAM when reading
|
|
|
+a file. (256 bytes is a reasonable upper bound.) Syntactically:
|
|
|
+
|
|
|
+Property ::= Chunk
|
|
|
+
|
|
|
+When designing a data object, use properties to describe context information
|
|
|
+like the size of an image, even if they don't vary in your program.
|
|
|
+Other programs will need this information.
|
|
|
+
|
|
|
+Think of property settings as assignments to variables in a programming
|
|
|
+language. Multiple assignments are redundant and local assignments
|
|
|
+temporarily override global assignments. The order of assignments
|
|
|
+doesn't matter as long as they precede the affected chunks. (Cf. LISTs,
|
|
|
+CATs, and Shared Properties.)
|
|
|
+
|
|
|
+Each object type (FORM type) is a local name space for property IDs.
|
|
|
+Think of a "CMAP" property in a "FORM ILBM" as the qualified ID "ILBM.CMAP".
|
|
|
+Property IDs specified when an object type is designed (and therefore
|
|
|
+known to all clients) are called "standard" while specialized ones
|
|
|
+added later are "nonstandard".
|
|
|
+
|
|
|
+Links
|
|
|
+
|
|
|
+Issue: A standard mechanism for "links" or "cross references" is very
|
|
|
+desirable for things like combining images and sounds into animations.
|
|
|
+Perhaps we'll define "link" chunks within FORMs that refer to other
|
|
|
+FORMs or to specific chunks within the same and other FORMs. This
|
|
|
+needs further work. EA IFF 1985 has no standard link mechanism.
|
|
|
+
|
|
|
+For now, it may suffice to read a list of, say, musical instruments,
|
|
|
+and then just refer to them within a musical score by index number.
|
|
|
+
|
|
|
+File References
|
|
|
+
|
|
|
+Issue: We may need a standard form for references to other files.
|
|
|
+A "file ref" could name a directory and a file in the same type of
|
|
|
+operating system as the ref's originator. Following the reference
|
|
|
+would expect the file to be on some mounted volume. In a network environment,
|
|
|
+a file ref could name a server, too.
|
|
|
+
|
|
|
+Issue: How can we express operating-system independent file refs?
|
|
|
+
|
|
|
+Issue: What about a means to reference a portion of another file?
|
|
|
+Would this be a "file ref" plus a reference to a "link" within the
|
|
|
+target file?
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+4. Data Sections
|
|
|
+
|
|
|
+The first thing we need of a file is to check: Does it contain IFF
|
|
|
+data and, if so, does it contain the kind of data we're looking for?
|
|
|
+So we come to the notion of a "data section".
|
|
|
+
|
|
|
+A "data section" or IFF "FORM" is one self-contained "data object"
|
|
|
+that might be stored in a file by itself. It is one high level data
|
|
|
+object such as a picture or a sound effect. The IFF structure "FORM"
|
|
|
+makes it self- identifying. It could be a composite object like a
|
|
|
+musical score with nested musical instrument descriptions.
|
|
|
+
|
|
|
+Group FORM
|
|
|
+
|
|
|
+A data section is a chunk with ckID "FORM" and this arrangement:
|
|
|
+
|
|
|
+FORM ::= "FORM" #{ FormType (LocalChunk | FORM | LIST | CAT)*
|
|
|
+}
|
|
|
+FormType ::= ID
|
|
|
+LocalChunk ::= Property | Chunk
|
|
|
+
|
|
|
+The ID "FORM" is a syntactic keyword like "struct" in C. Think of
|
|
|
+a "struct ILBM" containing a field "CMAP". If you see "FORM" you'll
|
|
|
+know to expect a FORM type ID (the structure name, "ILBM" in this
|
|
|
+example) and a particular contents arrangement or "syntax" (local
|
|
|
+chunks, FORMs, LISTs, and CATs). (LISTs and CATs are discussed in
|
|
|
+part 5, below.) A "FORM ILBM", in particular, might contain a local
|
|
|
+chunk "CMAP", an "ILBM.CMAP" (to use a qualified name).
|
|
|
+
|
|
|
+So the chunk ID "FORM" indicates a data section. It implies that the
|
|
|
+chunk contains an ID and some number of nested chunks. In reading
|
|
|
+a FORM, like any other chunk, programs must respect its ckSize as
|
|
|
+a virtual end-of-file for reading its contents, even if they're truncated.
|
|
|
+
|
|
|
+The FormType (or FORM type) is a restricted ID that may not contain
|
|
|
+lower case letters or punctuation characters. (Cf. Type IDs. Cf. Single
|
|
|
+Purpose Files.)
|
|
|
+
|
|
|
+The type-specific information in a FORM is composed of its "local
|
|
|
+chunks": data properties and other chunks. Each FORM type is a local
|
|
|
+name space for local chunk IDs. So "CMAP" local chunks in other FORM
|
|
|
+types may be unrelated to "ILBM.CMAP". More than that, each FORM type
|
|
|
+defines semantic scope. If you know what a FORM ILBM is, you'll know
|
|
|
+what an ILBM.CMAP is.
|
|
|
+
|
|
|
+Local chunks defined when the FORM type is designed (and therefore
|
|
|
+known to all clients of this type) are called "standard" while specialized
|
|
|
+ones added later are "nonstandard".
|
|
|
+
|
|
|
+Among the local chunks, property chunks give settings for various
|
|
|
+details like text font while the other chunks supply the essential
|
|
|
+information. This distinction is not clear cut. A property setting
|
|
|
+cancelled by a later setting of the same property has effect only
|
|
|
+on data chunks in between. E.g. in the sequence:
|
|
|
+
|
|
|
+prop1 = x (propN = value)* prop1 = y
|
|
|
+
|
|
|
+where the propNs are not prop1, the setting prop1 = x has no effect.
|
|
|
+
|
|
|
+The following universal chunk IDs are reserved inside any FORM: "LIST",
|
|
|
+"FORM", "PROP", "CAT ", "JJJJ", "LIS1" through "LIS9", "FOR1" through
|
|
|
+"FOR9", and "CAT1" through "CAT9". (Cf. Chunks. Cf. Group LIST. Cf.
|
|
|
+Group PROP.) For clarity, these universal chunk names may not be FORM
|
|
|
+type IDs, either.
|
|
|
+
|
|
|
+Part 5, below, talks about grouping FORMs into LISTs and CATs. They
|
|
|
+let you group a bunch of FORMs but don't impose any particular meaning
|
|
|
+or constraints on the grouping. Read on.
|
|
|
+
|
|
|
+Composite FORMs
|
|
|
+
|
|
|
+A FORM chunk inside a FORM is a full-fledged data section. This means
|
|
|
+you can build a composite object like a multi-frame animation sequence
|
|
|
+from available picture FORMs and sound effect FORMs. You can insert
|
|
|
+additional chunks with information like frame rate and frame count.
|
|
|
+
|
|
|
+Using composite FORMs, you leverage on existing programs that create
|
|
|
+and edit the component FORMs. Those editors may even look into your
|
|
|
+composite object to copy out its type of component, although it'll
|
|
|
+be the rare program that's fancy enough to do that. Such editors are
|
|
|
+not allowed to replace their component objects within your composite
|
|
|
+object. That's because the IFF standard lets you specify consistency
|
|
|
+requirements for the composite FORM such as maintaining a count or
|
|
|
+a directory of the components. Only programs that are written to uphold
|
|
|
+the rules of your FORM type should create or modify such FORMs.
|
|
|
+
|
|
|
+Therefore, in designing a program that creates composite objects,
|
|
|
+you are strongly requested to provide a facility for your users to
|
|
|
+import and export the nested FORMs. Import and export could move the
|
|
|
+data through a clipboard or a file.
|
|
|
+
|
|
|
+Here are several existing FORM types and rules for defining new ones.
|
|
|
+
|
|
|
+FTXT
|
|
|
+
|
|
|
+An FTXT data section contains text with character formatting information
|
|
|
+like fonts and faces. It has no paragraph or document formatting information
|
|
|
+like margins and page headers. FORM FTXT is well matched to the text
|
|
|
+representation in Amiga's Intuition environment. See the supplemental
|
|
|
+document "FTXT" IFF Formatted Text.
|
|
|
+
|
|
|
+ILBM
|
|
|
+
|
|
|
+"ILBM" is an InterLeaved BitMap image with color map; a machine-independent
|
|
|
+format for raster images. FORM ILBM is the standard image file format
|
|
|
+for the Commodore-Amiga computer and is useful in other environments,
|
|
|
+too. See the supplemental document "ILBM" IFF Interleaved Bitmap.
|
|
|
+
|
|
|
+PICS
|
|
|
+
|
|
|
+The data chunk inside a "PICS" data section has ID "PICT" and holds
|
|
|
+a QuickDraw picture. Issue: Allow more than one PICT in a PICS? See
|
|
|
+Inside Macintosh chapter "QuickDraw" for details on PICTs and how
|
|
|
+to create and display them on the Macintosh computer.
|
|
|
+
|
|
|
+The only standard property for PICS is "XY", an optional property
|
|
|
+that indicates the position of the PICT relative to "the big picture".
|
|
|
+The contents of an XY is a QuickDraw Point.
|
|
|
+
|
|
|
+Note: PICT may be limited to Macintosh use, in which case there'll
|
|
|
+be another format for structured graphics in other environments.
|
|
|
+
|
|
|
+Other Macintosh Resource Types
|
|
|
+
|
|
|
+Some other Macintosh resource types could be adopted for use within
|
|
|
+IFF files; perhaps MWRT, ICN, ICN#, and STR#.
|
|
|
+
|
|
|
+Issue: Consider the candidates and reserve some more IDs.
|
|
|
+
|
|
|
+Designing New Data Sections
|
|
|
+
|
|
|
+Supplemental documents will define additional object types. A supplement
|
|
|
+needs to specify the object's purpose, its FORM type ID, the IDs and
|
|
|
+formats of standard local chunks, and rules for generating and interpreting
|
|
|
+the data. It's a good idea to supply typedefs and an example source
|
|
|
+program that accesses the new object. See "ILBM" IFF Interleaved Bitmap
|
|
|
+for a good example.
|
|
|
+
|
|
|
+Anyone can pick a new FORM type ID but should reserve it with Electronic
|
|
|
+Arts at their earliest convenience. [Issue: EA contact person? Hand
|
|
|
+this off to another organization?] While decentralized format definitions
|
|
|
+and extensions are possible in IFF, our preference is to get design
|
|
|
+consensus by committee, implement a program to read and write it,
|
|
|
+perhaps tune the format, and then publish the format with example
|
|
|
+code. Some organization should remain in charge of answering questions
|
|
|
+and coordinating extensions to the format.
|
|
|
+
|
|
|
+If it becomes necessary to revise the design of some data section,
|
|
|
+its FORM type ID will serve as a version number (Cf. Type IDs). E.g.
|
|
|
+a revised "VDEO" data section could be called "VDE1". But try to get
|
|
|
+by with compatible revisions within the existing FORM type.
|
|
|
+
|
|
|
+In a new FORM type, the rules for primitive data types and word-alignment
|
|
|
+(Cf. Primitive Data Types) may be overriden for the contents of its
|
|
|
+local chunks but not for the chunk structure itself if your documentation
|
|
|
+spells out the deviations. If machine-specific type variants are needed,
|
|
|
+e.g. to store vast numbers of integers in reverse bit order, then
|
|
|
+outline the conversion algorithm and indicate the variant inside each
|
|
|
+file, perhaps via different FORM types. Needless to say, variations
|
|
|
+should be minimized.
|
|
|
+
|
|
|
+In designing a FORM type, encapsulate all the data that other programs
|
|
|
+will need to interpret your files. E.g. a raster graphics image should
|
|
|
+specify the image size even if your program always uses 320 x 200
|
|
|
+pixels x 3 bitplanes. Receiving programs are then empowered to append
|
|
|
+or clip the image rectangle, to add or drop bitplanes, etc. This enables
|
|
|
+a lot more compatibility.
|
|
|
+
|
|
|
+Separate the central data (like musical notes) from more specialized
|
|
|
+information (like note beams) so simpler programs can extract the
|
|
|
+central parts during read-in. Leave room for expansion so other programs
|
|
|
+can squeeze in new kinds of information (like lyrics). And remember
|
|
|
+to keep the property chunks manageably short let's say 2 256 bytes.
|
|
|
+
|
|
|
+When designing a data object, try to strike a good tradeoff between
|
|
|
+a super-general format and a highly-specialized one. Fit the details
|
|
|
+to at least one particular need, for example a raster image might
|
|
|
+as well store pixels in the current machine's scan order. But add
|
|
|
+the kind of generality that makes it usable with foreseeable hardware
|
|
|
+and software. E.g. use a whole byte for each red, green, and blue
|
|
|
+color value even if this year's computer has only 4-bit video DACs.
|
|
|
+Think ahead and help other programs so long as the overhead is acceptable.
|
|
|
+E.g. run compress a raster by scan line rather than as a unit so future
|
|
|
+programs can swap images by scan line to and from secondary storage.
|
|
|
+
|
|
|
+Try to design a general purpose "least common multiple" format that
|
|
|
+encompasses the needs of many programs without getting too complicated.
|
|
|
+Let's coalesce our uses around a few such formats widely separated
|
|
|
+in the vast design space. Two factors make this flexibility and simplicity
|
|
|
+practical. First, file storage space is getting very plentiful, so
|
|
|
+compaction is not a priority. Second, nearly any locally-performed
|
|
|
+data conversion work during file reading and writing will be cheap
|
|
|
+compared to the I/O time.
|
|
|
+
|
|
|
+It must be ok to copy a LIST or FORM or CAT intact, e.g. to incorporate
|
|
|
+it into a composite FORM. So any kind of internal references within
|
|
|
+a FORM must be relative references. They could be relative to the
|
|
|
+start of the containing FORM, relative from the referencing chunk,
|
|
|
+or a sequence number into a collection.
|
|
|
+
|
|
|
+With composite FORMs, you leverage on existing programs that create
|
|
|
+and edit the components. If you write a program that creates composite
|
|
|
+objects, please provide a facility for your users to import and export
|
|
|
+the nested FORMs. The import and export functions may move data through
|
|
|
+a separate file or a clipboard.
|
|
|
+
|
|
|
+Finally, don't forget to specify all implied rules in detail.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+5. LISTs, CATs, and Shared Properties
|
|
|
+
|
|
|
+Data often needs to be grouped together like a list of icons. Sometimes
|
|
|
+a trick like arranging little images into a big raster works, but
|
|
|
+generally they'll need to be structured as a first class group. The
|
|
|
+objects "LIST" and "CAT" are IFF-universal mechanisms for this purpose.
|
|
|
+
|
|
|
+Property settings sometimes need to be shared over a list of similar
|
|
|
+objects. E.g. a list of icons may share one color map. LIST provides
|
|
|
+a means called "PROP" to do this. One purpose of a LIST is to define
|
|
|
+the scope of a PROP. A "CAT", on the other hand, is simply a concatenation
|
|
|
+of objects.
|
|
|
+
|
|
|
+Simpler programs may skip LISTs and PROPs altogether and just handle
|
|
|
+FORMs and CATs. All "fully-conforming" IFF programs also know about
|
|
|
+"CAT ", "LIST", and "PROP". Any program that reads a FORM inside a
|
|
|
+LIST must process shared PROPs to correctly interpret that FORM.
|
|
|
+
|
|
|
+Group CAT
|
|
|
+
|
|
|
+A CAT is just an untyped group of data objects.
|
|
|
+
|
|
|
+Structurally, a CAT is a chunk with chunk ID "CAT " containing a "contents
|
|
|
+type" ID followed by the nested objects. The ckSize of each contained
|
|
|
+chunk is essentially a relative pointer to the next one.
|
|
|
+
|
|
|
+CAT ::= "CAT " #{ ContentsType (FORM | LIST | CAT)* }
|
|
|
+ContentsType ::= ID -- a hint or an "abstract data type" ID
|
|
|
+
|
|
|
+In reading a CAT, like any other chunk, programs must respect it's
|
|
|
+ckSize as a virtual end-of-file for reading the nested objects even
|
|
|
+if they're malformed or truncated.
|
|
|
+
|
|
|
+The "contents type" following the CAT's ckSize indicates what kind
|
|
|
+of FORMs are inside. So a CAT of ILBMs would store "ILBM" there. It's
|
|
|
+just a hint. It may be used to store an "abstract data type". A CAT
|
|
|
+could just have blank contents ID ("JJJJ") if it contains more than
|
|
|
+one kind of FORM.
|
|
|
+
|
|
|
+CAT defines only the format of the group. The group's meaning is open
|
|
|
+to interpretation. This is like a list in LISP: the structure of cells
|
|
|
+is predefined but the meaning of the contents as, say, an association
|
|
|
+list depends on use. If you need a group with an enforced meaning
|
|
|
+(an "abstract data type" or Smalltalk "subclass"), some consistency
|
|
|
+constraints, or additional data chunks, use a composite FORM instead
|
|
|
+(Cf. Composite FORMs).
|
|
|
+
|
|
|
+Since a CAT just means a concatenation of objects, CATs are rarely
|
|
|
+nested. Programs should really merge CATs rather than nest them.
|
|
|
+
|
|
|
+Group LIST
|
|
|
+
|
|
|
+A LIST defines a group very much like CAT but it also gives a scope
|
|
|
+for PROPs (see below). And unlike CATs, LISTs should not be merged
|
|
|
+without understanding their contents.
|
|
|
+
|
|
|
+Structurally, a LIST is a chunk with ckID "LIST" containing a "contents
|
|
|
+type" ID, optional shared properties, and the nested contents (FORMs,
|
|
|
+LISTs, and CATs), in that order. The ckSize of each contained chunk
|
|
|
+is a relative pointer to the next one. A LIST is not an arbitrary
|
|
|
+linked list the cells are simply concatenated.
|
|
|
+
|
|
|
+LIST ::= "LIST" #{ ContentsType PROP* (FORM | LIST | CAT)* }
|
|
|
+ContentsType ::= ID
|
|
|
+
|
|
|
+Group PROP
|
|
|
+
|
|
|
+PROP chunks may appear in LISTs (not in FORMs or CATs). They supply
|
|
|
+shared properties for the FORMs in that LIST. This ability to elevate
|
|
|
+some property settings to shared status for a list of forms is useful
|
|
|
+for both indirection and compaction. E.g. a list of images with the
|
|
|
+same size and colors can share one "size" property and one "color
|
|
|
+map" property. Individual FORMs can override the shared settings.
|
|
|
+
|
|
|
+The contents of a PROP is like a FORM with no data chunks:
|
|
|
+
|
|
|
+PROP ::= "PROP" #{ FormType Property* }
|
|
|
+
|
|
|
+It means, "Here are the shared properties for FORM type <<FormType>."
|
|
|
+
|
|
|
+A LIST may have at most one PROP of a FORM type, and all the PROPs
|
|
|
+must appear before any of the FORMs or nested LISTs and CATs. You
|
|
|
+can have subsequences of FORMs sharing properties by making each subsequence
|
|
|
+a LIST.
|
|
|
+
|
|
|
+Scoping: Think of property settings as variable bindings in nested
|
|
|
+blocks of a programming language. Where in C you could write:
|
|
|
+
|
|
|
+TEXT_FONT text_font = Courier; /* program's global default */
|
|
|
+
|
|
|
+File(); {
|
|
|
+ TEXT_FONT text_font = TimesRoman; /* shared setting */
|
|
|
+
|
|
|
+ {
|
|
|
+ TEXT_FONT text_font = Helvetica; /* local setting */
|
|
|
+ Print("Hello "); /* uses font Helvetica */
|
|
|
+ }
|
|
|
+
|
|
|
+ {
|
|
|
+ Print("there."); /* uses font TimesRoman */
|
|
|
+ }
|
|
|
+ }
|
|
|
+
|
|
|
+An IFF file could contain:
|
|
|
+
|
|
|
+LIST {
|
|
|
+ PROP TEXT {
|
|
|
+ FONT {TimesRoman} /* shared setting */
|
|
|
+ }
|
|
|
+
|
|
|
+ FORM TEXT {
|
|
|
+ FONT {Helvetica} /* local setting */
|
|
|
+ CHRS {Hello } /* uses font Helvetica */
|
|
|
+ }
|
|
|
+
|
|
|
+ FORM TEXT {
|
|
|
+ CHRS {there.} /* uses font TimesRoman */
|
|
|
+ }
|
|
|
+ }
|
|
|
+
|
|
|
+The shared property assignments selectively override the reader's
|
|
|
+global defaults, but only for FORMs within the group. A FORM's own
|
|
|
+property assignments selectively override the global and group-supplied
|
|
|
+values. So when reading an IFF file, keep property settings on a stack.
|
|
|
+They're designed to be small enough to hold in main memory.
|
|
|
+
|
|
|
+Shared properties are semantically equivalent to copying those properties
|
|
|
+into each of the nested FORMs right after their FORM type IDs.
|
|
|
+
|
|
|
+Properties for LIST
|
|
|
+
|
|
|
+Optional "properties for LIST" store the origin of the list's contents
|
|
|
+in a PROP chunk for the fake FORM type "LIST". They are the properties
|
|
|
+originating program "OPGM", processor family "OCPU", computer type
|
|
|
+"OCMP", computer serial number or network address "OSN ", and user
|
|
|
+name "UNAM". In our imperfect world, these could be called upon to
|
|
|
+distinguish between unintended variations of a data format or to work
|
|
|
+around bugs in particular originating/receiving program pairs. Issue:
|
|
|
+Specify the format of these properties.
|
|
|
+
|
|
|
+A creation date could also be stored in a property but let's ask that
|
|
|
+file creating, editing, and transporting programs maintain the correct
|
|
|
+date in the local file system. Programs that move files between machine
|
|
|
+types are expected to copy across the creation dates.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+6. Standard File Structure
|
|
|
+
|
|
|
+File Structure Overview
|
|
|
+
|
|
|
+An IFF file is just a single chunk of type FORM, LIST, or CAT. Therefore
|
|
|
+an IFF file can be recognized by its first 4 bytes: "FORM", "LIST",
|
|
|
+or "CAT ". Any file contents after the chunk's end are to be ignored.
|
|
|
+
|
|
|
+Since an IFF file can be a group of objects, programs that read/write
|
|
|
+single objects can communicate to an extent with programs that read/write
|
|
|
+groups. You're encouraged to write programs that handle all the objects
|
|
|
+in a LIST or CAT. A graphics editor, for example, could process a
|
|
|
+list of pictures as a multiple page document, one page at a time.
|
|
|
+
|
|
|
+Programs should enforce IFF's syntactic rules when reading and writing
|
|
|
+files. This ensures robust data transfer. The public domain IFF reader/writer
|
|
|
+subroutine package does this for you. A utility program "IFFCheck"
|
|
|
+is available that scans an IFF file and checks it for conformance
|
|
|
+to IFF's syntactic rules. IFFCheck also prints an outline of the chunks
|
|
|
+in the file, showing the ckID and ckSize of each. This is quite handy
|
|
|
+when building IFF programs. Example programs are also available to
|
|
|
+show details of reading and writing IFF files.
|
|
|
+
|
|
|
+A merge program "IFFJoin" will be available that logically appends
|
|
|
+IFF files into a single CAT group. It "unwraps" each input file that
|
|
|
+is a CAT so that the combined file isn't nested CATs.
|
|
|
+
|
|
|
+If we need to revise the IFF standard, the three anchoring IDs will
|
|
|
+be used as "version numbers". That's why IDs "FOR1" through "FOR9",
|
|
|
+"LIS1" through "LIS9", and "CAT1" through "CAT9" are reserved.
|
|
|
+
|
|
|
+IFF formats are designed for reasonable performance with floppy disks.
|
|
|
+We achieve considerable simplicity in the formats and programs by
|
|
|
+relying on the host file system rather than defining universal grouping
|
|
|
+structures like directories for LIST contents. On huge storage systems,
|
|
|
+IFF files could be leaf nodes in a file structure like a B-tree. Let's
|
|
|
+hope the host file system implements that for us!
|
|
|
+
|
|
|
+Thre are two kinds of IFF files: single purpose files and scrap files.
|
|
|
+They differ in the interpretation of multiple data objects and in
|
|
|
+the file's external type.
|
|
|
+
|
|
|
+Single Purpose Files
|
|
|
+
|
|
|
+A single purpose IFF file is for normal "document" and "archive" storage.
|
|
|
+This is in contrast with "scrap files" (see below) and temporary backing
|
|
|
+storage (non-interchange files).
|
|
|
+
|
|
|
+The external file type (or filename extension, depending on the host
|
|
|
+file system) indicates the file's contents. It's generally the FORM
|
|
|
+type of the data contained, hence the restrictions on FORM type IDs.
|
|
|
+
|
|
|
+Programmers and users may pick an "intended use" type as the filename
|
|
|
+extension to make it easy to filter for the relevant files in a filename
|
|
|
+requestor. This is actually a "subclass" or "subtype" that conveniently
|
|
|
+separates files of the same FORM type that have different uses. Programs
|
|
|
+cannot demand conformity to its expected subtypes without overly restricting
|
|
|
+data interchange since they cannot know about the subtypes to be used
|
|
|
+by future programs that users will want to exchange data with.
|
|
|
+
|
|
|
+Issue: How to generate 3-letter MS-DOS extensions from 4-letter FORM
|
|
|
+type IDs?
|
|
|
+
|
|
|
+Most single purpose files will be a single FORM (perhaps a composite
|
|
|
+FORM like a musical score containing nested FORMs like musical instrument
|
|
|
+descriptions). If it's a LIST or a CAT, programs should skip over
|
|
|
+unrecognized objects to read the recognized ones or the first recognized
|
|
|
+one. Then a program that can read a single purpose file can read something
|
|
|
+out of a "scrap file", too.
|
|
|
+
|
|
|
+Scrap Files
|
|
|
+
|
|
|
+A "scrap file" is for maximum interconnectivity in getting data between
|
|
|
+programs; the core of a clipboard function. Scrap files may have type
|
|
|
+"IFF " or filename extension ".IFF".
|
|
|
+
|
|
|
+A scrap file is typically a CAT containing alternate representations
|
|
|
+of the same basic information. Include as many alternatives as you
|
|
|
+can readily generate. This redundancy improves interconnectivity in
|
|
|
+situations where we can't make all programs read and write super-general
|
|
|
+formats. [Inside Macintosh chapter "Scrap Manager".] E.g. a graphically-
|
|
|
+annotated musical score might be supplemented by a stripped down 4-voice
|
|
|
+melody and by a text (the lyrics).
|
|
|
+
|
|
|
+The originating program should write the alternate representations
|
|
|
+in order of "preference": most preferred (most comprehensive) type
|
|
|
+to least preferred (least comprehensive) type. A receiving program
|
|
|
+should either use the first appearing type that it understands or
|
|
|
+search for its own "preferred" type.
|
|
|
+
|
|
|
+A scrap file should have at most one alternative of any type. (A LIST
|
|
|
+of same type objects is ok as one of the alternatives.) But don't
|
|
|
+count on this when reading; ignore extra sections of a type. Then
|
|
|
+a program that reads scrap files can read something out of single
|
|
|
+purpose files.
|
|
|
+
|
|
|
+Rules for Reader Programs
|
|
|
+
|
|
|
+Here are some notes on building programs that read IFF files. If you
|
|
|
+use the standard IFF reader module "IFFR.C", many of these rules and
|
|
|
+details will be automatically handled. (See "Support Software" in
|
|
|
+Appendix A.) We recommend that you start from the example program
|
|
|
+"ShowILBM.C". You should also read up on recursive descent parsers.
|
|
|
+[See, for example, Compiler Construction, An Advanced Course.]
|
|
|
+
|
|
|
+% The standard is very flexible so many programs can exchange
|
|
|
+data. This implies a program has to scan the file and react to what's
|
|
|
+actually there in whatever order it appears. An IFF reader program
|
|
|
+is a parser.
|
|
|
+
|
|
|
+% For interchange to really work, programs must be willing to
|
|
|
+do some conversion during read-in. If the data isn't exactly what
|
|
|
+you expect, say, the raster is smaller than those created by your
|
|
|
+program, then adjust it. Similarly, your program could crop a large
|
|
|
+picture, add or drop bitplanes, and create/discard a mask plane. The
|
|
|
+program should give up gracefully on data that it can't convert.
|
|
|
+
|
|
|
+% If it doesn't start with "FORM", "LIST", or "CAT ", it's not
|
|
|
+an IFF-85 file.
|
|
|
+
|
|
|
+% For any chunk you encounter, you must recognize its type ID
|
|
|
+to understand its contents.
|
|
|
+
|
|
|
+% For any FORM chunk you encounter, you must recognize its FORM
|
|
|
+type ID to understand the contained "local chunks". Even if you don't
|
|
|
+recognize the FORM type, you can still scan it for nested FORMs, LISTs,
|
|
|
+and CATs of interest.
|
|
|
+
|
|
|
+% Don't forget to skip the pad byte after every odd-length chunk.
|
|
|
+
|
|
|
+% Chunk types LIST, FORM, PROP, and CAT are generic groups. They
|
|
|
+always contain a subtype ID followed by chunks.
|
|
|
+
|
|
|
+% Readers ought to handle a CAT of FORMs in a file. You may treat
|
|
|
+the FORMs like document pages to sequence through or just use the
|
|
|
+first FORM.
|
|
|
+
|
|
|
+% Simpler IFF readers completely skip LISTs. "Fully IFF-conforming"
|
|
|
+readers are those that handle LISTs, even if just to read the first
|
|
|
+FORM from a file. If you do look into a LIST, you must process shared
|
|
|
+properties (in PROP chunks) properly. The idea is to get the correct
|
|
|
+data or none at all.
|
|
|
+
|
|
|
+% The nicest readers are willing to look into unrecognized FORMs
|
|
|
+for nested FORM types that they do recognize. For example, a musical
|
|
|
+score may contain nested instrument descriptions and an animation
|
|
|
+file may contain still pictures.
|
|
|
+
|
|
|
+Note to programmers: Processing PROP chunks is not simple! You'll
|
|
|
+need some background in interpreters with stack frames. If this is
|
|
|
+foreign to you, build programs that read/write only one FORM per file.
|
|
|
+For the more intrepid programmers, the next paragraph summarizes how
|
|
|
+to process LISTs and PROPs. See the general IFF reader module "IFFR.C"
|
|
|
+and the example program "ShowILBM.C" for details.
|
|
|
+
|
|
|
+Allocate a stack frame for every LIST and FORM you encounter and initialize
|
|
|
+it by copying the stack frame of the parent LIST or FORM. At the top
|
|
|
+level, you'll need a stack frame initialized to your program's global
|
|
|
+defaults. While reading each LIST or FORM, store all encountered properties
|
|
|
+into the current stack frame. In the example ShowILBM, each stack
|
|
|
+frame has a place for a bitmap header property ILBM.BMHD and a color
|
|
|
+map property ILBM.CMAP. When you finally get to the ILBM's BODY chunk,
|
|
|
+use the property settings accumulated in the current stack frame.
|
|
|
+
|
|
|
+An alternate implementation would just remember PROPs encountered,
|
|
|
+forgetting each on reaching the end of its scope (the end of the containing
|
|
|
+LIST). When a FORM XXXX is encountered, scan the chunks in all remembered
|
|
|
+PROPs XXXX, in order, as if they appeared before the chunks actually
|
|
|
+in the FORM XXXX. This gets trickier if you read FORMs inside of FORMs.
|
|
|
+
|
|
|
+Rules for Writer Programs
|
|
|
+
|
|
|
+Here are some notes on building programs that write IFF files, which
|
|
|
+is much easier than reading them. If you use the standard IFF writer
|
|
|
+module "IFFW.C" (see "Support Software" in Appendix A), many of these
|
|
|
+rules and details will automatically be enforced. See the example
|
|
|
+program "Raw2ILBM.C".
|
|
|
+
|
|
|
+% An IFF file is a single FORM, LIST, or CAT chunk.
|
|
|
+
|
|
|
+% Any IFF-85 file must start with the 4 characters "FORM", "LIST",
|
|
|
+or "CAT ", followed by a LONG ckSize. There should be no data after
|
|
|
+the chunk end.
|
|
|
+
|
|
|
+% Chunk types LIST, FORM, PROP, and CAT are generic. They always
|
|
|
+contain a subtype ID followed by chunks. These three IDs are universally
|
|
|
+reserved, as are "LIS1" through "LIS9", "FOR1" through "FOR9", "CAT1"
|
|
|
+through "CAT9", and " ".
|
|
|
+
|
|
|
+% Don't forget to write a 0 pad byte after each odd-length chunk.
|
|
|
+
|
|
|
+% Four techniques for writing an IFF group: (1) build the data
|
|
|
+in a file mapped into virtual memory, (2) build the data in memory
|
|
|
+blocks and use block I/O, (3) stream write the data piecemeal and
|
|
|
+(don't forget!) random access back to set the group length count,
|
|
|
+and (4) make a preliminary pass to compute the length count then stream
|
|
|
+write the data.
|
|
|
+
|
|
|
+% Do not try to edit a file that you don't know how to create.
|
|
|
+Programs may look into a file and copy out nested FORMs of types that
|
|
|
+they recognize, but don't edit and replace the nested FORMs and don't
|
|
|
+add or remove them. That could make the containing structure inconsistent.
|
|
|
+You may write a new file containing items you copied (or copied and
|
|
|
+modified) from another IFF file, but don't copy structural parts you
|
|
|
+don't understand.
|
|
|
+
|
|
|
+% You must adhere to the syntax descriptions in Appendex A. E.g.
|
|
|
+PROPs may only appear inside LISTs.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Appendix A. Reference
|
|
|
+
|
|
|
+Type Definitions
|
|
|
+
|
|
|
+The following C typedefs describe standard IFF structures. Declarations
|
|
|
+to use in practice will vary with the CPU and compiler. For example,
|
|
|
+68000 Lattice C produces efficient comparison code if we define ID
|
|
|
+as a "LONG". A macro "MakeID" builds these IDs at compile time.
|
|
|
+
|
|
|
+/* Standard IFF types, expressed in 68000 Lattice C. */
|
|
|
+
|
|
|
+typedef unsigned char UBYTE; /* 8 bits unsigned */
|
|
|
+typedef short WORD; /* 16 bits signed */
|
|
|
+typedef unsigned short UWORD; /* 16 bits unsigned */
|
|
|
+typedef long LONG; /* 32 bits signed */
|
|
|
+
|
|
|
+typedef char ID[4]; /* 4 chars in ' ' through '~' */
|
|
|
+
|
|
|
+typedef struct {
|
|
|
+ ID ckID;
|
|
|
+ LONG ckSize; /* sizeof(ckData) */
|
|
|
+ UBYTE ckData[/* ckSize */];
|
|
|
+ } Chunk;
|
|
|
+
|
|
|
+/* ID typedef and builder for 68000 Lattice C. */
|
|
|
+typedef LONG ID; /* 4 chars in ' ' through '~' */
|
|
|
+#define MakeID(a,b,c,d) ( (a)<<<<24 | (b)<<<<16 | (c)<<<<8 | (d) )
|
|
|
+
|
|
|
+/* Globally reserved IDs. */
|
|
|
+#define ID_FORM MakeID('F','O','R','M')
|
|
|
+#define ID_LIST MakeID('L','I','S','T')
|
|
|
+#define ID_PROP MakeID('P','R','O','P')
|
|
|
+#define ID_CAT MakeID('C','A','T',' ')
|
|
|
+#define ID_FILLER MakeID(' ',' ',' ',' ')
|
|
|
+
|
|
|
+Syntax Definitions
|
|
|
+
|
|
|
+Here's a collection of the syntax definitions in this document.
|
|
|
+
|
|
|
+Chunk ::= ID #{ UBYTE* } [0]
|
|
|
+
|
|
|
+Property ::= Chunk
|
|
|
+
|
|
|
+FORM ::= "FORM" #{ FormType (LocalChunk | FORM | LIST | CAT)*
|
|
|
+}
|
|
|
+FormType ::= ID
|
|
|
+LocalChunk ::= Property | Chunk
|
|
|
+
|
|
|
+CAT ::= "CAT " #{ ContentsType (FORM | LIST | CAT)* }
|
|
|
+ContentsType ::= ID -- a hint or an "abstract data type" ID
|
|
|
+
|
|
|
+LIST ::= "LIST" #{ ContentsType PROP* (FORM | LIST | CAT)* }
|
|
|
+PROP ::= "PROP" #{ FormType Property* }
|
|
|
+
|
|
|
+In this extended regular expression notation, the token "#" represents
|
|
|
+a ckSize LONG count of the following {braced} data bytes. Literal
|
|
|
+items are shown in "quotes", [square bracketed items] are optional,
|
|
|
+and "*" means 0 or more instances. A sometimes-needed pad byte is
|
|
|
+shown as "[0]".
|
|
|
+
|
|
|
+Defined Chunk IDs
|
|
|
+
|
|
|
+This is a table of currently defined chunk IDs. We may also borrow
|
|
|
+some Macintosh IDs and data formats.
|
|
|
+
|
|
|
+Group chunk IDs
|
|
|
+ FORM, LIST, PROP, CAT.
|
|
|
+Future revision group chunk IDs
|
|
|
+ FOR1 I FOR9, LIS1 I LIS9, CAT1 I CAT9.
|
|
|
+FORM type IDs
|
|
|
+ (The above group chunk IDs may not be used for FORM type IDs.)
|
|
|
+ (Lower case letters and punctuation marks are forbidden in FORM
|
|
|
+type IDs.)
|
|
|
+ 8SVX 8-bit sampled sound voice, ANBM animated bitmap, FNTR raster
|
|
|
+font, FNTV vector font, FTXT formatted text, GSCR general-use musical
|
|
|
+score, ILBM interleaved raster bitmap image, PDEF Deluxe Print page
|
|
|
+definition, PICS Macintosh picture, PLBM (obsolete), USCR Uhuru Sound
|
|
|
+Software musical score, UVOX Uhuru Sound Software Macintosh voice,
|
|
|
+SMUS simple musical score, VDEO Deluxe Video Construction Set video.
|
|
|
+Data chunk IDs
|
|
|
+ "JJJJ", TEXT, PICT.
|
|
|
+PROP LIST property IDs
|
|
|
+ OPGM, OCPU, OCMP, OSN, UNAM.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Support Software
|
|
|
+
|
|
|
+These public domain C source programs are available for use in building
|
|
|
+IFF-compatible programs:
|
|
|
+
|
|
|
+IFF.H, IFFR.C, IFFW.C
|
|
|
+
|
|
|
+ IFF reader and writer package.
|
|
|
+ These modules handle many of the details of reliably
|
|
|
+ reading and writing IFF files.
|
|
|
+
|
|
|
+IFFCheck.C This handy utility program scans an IFF file, checks
|
|
|
+ that the contents are well formed, and prints an outline
|
|
|
+ of the chunks.
|
|
|
+
|
|
|
+PACKER.H, Packer.C, UnPacker.C
|
|
|
+
|
|
|
+ Run encoder and decoder used for ILBM files.
|
|
|
+
|
|
|
+ILBM.H, ILBMR.C, ILBMW.C
|
|
|
+
|
|
|
+ Reader and writer support routines for raster image
|
|
|
+ FORM ILBM. ILBMR calls IFFR and UnPacker. ILBMW calls
|
|
|
+ IFFW and Packer.
|
|
|
+
|
|
|
+ShowILBM.C
|
|
|
+ Example caller of IFFR and ILBMR modules. This
|
|
|
+ Commodore-Amiga program reads and displays a FORM ILBM.
|
|
|
+Raw2ILBM.C
|
|
|
+ Example ILBM writer program. As a demonstration, it
|
|
|
+ reads a raw raster image file and writes the image
|
|
|
+ as a FORM ILBM file.
|
|
|
+ILBM2Raw.C
|
|
|
+ Example ILBM reader program. Reads a FORM ILBM file
|
|
|
+ and writes it into a raw raster image.
|
|
|
+
|
|
|
+REMALLOC.H, Remalloc.c
|
|
|
+
|
|
|
+ Memory allocation routines used in these examples.
|
|
|
+
|
|
|
+INTUALL.H generic "include almost everything" include-file
|
|
|
+ with the sequence of includes correctly specified.
|
|
|
+
|
|
|
+READPICT.H, ReadPict.c
|
|
|
+
|
|
|
+ given an ILBM file, read it into a bitmap and
|
|
|
+ a color map
|
|
|
+
|
|
|
+PUTPICT.H, PutPict.c
|
|
|
+
|
|
|
+ given a bitmap and a color map, save it as
|
|
|
+ an ILBM file.
|
|
|
+
|
|
|
+GIO.H, Gio.c generic I/O speedup package. Attempts to speed
|
|
|
+ disk I/O by buffering writes and reads.
|
|
|
+
|
|
|
+giocall.c sample call to gio.
|
|
|
+
|
|
|
+ilbmdump.c reads in ILBM file, prints out ascii representation
|
|
|
+ for including in C files.
|
|
|
+
|
|
|
+bmprintc.c prints out a C-language representation of data for
|
|
|
+ a bitmap.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Example Diagrams
|
|
|
+
|
|
|
+Here's a box diagram for an example IFF file, a raster image FORM
|
|
|
+ILBM. This FORM contains a bitmap header property chunk BMHD, a color
|
|
|
+map property chunk CMAP, and a raster data chunk BODY. This particular
|
|
|
+raster is 320 x 200 pixels x 3 bit planes uncompressed. The "0" after
|
|
|
+the CMAP chunk represents a zero pad byte; included since the CMAP
|
|
|
+chunk has an odd length. The text to the right of the diagram shows
|
|
|
+the outline that would be printed by the IFFCheck utility program
|
|
|
+for this particular file.
|
|
|
+
|
|
|
+ +-----------------------------------+
|
|
|
+ |'FORM' 24070 | FORM 24070 IBLM
|
|
|
+ +-----------------------------------+
|
|
|
+ |'ILBM' |
|
|
|
+ +-----------------------------------+
|
|
|
+ | +-------------------------------+ |
|
|
|
+ | | 'BMHD' 20 | | .BMHD 20
|
|
|
+ | | 320, 200, 0, 0, 3, 0, 0, ... | |
|
|
|
+ | + ------------------------------+ |
|
|
|
+ | | 'CMAP' 21 | | .CMAP 21
|
|
|
+ | | 0, 0, 0; 32, 0, 0; 64,0,0; .. | |
|
|
|
+ | +-------------------------------+ |
|
|
|
+ | 0 |
|
|
|
+ +-----------------------------------+
|
|
|
+ |'BODY' 24000 | .BODY 24000
|
|
|
+ |0, 0, 0, ... |
|
|
|
+ +-----------------------------------+
|
|
|
+
|
|
|
+This second diagram shows a LIST of two FORMs ILBM sharing a common
|
|
|
+BMHD property and a common CMAP property. Again, the text on the right
|
|
|
+is an outline a la IFFCheck.
|
|
|
+
|
|
|
+
|
|
|
+ +-----------------------------------------+
|
|
|
+ |'LIST' 48114 | LIST 48114 AAAA
|
|
|
+ +-----------------------------------------+
|
|
|
+ |'AAAA' | .PROP 62 ILBM
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | |'PROP' 62 | |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | |'ILBM' | |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | | +-------------------------------+ | |
|
|
|
+ | | | 'BMHD' 20 | | | ..BMHD 20
|
|
|
+ | | | 320, 200, 0, 0, 3, 0, 0, ... | | |
|
|
|
+ | | | ------------------------------+ | |
|
|
|
+ | | | 'CMAP' 21 | | | ..CMAP 21
|
|
|
+ | | | 0, 0, 0; 32, 0, 0; 64,0,0; .. | | |
|
|
|
+ | | +-------------------------------+ | |
|
|
|
+ | | 0 | |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | |'FORM' 24012 | | .FORM 24012 ILBM
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | |'ILBM' | |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | | +-----------------------------+ | |
|
|
|
+ | | |'BODY' 24000 | | | ..BODY 24000
|
|
|
+ | | |0, 0, 0, ... | | |
|
|
|
+ | | +-----------------------------+ | |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | |'FORM' 24012 | | .FORM 24012 ILBM
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | |'ILBM' | |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ | | +-----------------------------+ | |
|
|
|
+ | | |'BODY' 24000 | | | ..BODY 24000
|
|
|
+ | | |0, 0, 0, ... | | |
|
|
|
+ | | +-----------------------------+ | |
|
|
|
+ | +-----------------------------------+ |
|
|
|
+ +-----------------------------------------+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+Appendix B. Standards Committee
|
|
|
+
|
|
|
+The following people contributed to the design of this IFF standard:
|
|
|
+
|
|
|
+Bob "Kodiak" Burns, Commodore-Amiga
|
|
|
+R. J. Mical, Commodore-Amiga
|
|
|
+Jerry Morrison, Electronic Arts
|
|
|
+Greg Riker, Electronic Arts
|
|
|
+Steve Shaw, Electronic Arts
|
|
|
+Barry Walsh, Commodore-Amiga
|