xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (03/08/91)
Note followups! nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: {An ongoing conversation, talking about the IFF standard] More important, though, is that IFF is a standard container for standard encodings, and you are perfectly free to (and, more likely than not, someone already has) define an encoding key called "PAK8" instead of "ILBM" and store your data as eight bit pixels if that makes you happier. The rule for an IFF "chunk" is, if a decoder/displayer doesn't recognize the code quadbyte, it is supposed to skip the associated data and go on to what it can handle; this is again excellent functionality in an _exchange_ standard. >If everybody defined their own standard chunks there would no longer be any >standard chunks. True if the story ended there, but there is a registration process so that if the Mac people wanted to register a BHX4 container name for the very common BinHex4.0 exchange format, they could assure that there were no collisions with other vendors' container names, and also (optionally) furnish a publically usable specification for that format, so that John or Jill Programmer could write a BHX4 handler for _any_ machine to which the encased data was of interest. It is also permissible to register a container name for a proprietary format. Though that dooms it as an exchange format, doing so does make it possible for a vendor to mix the proprietary containers with other containers in an IFF file, and know that on processing an IFF file, if that container name is seen, it is in the vendor's proprietary format, and the vendor provided handler should be invoked and can be invoked safely. At least one music program did/does use such a proprietary format. The proof of the pudding, etc., is that the vendor/format/implementation mix in IFF files on the Amiga (and perhaps other machines, I'm no expert here) has been quite successful. You can build an IFF that looks like a Chinese restaurant menu of containers, and pass the file to various handlers, and each does all and only what it can with the encoded data. For example, an IFF file might contain text, graphics, and picture containers, which can be separately accessed by pagers or editors or voice synthasizers for the text, viewers or paint programs for the graphics, and players or synthasizers or samplers for the music, depending on what interests the particular user, then passed off to a kitchen sink style special purpose handler that animates the graphics, plays the music, reads the text aloud, and scrolls the text in a "closed caption" window, all at once. I don't claim it is easy, merely that IFF makes it possible, and that such usage is common on the Amiga. Contrariwise, such complexity is not mandated for an IFF file, merely available. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- By the way, I think the term of art is more like "hunk" than "container", but I hope the latter is clearer to the person not associated with the IFF standard.