Note: This document uses little-endian(Intel) byte and bit order throughout.
Each DIFF-format file consists of one chunk, the DIFF chunk, which usually contains a "pencil-compatible" list of chunks inside.
A chunk has the following general structure:
The first bit of the tag indicates whether the chunk has a pencil-compatible header; the second bit indicates whether the chunk has a pencil-compatible chunk list. The remaining bits make up five 6-bit characters, using DIFF Tag Encoding(described later).
The payload consists of an optional pencil-compatible header, an optional pencil-compatible chunk list, and zero or more bytes of tag-specific data.
A pencil-compatible header is conceptually similar to an .INI file section, containing name=data entries in no particular order. Sections within it can be achieved by some application-defined interpretation of the names, like demarcation("Engine.Actor.Lifespan") or counting/lengthing("Program""Dare""TextTree"[0A]"TextFormat"). It has the following structure:
|4B||4B||[H. Size - 4]B
|[H. Size]||[E. Count]||[[E. Count] Header Entries]
Each header entry is as follows:
|4B||[N. Size]B||4B||[D. Size]B
|[N. Size]||[Name]||[D. Size]||[Data]
Pencil-Compatible Chunk List
A pencil-compatible chunk list is as follows:
|4B||4B||[L. Size - 4]B
|[L. Size]||[E. Count]||[[E. Count] Chunks]
The chunks within a pencil-compatible chunk list are full and normal chunks.
Tag-specific data is usually the ultimate payload.
- For a DIFF-format image, the image itself is probably tag-specific data, with a palette(if any) as tag-specific data in another chunk.
- For a DIFF-format movie, the frames are probably tag-specific data(whether in a single chunk or as per-frame chunks), and the audio track is probably tag-specific data in a chunk of its own.
- For a DIFF-format metadocument, each document within it is probably tag-specific data in per-document chunks.
Generally, an application reading a DIFF file should be able to ignore information specific to other applications, and an application should be able to add information specific to itself with relative freedom. Specifically:
- An application can freely add chunks whose tags mean nothing to other applications. Tags beginning with the <NC> character should be considered "private", though private to *what* can still be an issue.
- An application should ignore chunks whose tags mean nothing to it.
Unexpected Pencil-Compatible Headers Or Chunk Lists
- An application can freely add a pencil-compatible header or chunk list to a chunk that normally lacks one.
- An application should ignore an unexpected pencil-compatible header or chunk list; it presumably contains information specific to some other application.
Unexpected Header Entries
- An application can freely add entries to a pencil-compatible header whose names mean nothing to other applications. The recommended way to do this is with demarcation or counting/lengthing, with the first segment being "Program", and the second being the name of the application, or company/author(in which case the application name should be the third segment). The specific technique is unimportant, as long as it remains distinct; an application looking for entry names beginning with "Program.Spellstring." will know that an entry named "Program""Dare""DIDisplay"[0D]"WindowLocSize" is not for it. Note, however, that adding these requires knowledge of the chunk type; for some chunk types, all possible names are meaningful, and an application adding application-specific information to such a chunk should add a "private" chunk to its pencil-compatible chunk list.
- An application should ignore entries in a pencil-compatible header whose names mean nothing to it.
Propagation Of Unexpected Information
- An application need not propagate information specific to other applications; in fact, the information may no longer apply, for example if it was a CRC of the tag-specific data. However, an application can freely propagate such information, for example if it's overwriting a single header field and leaving the rest of the file intact. For this reason, "summary information" like CRCs should not be stored in application-specific fields.
- If an application is not already modifying a file, it should not modify it in order to remove information specific to other applications.
DIFF Tag Encoding
Note that while this table resembles the tables used for OnTwelve encoding, it is *not* OnTwelve-compatible. Also, the • and - characters are often treated as a single character, hyphen/minus, rather than separate hyphen and minus characters.
|30||W||X||Y||Z||+||±||-||=||<undefined; use "~" or "#8" through "#F" if needed>