indd-utils/docs/format/objects.md

# INDD objects

How the byte stream of a database object (see `database.md`) is
structured, and what the classes and chunks used by the converter mean.
Implemented in `src/object.rs` and `src/model/`.

## How this was learned

IDML exported by InDesign names most objects `Self="u<hex>"`, and that hex
number is the object's UID in the INDD file. So each corpus pair gives, for
every such IDML element, the INDD object, its class, and the attribute
values its chunks must encode. Facts below were found by comparing the two,
and are checked by `tools/compare.py`, which converts every pair (78 unique
pairs, InDesign 7.5–21) and compares the output with the reference IDML
attribute by attribute.

## Chunks

Most objects (99.9 % of 773,753 in the little-endian corpus) are a sequence
of chunks:

| Size | Field |
|---|---|
| 4 | Chunk ID |
| 4 | Data length *n* |
| *n* | Data |

The rest are plain byte streams: objects of class 0x129 (raw data, below)
and the XMP packet (UID 0x80000001). In the 245 distinct little-endian
files, all 1,171 class 0x129 objects are plain byte streams. Chunk IDs are in the same number space as
class IDs; a chunk often lists objects of the class with the same number
(for example chunk 0x501 of the document lists spreads, class 0x501).

## Primitive encodings

Object data is in the byte order of the header's flag (`header.md`).
All samples except two are little-endian, and the examples here are
little-endian. Big-endian data and the layouts of InDesign 3.0 and 4.0
are in `big-endian.md`.

- **UID lists:** u32 count, then that many u32 UIDs.
- **Matrices:** six f64, in IDML `ItemTransform` order (a b c d tx ty).
- **Text segments:** a u16 header, flags in bits 14–15 and a count in bits
  0–13. 0x4000: *count* single-byte characters follow. 0x8000: *count*
  UTF-16 code units follow. A text of *n* code units is a sequence of
  segments adding up to *n*. Example: "WOMEN’S\r" is
  `05 40 "WOMEN" 01 80 19 20 02 40 "S\r"`.
- **In-object strings:** u8 2, u8 (usually 0; a script code in some
  strings, below), u16 length in code units, then segments. 4,135 occurrences in three sample files.
  In files from InDesign 2.0 the first byte is 1: in the four distinct 2.0
  files, the pattern tag, 0, length *n*, 0, segment header 0x4000 + *n*
  occurs 154 to 353 times per file with tag 1 and never with tag 2. In
  the 83 distinct 3.0, 4.0 and 5.0 little-endian files the same pattern
  has tag 2 (76 to 4,296 times per file); tag 1 matches once in each of
  two of them.

## Document (class 0xE01, always UID 1)

| Chunk | Contents |
|---|---|
| 0x501 | UID list: spreads, in order |
| 0x1401 | UID list: master spreads |
| 0x301 | UID list: layers (the first is an internal layer that holds pages) |
| 0x313 | u32: active layer (IDML `ActiveLayer`) |
| 0x222 | Two UID lists: the stories, then the XML backing story; IDML `StoryList` is both (`xml.md`) |
| 0x4C01 | UID list: sections |
| 0xA443 | Document users: u32 count, then per user a flag byte, the name as an in-object string, u32 colour |
| 0x1D8 | Save history: u32 count, then one record per session (below) |
| 0x1630B | Label: u16 0x7B7B, u32 count *n*, then *n* pairs of key and value, each a flag byte and an in-object string |
| 0x21B03 | UID list: articles, in order (below, articles) |

**Document label.** IDML writes `Document/Properties/Label` with one
`KeyValuePair` (`Key`, `Value`) per stored pair, in stored order, with
the strings as stored. Without the chunk there is no `Label`.
Evidence: 436 of the 438 trustworthy pairs whose IDML has a document
label match (one differs, one has no chunk). The flag byte is 1 on 4
keys in 4 pairs, all others 0; the 3 of these pairs whose IDML has a
document label write the key without the `$ID/` prefix of built-in
names.

**Script byte of the user names.** The second byte of each user name's
in-object string (the byte after the string tag) is a script code: 0
in documents in Latin script, 1 in all 9 trustworthy pairs with
Japanese user or assignment names, 7 in a Russian, 25 in a Simplified
Chinese and 29 in a Czech document. The same codes are font writing
scripts (1 for Japanese fonts, 25 for Simplified Chinese fonts). All
users of a document have the same byte, except in one pair with users
of bytes 0 and 7. The converter uses the byte of the last user to
choose font family names (`fonts.md`, native family names).

Other in-object strings carry the same kind of byte, so a search for a
string must accept any second byte. In the 149 pairs typeset in
Japanese it is 1 for most user-made names, and 3, 5, 7, 0x19 and 0x1D
also occur, in style names, style GUIDs, layer names and ruby font
styles. Layer names and style GUIDs (below) rely on this.

**Document users.** IDML lists one `DocumentUser` per user in chunk
0xA443, `Self` being `dDocumentUser` and the index in hexadecimal (491 of
495 trustworthy pairs have as many users as the chunk; the other 4 are
DOM 7 and 16 files with one user more in the IDML). A user with flag 0
has its stored name as `UserName` (1,724 of 1,724). Flag 2 marks the
placeholder for an unknown user, stored with a name such as
`Unknown User Name` or the same words in the language of the computer
that saved it; IDML writes `$ID/Unknown User Name` for 495 of the 586
such users, and the stored name for the other 91. The rule is the
saving edition's name for an unknown user (saving edition, below):
IDML writes `$ID/Unknown User Name` for every user, of either flag,
whose stored name is that edition's, and the stored name for every
other user, also a flag 2 user named in another language (for example
`Unknown User Name` in a document last saved by a Korean edition).
Without a black name the converter writes `$ID/Unknown User Name` for
every flag 2 user (the schema requires `UserName`). The colour UID names an interface colour, but the IDML
`UserColor` does not follow from it (users stored with 0.6, 0.4, 0 are
`BrickRed` in 4 files and `Gold` in 1), so it is left out of the
conversion and of the measurement (`measurement.md`).

**Save history (chunk 0x1D8).** A u32 count, then one record per
session that saved the document, oldest first:

| Field | Contents |
|---|---|
| u16 | kind (not used) |
| u16 | platform: 0 or 3 (style shortcuts, below) |
| u16, u16 | not identified |
| u16 | language code (below) |
| flag byte, in-object string | application version, such as `16.1.0.20` |
| u16 | build (not used) |
| u32, u32 | FILETIME of the session, high part first (not used) |

Evidence: the layout parses every record of 4,431 of the 4,439
distinct valid corpus files outside the privately held samples (4,272
little-endian, 159 big-endian), from InDesign 3.0 to 21. Of the other
8, six are InDesign 2.x files whose strings have another tag
(in-object strings, above) and two (one 3.x, one 13.x) have no chunk. All 803
pairs parse.

**Language code.** The u16 of the last record is 0x0100 in 4,018 of
those files, 0x0101 in 335, 0x0103 in 53 and 0x0400 in 25. It follows
the language edition of the application of that session:

- All 149 pairs typeset in Japanese that the corpus gained in 2026-10
  have 0x0101; so do 11 earlier pairs, among them the 7 whose default
  story tag name (preferences chunk 0xBF4F) is Japanese or Chinese.
  No document with a tag name in another language (Korean, German,
  French, Russian, …) has 0x0101 (654 pairs before 2026-10).
- The values IDML writes in the exporting InDesign's language follow
  it (below): in 0x0101 documents the flattener resolution, the index
  title and separator and the endnote separator are those of a
  Japanese edition.
- 0x0103 occurs in documents in Latin and Hebrew script; it gives the
  same values as 0x0100 in all 12 pairs that have it.

The converter reads the code of the last record only, and only uses
whether it is 0x0101.

**Application version.** The version string of the last record can be
later than the version in the header: InDesign 13.1 saved files whose
header says 13.0. IDML writes some values only from 13.1, and follows
the application, not the header. Over the trustworthy pairs of version
12.0 to 14.0 (corpus after 2026-10), the document's
`TextFramePreference` has the `Footnotes…` values:

| Header | Last session | IDML `DOMVersion` | Pairs | With the values |
|---|---|---|---:|---:|
| 12.0, 12.1 | same | same | 72 | 0 |
| 13.0 | 13.0 | 13.0 | 42 | 0 |
| 13.0 | 13.0 | 13.1 | 16 | 16 |
| 13.0 | 13.1 | 13.1 | 93 | 93 |
| 13.1 | 13.1 | 13.1 | 148 | 148 |
| 14.0 | 14.0 or 14.3 | 14.0 | 43 | 43 |

The 16 were exported by InDesign 13.1 without saving, which the INDD
cannot show. The converter takes a 13.1 boundary as reached when the
header or the last session is at least 13.1: for the `Footnotes…`
values of the document, of text frames and of object styles, and for
`MergeConsecutiveParaBorders`. This adds 93 to 253 values for each of
these keys and no wrong or extra value. The record count is checked against the chunk
size; a chunk that does not parse gives no code.

**Values that follow the language of the last session.** Over all 803
pairs (160 with code 0x0101):

| Value | 0x0101 | Other codes |
|---|---|---|
| Spread `FlattenerPreference` resolutions, no chunk 0x10833 | 400, 400 | 300, 150 |
| `IndexOptions` `BetweenEntriesSeparator`, no chunk 0x13010 (`preferences.md`) | `、` in 157 of 159 | `; ` in 632 of 632 |
| `IndexOptions` `Title`, no chunk 0x13010 | `索引` in 158 of 159 | `Index` in 624 of 632, and `Indice`, `Rejstřík`, `Índice`, `Указатель` |
| `EndnoteOption` `EndnoteSeparatorText` and `EndnoteMarkerPositioning`, no chunk 0x2261E (`footnotes.md`) | U+3000 and `RubyMarker` in 17 of 18 | tab and `SuperscriptMarker` in 123 of 123 |
| `EndnoteOption` `EndnoteTitle`, no chunk 0x2261E | `文末脚注` (15, DOM 13), `後注` (2, DOM 19 and 20), `Endnotes` (1) | `Endnotes` in 93 of 123, and 4 other titles |
| `Assignment` `Name` | `$ID/UnassignedInCopy` in 157 of 160 | `$ID/UnassignedInCopy` in 612 of 643 |

One trustworthy pair from version 16.1 has code 0x0101 but the values
of another language in every row (flattener 300 and 150 on its 9
spreads, `Index`, `; `, tab, `Endnotes`). Its IDML is dated 55.5 hours
after the last session in the INDD, while the IDMLs of 9 other 0x0101
documents are dated 0 to 40 seconds after it (plus their time zone).
So that IDML was exported in a session the INDD does not record, by an
application of another language.

The converter uses the code where it decides the value: the flattener
resolutions, the index separator and the endnote separator. The index
title, the endnote title and marker position and the unknown user
follow the saving edition (below). It writes no assignment `Name`:
names that are not `$ID/UnassignedInCopy` occur with every code.

**Saving edition (the XMP black name).** The XMP packet of the INDD
lists the document's colours in `xmpTPg:Colorants`, each with
`xmpG:swatchName`, `xmpG:mode`, `xmpG:type` and its values (`cyan` to
`black` in percent, `red`, `green`, `blue` 0 to 255). Tints have an
`xmpG:tint` and keep the stored name of their base colour. The black
swatch is listed with the name the InDesign that saved the document
gives it: `Black`, `검정`, `黒`, `黑色`, `Schwarz`, `Noir`, `Nero`,
`Zwart`, `Černá`, `Preto`, `Черный`. The converter takes as the black
name the `swatchName` of the one colorant that is not a tint, is a
process colour, has the mode and values of the document's black colour
(`Color/Black`, as IDML writes its values) and whose name no other
colour of the document has. Over the 1,251 trustworthy pairs of the
corpus after 2026-10 there is exactly one such colorant in each: 502
`검정`, 431 `Black`, 126 `黒`, 93 `黑色`, 45 `Schwarz`, 44 `Noir`, 4
`Nero`, 3 `Zwart` and one each of `Černá`, `Preto` and `Черный`.

This is a rule over stored data: the packet records the edition of the
last save, and IDML follows the edition that exported it. Where a
document was exported by another installation than the one that saved
it last, the IDML has the other edition's values; the exceptions below
are such documents.

IDML writes these values in the language of that edition:

| Black name | Tint of black | Unknown user | Endnote title (no chunk 0x2261E) | Index title (no chunk 0x13010) |
|---|---|---|---|---|
| `Black` | `[Black] 40%` | `Unknown User Name` | `Endnotes` | `Index` |
| `검정` | `[검정] 40%` | `알 수 없는 사용자 이름` | `미주` | `색인` |
| `黒` | | `不明なユーザー名` | `文末脚注` (DOM 13), `後注` (DOM 19, 20) | `索引` |
| `黑色` | `[黑色] 40%` | `不明的使用者名稱`, `未知用户名` | | `索引` |
| `Schwarz` | `[Schwarz] 40%` | `Unbekannter Benutzername` | `Endnoten` | `Index` |
| `Noir` | `[Noir] 40%` | `Nom d'utilisateur inconnu` | `Notes de fin` | `Index` |
| `Nero` | | `Nome ut. sconosciuto` | `Note di chiusura` | `Indice` |
| `Zwart` | | `Onbekende gebruikersnaam` | `Eindnoten` | `Index` |
| `Černá` | | `Neznámé jméno uživatele` | | `Rejstřík` |
| `Preto` | | `Nome de usuário desconhecido` | | `Índice` |
| `Черный` | | `Неизвестное имя пользователя` | | `Указатель` |

An empty cell has no sample. The endnote marker is `RubyMarker` for
`黒` and `SuperscriptMarker` for every other black name.

With these rules the converter reproduces, over the trustworthy pairs:

| Value | Reproduced | Before (assignment name and code rules) |
|---|---|---|
| `Tint` elements and their names (tints of black) | 204 of 204 tints, no extra tint | 171, and 409 extra values in 27 documents |
| `DocumentUser` `UserName` | 3,208 of 3,212 | 3,000 |
| `EndnoteOption` `EndnoteTitle` | 917 of 918 | 692 (no title without the chunk) |
| `EndnoteOption` `EndnoteMarkerPositioning` | 916 of 918 | 876 |
| `IndexOptions` `Title` | 1,250 of 1,251 | 1,162 |

The remaining differences are the 16.1 document above (exported by
another edition: three users, its endnote title and its index title),
one 20.0 document whose black name is `Black` but whose IDML writes the
German name of the unknown user as `$ID/Unknown User Name` (two users),
and DOM 7 documents whose IDML lists one user more than the INDD. In 8
stale pairs the rule loses 1 to 3 values each: their IDML was exported
by another edition than the one that saved the INDD later (for example
a Dutch endnote title in a document whose last save has `Black`).

Not explained by the black name: `BaselineFrameGridColor`,
`ColumnGuideColor`, the grid and gutter defaults and the print marks of
the Korean documents with code 0x0101 whose IDML has the values of a
Roman edition (`preferences.md`, values of the exporting edition), the
language quotes and the trimmed language lists.

## Spreads (0x501) and master spreads (0x1401)

| Chunk | Contents |
|---|---|
| 0x503 | u32 self, u32 0, UID list of spread layers |
| 0x56E | Matrix: `ItemTransform` |
| 0x1B8 | u32: `BindingLocation` |
| 0x1A8 | u16: 0 = `AllowPageShuffle="true"`, 1 = `false` |
| 0x10833 | Flattener settings (below) |
| 0x14580 | Tab orders: u32 count, then per page u32 page UID and a UID list (the page's `TabOrder`) |
| 0x140D | Master spreads: u16, 0 = `ShowMasterItems="false"` |
| 0x140A | Master spreads: u32 story of the primary text frame (below) |
| 0x2050C | Page transition (12 bytes): u32 type code, u32 40, u32 direction code (below) |
| 0x2056D | Timing lists (animation and timing, below) |

Evidence, over the 5,129 spreads and 914 master spreads of the 495
trustworthy pairs:

- `AllowPageShuffle`: 0x1A8 is 0 in 5,064 spreads, all `true`, and 1 in
  53, all `false`. The 12 spreads without the chunk (in 7 documents) are
  all `false`.
- `ShowMasterItems` of master spreads: 913 have no chunk 0x140D and are
  `true`; the one with the chunk (0) is `false`.
- `PrimaryTextFrame` of master spreads, over all pairs of the corpus of
  2026-10: IDML writes `n` when chunk 0x140A is absent (1,471 master
  spreads) or holds 0 (6). Otherwise it names the text
  frame on that master spread whose `ParentStory` is the chunk's story
  and whose `PreviousTextFrame` is `n` (50 of 50; in 40 of them the
  story has a second frame on the spread, which is not the primary
  one). IDML of DOM 7 has no `PrimaryTextFrame` (9 master spreads). The
  attribute is the last one of `MasterSpread`. The converter writes it
  from DOM 8 and leaves it out when the spread has no such frame: 1,521
  of 1,521 values over all pairs with the same major version.
- `TabOrder` of pages: the list for the page in its spread's chunk 0x14580
  equals the IDML list for 9,367 of 9,367 pages (8 with a tab order);
  pages not in the chunk have an empty `TabOrder`.

**Page transitions.** Chunk 0x2050C gives `PageTransitionType` and
`PageTransitionDirection`. Over the 11,676 spreads of the distinct
little-endian pairs with the same major version (corpus after 2026-10):

| u32 at 0 | `PageTransitionType` | u32 at 8 | `PageTransitionDirection` | Spreads (documents) |
|---|---|---|---|---|
| no chunk | `None` | | `NotApplicable` | 11,646 (1,453) |
| 0 | `None` | 0 | `NotApplicable` | 12 (2) |
| 0x205C8 | `BlindsTransition` | 0xB | `Horizontal` | 8 (4) |
| 0x205CA | `CombTransition` | 0xB | `Horizontal` | 2 (2) |
| 0x205CC | `DissolveTransition` | 0 | `NotApplicable` | 4 (4) |
| 0x205CF | `PushTransition` | 1 | `Down` | 2 (2) |
| 0x205D0 | `SplitTransition` | 0xD | `HorizontalIn` | 2 (2) |

The u32 at 4 is 40 in every chunk, and every spread has
`PageTransitionDuration="Medium"` (`idml-values.md`), so the field is
not mapped. Master spreads have neither the chunk nor the attributes
(2,395 of 2,395). The converter writes the two attributes on
spreads for these codes, and leaves out an attribute whose code is not
in the table.

**Flattener settings.** Every IDML spread has a `FlattenerPreference`
child. Chunk 0x10833 (52 bytes) is in 20 spreads of 5 trustworthy
documents, always with the same bytes: f64 0.5 at offset 8, f64 400 at
offsets 20 and 28, 2 at 36 and 800 at 44. Their IDML has
`LineArtAndTextResolution` and `GradientAndMeshResolution` 400 and
`RasterVectorBalance` 50. In the corpus of 2026-10, 182 spreads of 20
trustworthy documents store 150 at 20 and 300 at 28, and their IDML has
`LineArtAndTextResolution="300"` and `GradientAndMeshResolution="150"`
(182 of 182): the f64 at 28 is `LineArtAndTextResolution` and the f64 at
20 `GradientAndMeshResolution`. Without the chunk, the IDML has 400 and 400 when the
last session of the save history (document, above) has code 0x0101,
and 300 and 150 otherwise: 7,481 of the 7,490 spreads of all 803 pairs
match, the other 9 being the spreads of the pair exported in a
session the INDD does not record. No stored resolution decides it: the
bytes of 400 as f64 occur in 1 of the 10 such documents of the 654
pairs before 2026-10, and no byte of the spread chunks separates the
two groups. The converter writes the resolutions by this rule, and
none when the history cannot be read. The other four values are the
same in every IDML (`idml-values.md`).

**Spread layers (0x301)** hold the items of one document layer on one
spread. Chunk 0x302: u32 document layer UID, u16 1 for the layer's guide
part. Chunk 0x303: u32 spread, u32 spread, UID list of children. Pages are
children of the spread layer for the internal pages layer.

## Guides (0x3301)

Ruler guides are objects of class 0x3301. They are children of a spread
layer (listed in its chunk 0x303), like page items, and their chunk 0x15B
names the spread and the spread layer. The spread layer's document layer
is IDML `ItemLayer`. IDML writes a guide as a `Guide` element inside a
`Page` element. Chunk 0x3308 (52 bytes):

| Offset | Contents | IDML |
|---|---|---|
| 0 | f64 position in spread coordinates: y for a horizontal guide, x for a vertical one | `Location` (below) |
| 8 | u32 owner: a page of the spread, or the spread itself | the `Page` element the guide is in |
| 12 | u16 orientation: 1 horizontal, 0 vertical | `Orientation` |
| 14 | f64, 0.05 in every sample | `ViewThreshold="5"` in every sample |
| 22 | u32, 6 in every sample | `GuideColor` `Cyan` in every sample |
| 26 | u16 fit to page: 1 true, 0 false | `FitToPage` |
| 28 | f64, not identified | |
| 36 | u32, not identified (24, 25, 30 or 31) | |
| 40 | u32 guide type: 0 ruler, 1 liquid | `GuideType` (`Ruler`, `Liquid`) |
| 44 | f64, 1 in every sample | |

**Evidence.** The 137 distinct little-endian files hold 847 guides; 815
have this 52-byte record. The other 32 are in one InDesign 7.0 file with
no IDML and have a 40-byte record, the first 40 bytes of the layout
above; the InDesign 3.0 and 4.0 files have it too (`big-endian.md`). The
converter reads it and leaves out `GuideType`. In the corpus pairs, 71 IDML guides in 33 distinct files have an
INDD object with the same UID. Two more pairs have the same number of
guides on both sides but different UIDs (the IDML was exported from
another save) and are not used. For the 71:

- `Orientation`: 71 of 71 (50 horizontal, 21 vertical).
- `FitToPage`: 71 of 71 (49 true, 22 false).
- `GuideType`: 71 of 71 (59 ruler, 12 liquid).
- `ItemLayer`: 71 of 71.
- Owner: the 49 guides owned by a page are in that page's element, the
  22 owned by the spread are in the spread's first page (71 of 71). All
  22 spread guides have `FitToPage="false"` and all 49 page guides
  `FitToPage="true"`.
- The view threshold and colour have one value each in the INDD and in
  IDML, so the fields are not proven. The converter writes
  `ViewThreshold="5"` only for 0.05 and `GuideColor` `Cyan` only for 6.

**Location.** IDML measures `Location` from the ruler origin
(`ViewPreference` `RulerOrigin`, chunk 0x808 of the preferences,
`preferences.md`). It is the stored position minus the origin's y
(horizontal guides) or x (vertical guides). A page's corner is its
`GeometricBounds` corner mapped by its `ItemTransform`. The origin is:

- `SpreadOrigin`: the top-left corner of the spread's pages (the
  smallest left and top edge of any page).
- `PageOrigin`: the top-left corner of the guide's own page; for a
  guide of the spread, the corner of the spread's pages as with
  `SpreadOrigin`.
- `SpineOrigin`: for vertical guides on a spread of two pages, the left
  edge of the right page (x = 0 in the samples); otherwise as with
  `SpreadOrigin`.

IDML computes the difference after adding the spread's translation
(`ItemTransform` of the spread) to both values:
`(position + t) − (origin + t)`. This only changes the last bits, but
it decides whether a guide on the origin gets 0 or a remainder such as
−1.1e-13. Over the 1,252 trustworthy pairs it gives the IDML number
exactly for 8,580 of the 9,127 guides in `SpreadOrigin` documents
(7,782 without the translation); the others differ only in the last
digits.

**Evidence.** All 553 guides of the 23 trustworthy pairs with
`PageOrigin` follow the rule: 435 page guides (304 horizontal, 131
vertical, on spreads of one, two and five pages) and 118 spread guides
(116 horizontal, 2 vertical on one-page spreads). The 9,127 guides of
`SpreadOrigin` documents follow it but for 25 (below), including pages
whose bounds do not start at 0. The one `SpineOrigin` file (a stale
pair, InDesign 15.0) has three vertical guides: on a two-page master
spread at stored −552.76 and 42.52 with IDML −552.76 and 42.52 (from
x = 0), on a one-page master spread at stored 0 with IDML 297.64 (from
the page's left edge at −297.64); its horizontal guides are measured
from the top of the pages. No spread of more than two pages with
`SpineOrigin` was seen.

**Guides at the spread origin.** In 5 trustworthy pairs (InDesign
17.0, one collection), 5 guides each that belong to a page with
`FitToPage="true"` have `Location` values that put them at 0 in spread
coordinates: vertical guides stored at −457.14 and −58.47 get the
spine's position, a horizontal guide stored at −9.92 gets y = 0. The
stored positions lie inside their pages. No field of the guide record
or the guide's other chunks separates them from the other guides of
the same documents (`unknowns.md`). The converter writes the stored
position.

**Spread guides outside the pages.** IDML leaves out a guide owned by
the spread when its position lies outside the bounding box of the
spread's pages (each page's corners mapped by its `ItemTransform`; the
bleed does not count): for a horizontal guide when its y is above the
top or below the bottom, for a vertical one the same with x. Over the
489 trustworthy pairs before 2026-10: 84 of 85 such guides are left out
(positions such as −15, −66 or 1215 on pages 1200 wide), all 1,198
spread guides inside are written, and all 5,740 page guides are written
wherever they are. With the bleed added, 30 of the left-out guides
would be inside. The exception is a horizontal guide at −9 on a master
spread, which IDML writes; its object has chunks 0x1424 and 0x1425,
which no left-out guide has. The converter leaves out such guides
(with a tolerance of 1e-6).

**Other settings.** A guide has chunks 0x2C2D (`Locked`) and 0x1424
(`OverriddenPageItemProps`) as page items do (`Page item settings`),
and the f64 at offset 44 of the 52-byte record is `GuideZone`. Over the
7,003 guides of the trustworthy pairs: `Locked` 7,003 of 7,003 (3
locked), `GuideZone` 6,988 of the 6,988 with a 52-byte record (464 with
0), `OverriddenPageItemProps` 6,988 of 6,988; the 15 guides with a
40-byte record have neither attribute in IDML.

`PageIndex` counts from the spine of the spread: 0 for a guide of the
spread itself; for a page guide, the pages left of the spine are −1,
−2, … (counting outwards) and those right of it 1, 2, …, the spine being
after `BindingLocation` pages; on master spreads it is at the left edge.
This gives 6,998 of 7,003 (1,215 spread guides 0; 2,266 of 2,269 page
guides on document spreads, 473 of them −1 and 12 −2;
3,517 of 3,519 on master spreads).

## Layers (0x302)

Chunk 0x304:

| Offset | Contents | IDML |
|---|---|---|
| 0 | u16 | `Locked` (1 = true) |
| 2 | u16 | `Visible` |
| 4 | u16 | `Printable` |
| 6 | u16 | `LockGuides` |
| 8 | u16, 1 in every sample | |
| 10 | u32 UID of an interface colour | `LayerColor` (below) |
| 14 | u16 | `UI` |
| 16 | u16, 1 in every sample | |
| 18 | u8 flag, in-object string | `Name` |
| after the name | u16 | `IgnoreWrap` |

The internal layer is the first UID of the document's layer list
(chunk 0x301 of UID 1) and has no IDML element: in 489 of 489
trustworthy pairs that layer is not written. It is usually named
`Internal_pages_layer_name` (467), but also `Pages` (20) or has an empty
name (2), so the name does not identify it. In all 1,053 layers of the trustworthy pairs the name starts at
offset 19, and each field above equals the IDML value for 1,053 of 1,053
layers (127 locked, 55 hidden, 59 not printable, 4 with locked guides,
1 without `UI`, 2 ignoring text wrap). In the corpus of 2026-10, the
string at offset 19 gives the IDML `Name` of 1,683 of 1,683 layers in
all pairs, whatever its second byte (in the trustworthy pairs, 188
layers have a byte other than 0, all with the IDML name). The converter reads the name at offset 19 when byte
19 is the string tag, and otherwise searches for a string from offset
18. `ShowGuides` and `Expendable` are
true in every layer; the two fields that are 1 in every sample may hold
them. The converter reads the fields only when the name starts at offset
19 (in all little-endian corpus pairs, 1,465 layers).

## Pasted smooth shades (0x5533)

Objects of class 0x5533 hold shadings. Chunk 0x5531: a flag byte (1 =
built-in key) and the name, then a u32. Chunk 0x5532 holds the shading;
a constant shade has 92 bytes, with u32 28 (the length of what follows)
at offset 60, then a u32 and three f64. IDML writes it as a
`PastedSmoothShade` with `ContentsType="ConstantShade"` and `Contents`
the base64 of the same u32 and three f64 in big-endian order
(`AAAAAUBv4AAA…` for 1 and 255, 0, 0).

Every trustworthy pair has one constant shade in IDML, and it is the
class 0x5533 object of lowest UID with a constant shade (495 of 495);
in 84 pairs the INDD has two more that IDML leaves out. The converter
writes that one shade, and matches the IDML on all values in 495 of
495 (name `$ID/` from flag 1 and an empty name; two contents values,
255 and 1).

**Axial shades.** Chunk 0x5532 in general: u32 0 at 0; six f64 at 4 (a
matrix); u32 0 at 52; u32 shading type at 56; u32 *n* at 60; *n* bytes
of shading data from 64, to the end of the chunk. A constant shade has
type 0 and *n* = 28. Type 5 is an axial shade, which IDML writes as
`ContentsType="AxialShade"` with `ContentsMatrix` the six f64 and
`Contents` the base64 of the shading data with every field converted to
big-endian. The data is a sequence of fields:

```
shading:
  f64 ×6                      coordinates
  u16 ×4                      (0 or 1)
  u32 colour space            (2 in every sample)
  u32 function count F
  function ×F
  u32                         (4 in every sample)
  f64 ×6
  u32                         (2 in every sample)
  u16 ×2                      (0 or 1)
function:
  u32 function type           (0 in every sample)
  u32 inputs, u32 outputs     (1 and 1 in every sample)
  u16, u32 c, f64 ×2c         domain
  u16, u32 c, f64 ×2c         range
  u32, u32 c, f64 ×2c         encode
  u32 c, f64 ×2c              decode
  u16
  u32, u32 bits per sample (8 in every sample), u32 byte count B
  u8 ×B                       samples, not swapped
```

Over all pairs of the corpus of 2026-10 the INDD files hold 3,725 axial
shades (3,704 in 37 trustworthy pairs); the grammar consumes every chunk
to its end. IDML has 900 axial shades (891 in 12 trustworthy pairs), and
the converter's `Contents`, `ContentsMatrix` and other attributes equal
IDML's for all 900. The name chunk is that of constant shades (`$ID/`).
The other attributes are those every IDML has on an axial shade
(`idml-values.md`), and `SwatchColorGroupReference` from DOM 12 as for
other swatches. Type 6 also occurs (43 objects in trustworthy pairs);
IDML writes none of them, so its layout is not needed. A shading with
another value where the grammar names the value of every sample, or with
bytes left over, is left out with a warning.

**Which axial shades IDML writes.** The rule of unnamed colours (colours,
below): a shade is written when a value in the package refers to it, or
when the page item defaults name it (chunk 0x6E07 or entry 0 of chunk
0x6E06, by class 0x5533). In the trustworthy pairs IDML writes 891 of
the 3,704 axial shades, all 891 that the rule selects and none of the
other 2,813. Of the 891, 884 are referred to by a page item's
`FillColor` (attribute 0x6E68 of the item's chunk 0x6E03 holds the
shade's UID; 744 rectangles of spreads and 140 of master spreads) and 7
are named by the defaults only. All references are rectangle fills.

**Order.** In `Graphic.xml` the shades follow the inks in UID order (the
constant shade has the lowest UID), before `Swatch/None`: 12 of 12
trustworthy pairs with axial shades.

## Index sort options

Chunk 0x1307E of the preferences object (class 0x2202) holds the index
groups. A "string" is a flag byte and an in-object string; a "u32
string" is a u32 length in UTF-16 units and text segments.

```
u32 group count
group:
  string     group name (kIndexGroup_Symbol, kWRIndexGroup_GreekAlphabet, ...)
  u8         include
  u8         (not identified)
  u16        header variant
  u16        (not identified)
  u32        variant count
  variant:
    string      internal name
    string      UI string
    u32 string  document string
    u8          1 = visible
    u8          (0)
    u32         section count
    section:
      u32 string  sorting string
      u32 string  document header string
      string      UI header string
      u16         language
```

Every chunk of the 654 pairs parses to its end with this layout. The
variants and sections have the same fields as the list that IDML writes
under `IndexHeaderSetting` (`preferences.md`), which the converter takes
from chunk 0x1300E. The converter uses the name, include byte and header
variant of each group, and the internal name of the variant that the
header variant indexes in the group's variant list.

IDML writes an `IndexingSortOption` per group, in the stored order:
`Self` `dIndexingSortOptionn` and the name, `Name` `$ID/` and the name,
`Include`, `Priority` (the position, from 0) and `HeaderType`, which
follows the internal name of the chosen variant:

| Variant name | `HeaderType` |
|---|---|
| `IDX_Basic` | `BasicLatin` |
| `IDX_Spanish` | `Spanish` |
| `IDX_Czech` | `Czech` |
| `IDX_Russian` | `Russian` |
| `IDX_AllHira` | `HiraganaAll` |
| `IDX_ChinesePinyin` | `ChinesePinyin` |
| `IDX_ChineseStroke` | `ChineseStrokeCount` |
| `IDX_KoreanConsonant` | `KoreanConsonant` |
| the group's own name (symbol, numeric, Greek, Arabic and Hebrew groups) | `Nothing` |

The converter leaves `HeaderType` out for other names. Evidence: the
495 trustworthy pairs before 2026-10 have 11 different lists (8 or 10
groups, in different orders, with different groups included). Over the
1,251 trustworthy pairs of the corpus after 2026-10 the converter
reproduces all 12,472 `HeaderType` values. The variant index decides
where the list order differs: the Chinese group has variant 0 in every
file, but in 83 documents its list starts with `IDX_ChineseStroke`, and
their IDML has `ChineseStrokeCount` (83 of 83); a table by group and
variant number, used before, gave `ChinesePinyin` there. Over all 654
pairs before 2026-10 the Alphabet variant is 0 in 652 files, 3 and 5 in
one each, and the Cyrillic variant is 2 in all.

## Numbering lists (0x1A483)

Chunk 0x1A49B of the preferences object: u32 UID of the default list,
u16 count *n*, *n* list UIDs, i32 −1. Each list has chunk 0x1A49A: a
flag byte (1 for a built-in key; 0 and 2 plain) and the name, then u8
`ContinueNumbersAcrossStories` and, two bytes after the name, u8
`ContinueNumbersAcrossDocuments` (1 `true`); the rest is not identified.

IDML writes one `NumberingList` per list in `designmap.xml`, the default
(`$ID/[Default]`) first, then the *n* lists in stored order, with
`Self` `NumberingList/` and the name. The paragraph attribute 0x1A417
(`AppliedNumberingList`, a `Properties` child of type `object`) is the
UID of a list. Evidence: 705 of 705 lists of the trustworthy pairs
(953 of 953 in all pairs), names, both flags and order;
`AppliedNumberingList` 519 of 519 paragraph styles and 489 of 489 text
defaults.

## Assignments (0x1BE01)

Every document has one object of class 0x1BE01, listed in chunk 0x1BE13
of the document; IDML writes it as an `Assignment` with `Self` its UID
(495 of 495 trustworthy pairs). Chunk 0x1BE1B starts with a flag byte
and the name in the language of the edition the document was made with
(`Unassigned InCopy Content`, `Contenu InCopy non affecté`, …; the
converter uses it for values of that edition, `preferences.md`), then two empty
strings and fields that are the same in every pair. IDML names it
`$ID/UnassignedInCopy` in 476 pairs and gives the stored name in 19, in
files of several languages and versions, so the name follows the
computer that exported the IDML; the converter leaves `Name` out (it is
optional in the schema) and the measurement too. The language code of
the save history does not decide it either (document, above). The other
attributes are the same in every IDML (`idml-values.md`).

## Articles (0x21B01)

**Article list.** Chunk 0x21B03 of the document object: u32 count, then
that many article UIDs. IDML writes one `Article` element in
`designmap.xml` per listed UID, in list order (not UID order).
Evidence: the 19 pairs whose IDML has `Article` elements or
`ArticleChildrenList` (DOM 8.0, 10.1, 13.x, 20.5): the list order equals
the IDML order for all 31 articles; the chunk is in all 19 (count 0 in
the 6 with no articles), and its length is exactly 4 + 4 × count. In
all 66 corpus INDD files that have article objects (INDD 7.5 to 21.2,
203 articles), the list holds exactly the document's 0x21B01 objects.

**Article object.**

| Chunk | Layout | IDML |
|---|---|---|
| 0x13C | flag byte, in-object string | `Name` |
| 0x21B02 | u32 count, then that many page item UIDs | one `ArticleMember` per UID, in order, `ItemRef="u<hex>"` |
| 0x1A8 | u16 | not mapped (below) |

- `Self` is `u<hex UID>`: 31 of 31 in pairs.
- Name: the flag byte is 2 in all 203 articles of the corpus, and the
  string ends at the chunk's end in all 203. 31 of 31 names match in
  pairs (Latin, Hangul and Han text; segments with 0x40 and 0x80
  encodings).
- Members: 31 of 31 lists match the IDML `ArticleMember` `ItemRef`s in
  order. Without chunk 0x21B02 (2 articles) or with count 0 (2 in
  pairs), the IDML `Article` has no children. In the corpus, members
  are page items (class 0x6201) or groups (0x401); no other class
  appears (201 lists).
- `ArticleMember` `Self` is the article's `Self`, `ArticleMember`, and
  the member's index from 0: `u281ArticleMember0`, `u281ArticleMember1`.
  44 of 44 members in pairs. No corpus IDML has an article with more
  than 10 members, so whether the index is decimal or hexadecimal is not
  shown; the converter writes it in decimal.
- `ArticleExportStatus` is `true` on every `Article` of every corpus
  IDML (31 in pairs; no other value in 3,557 IDML files). No stored
  field is identified; the converter writes `true` (`idml-values.md`,
  defaults).
- Chunk 0x1A8 (u16) is in 50 of 203 articles: 1 in 47, 0 in 3. The one
  in a pair has 1 and `ArticleExportStatus="true"`, as do the articles
  without the chunk; it is not mapped.
- No corpus IDML has an `Article` `Properties/Label`, so an article's
  label chunk is not shown.

**Page items.** Chunk 0x21B04 of a page item or group: u32 count and the
UIDs of the articles the item is a member of. 44 of 44 members in pairs
have count 1 and their article's UID; 331 other items have count 0. IDML
has no attribute for it; the converter does not read it.

**`ArticleChildrenList` on groups.** Chunk 0x21B05 of a group (class
0x401): u32 count, then UIDs. IDML `Group` has
`ArticleChildrenList="u<hex> u<hex> …"` with these UIDs in order,
exactly when the group has the chunk: 68 of 68 groups in 12 pairs; no
group has the attribute without the chunk or the chunk without the
attribute. The list is the group's children in reverse order of chunk
0x15B in 68 of 68 groups in pairs and 259 of 259 in the files with
articles. Groups with the chunk also occur in documents without
articles (4 pairs of 13.x). IDML writes the attribute directly after
`Self` (68 of 68).

**Element order.** In `designmap.xml` the `Article` elements come last,
after `Assignment` (all 13 pairs with articles). The schema puts
`Article` in the final interleaved group with `Assignment` and others,
so writing them after the assignments is valid. `Article` allows
`Self`, `Name`, `ArticleExportStatus`, `Properties/Label`, then
`ArticleMember*` (`Self` and `ItemRef`, both required).

**Versions.** Article objects occur in INDD 7.5 to 21.2. Pairs show DOM
8.0, 10.x and 20.x; no 7.x INDD with articles has an IDML. The
converter writes articles for every version.

**Damaged input.** The converter writes each listed article once and
skips listed UIDs that are not articles. An article without a readable
name or member list is left out with a warning. A member that is not
written as a page item element is left out with a warning, and so is an
`ArticleChildrenList` UID that is not a child of the group.

## Named grids (0xCD12)

Chunk 0xCD28: u32, a flag byte (1 = built-in key) and the name
(`[Page Grid]`, IDML `$ID/[Page Grid]`). IDML writes a `NamedGrid` per
object, in UID order, with a `GridDataInformation`:

- A grid made by the user has its own chunk 0xCD02, with the layout of
  the page chunk (layout grid, below), and IDML writes those settings.
- The built-in `[Page Grid]` has only chunk 0xCD28. Its
  `GridDataInformation` equals the document's layout grid preference
  (`LayoutGridDataInformation`, chunk 0xCD2F, `preferences.md`) in every
  attribute that preference has: 803 of 803 pairs of the corpus of
  2026-10 (606 trustworthy). It does not always equal the pages' grid:
  4 of the 574 trustworthy pairs whose pages all have the same grid
  differ.

The converter writes each named grid with its own settings, or with
the layout grid preference. Over all pairs: 876 of 876 named grids, and
every attribute of their `GridDataInformation` (`AppliedFont` 875: one
family that IDML names in another form, `fonts.md`); 38 pairs have
grids made by the user (2 or 3 named grids).

**Applied named grid (chunk 0xCD32).** A story (class 0x201) or object
style (class 0x1B901) that uses a named grid has chunk 0xCD32: u16 1,
then the UID of the named grid object (6 bytes). An object style can
also have u16 0 (2 bytes). IDML writes `AppliedNamedGrid` as the grid's
`Self` (`NamedGrid/<name>`, `NamedGrid/$ID/[Page Grid]` for the
built-in grid), and `n` for u16 0 or without the chunk. Evidence over
all pairs of the corpus of 2026-10, compared by `compare.py`:

- Stories: 26,805 of 26,805 (19,424 of 19,424 in the trustworthy
  pairs). 106 IDML stories name a grid made by the user (two grids, in
  13 pairs of version 12.1), and their INDD stories have the chunk with
  that grid's UID.
- Object styles: 3,515 of 3,515 (2,661 of 2,661 trustworthy). 55 name
  `[Page Grid]` (u16 1); the others have u16 0 or no chunk and `n`,
  among them all root styles `[None]` but one, which names
  `[Page Grid]`.

Over the whole little-endian corpus, every story chunk 0xCD32 has 6
bytes, u16 1 and the UID of a named grid object. The converter writes
`n` for u16 0 or no chunk, and the grid's `Self` for u16 1 with the UID
of a named grid of the document; otherwise it leaves the attribute out.

## Table of contents styles (0x11605)

Chunk 0x11605: a flag byte (1 = built-in key) and the name, a u16 (0 in
every style), a u16 `IncludeBookDocuments` and a u32 `CreateBookmarks`
(1 = true), the u32 UID of the title's paragraph style, a flag byte and the
title, a flag byte and a string not identified, then u16 fields: at 0
`SetStoryDirection` (0 `Horizontal`, 1 `Vertical`), at 2
`NumberedParagraphs` (0 `IncludeFullParagraph`, 2 `ExcludeNumbers`), at
4 `MakeAnchor` and at 6 `RemoveForcedLineBreak` (1 = true; the chunk of
older files ends before the fields IDML does not have yet), then the
entries. IDML writes one `TOCStyle` per object in `Styles.xml`.

A story made by a table of contents has chunk 0x8C40, the UID of an
object of class 0x8C20 whose chunk 0x11613 is the TOC style; IDML writes
that style as the story's `AppliedTOCStyle`, and `n` for other stories.

Evidence over the trustworthy pairs: the 511 TOC styles the converter
writes match on `Name`, `Title` and `TitleStyle` (511 of 511),
`NumberedParagraphs` (511, one `ExcludeNumbers`), `SetStoryDirection`
(620 of 620 in the corpus of 2026-10; over all its pairs 823 of 824, 2
`Vertical` in two pairs of version 18), `MakeAnchor` (445 of
445 from DOM 9 on, 4 true) and `RemoveForcedLineBreak` (340 of 340 from
DOM 13 on, 4 true); `AppliedTOCStyle` matches for 18,923 of 18,923
stories (21 made by a table of contents). `IncludeBookDocuments` and
`CreateBookmarks` match all 1,520 TOC styles of the corpus of 2026-10
whose IDML style has the same name (1,304 trustworthy; 15 with
`IncludeBookDocuments="true"`, one with `CreateBookmarks="false"`, in a
stale pair). The flagged string after the title is the path of a book
file in some of these styles, but it does not decide
`IncludeBookDocuments`. 

**Entries.** After the u16 fields (two before version 9, three before
13, four from 13) the chunk holds a u16 entry count and the entries:

| Field | IDML |
|---|---|
| flag byte, in-object string | `Name`: the paragraph style's name, with `$ID/` first for flag 1; the group separator U+E00B is written `:` |
| flag byte, in-object string | a document path; not in IDML |
| u32 | `FormatStyle`: paragraph style UID |
| u16 | `Level` |
| u16 | 0 in every entry of the pairs; 1 in some entries of files without a pair (not mapped) |
| u16 | `PageNumberPosition`: 0 `AfterEntry`, 1 `BeforeEntry`, 2 `None` |
| u32 | `PageNumberStyle`: character style UID |
| u32 *n*, segments | `Separator` |
| u32 | `SeparatorStyle`: character style UID |
| u16 | 0 in every entry |
| u32 *n*, segments | `; `, `;` or `、`; not in IDML |
| u16 | 1 in every entry |

IDML writes each entry as a `TOCStyleEntry` child of its `TOCStyle`:
`Self` is `u`, the TOC style's UID in hexadecimal, `TOCStyleEntry` and
the entry's index (0 to 5 in the samples, so whether the index is
hexadecimal is not shown), then
`Name`, `Level`, `PageNumberPosition`, `Separator`,
`SortAlphabet="false"` (every entry), and `Properties` with
`FormatStyle`, `PageNumberStyle` and `SeparatorStyle`: a user style as
`type="object"` and its `Self`; the root style as `type="string"`
`$ID/[No paragraph style]` or `$ID/[No character style]`; UID 0 as
`type="string"`, `$ID/kSameStyleWithBracket` for `FormatStyle` and
`$ID/[Same Style]` for the other two. `Separator` is `$ID/` and the text,
with tab written `^t`, U+0008 `^y`, line feed `^n`, U+2003 `^m` and
U+2014 `^_`.

Evidence: every TOC style with entries in the trustworthy pairs
(versions 8.0 to 21.3) parses to the end of the chunk with this layout,
and the converter reproduces all 255 `TOCStyleEntry` elements with all
their values: `Name`, `Level`, `PageNumberPosition`, `Separator`,
`SortAlphabet` and the three style properties, 255 of 255 each.
`SortAlphabet` is `false` in all; neither constant u16 can be shown to
hold it. A chunk whose entries do not parse to its end keeps its style
and loses its entries, with a warning.

Two TOC styles of the corpus pairs have another value at the
`SetStoryDirection` field: 0x40 with no `SetStoryDirection` in the IDML
(version 15.0) and 0xF6FC with `Horizontal` (a stale pair of version
12.0). The converter writes the attribute for 0 and 1 only.

## Languages (0x2D07)

Chunk 0x2D0F: a flag byte and the name (`English: USA`), a flag byte and
the primary name (`English`), a flag byte and the secondary name (`USA`,
often empty), u16 `Id`, then two vendors, each a flag byte, a u32 and a
string: first the spelling vendor, then the hyphenation vendor
(`Hunspell`, `Proximity`, `Duden`, `WinSoft`); last the locale
(`en_US`).

IDML lists the language objects in UID order as `Language` elements at
the start of `designmap.xml`: `Name`, `PrimaryLanguageName` and
`SublanguageName` are `$ID/` and the stored names, except that the
language named `Neutral` is `$ID/[No Language]` in all three. Evidence
over the trustworthy pairs: in 488 of 495 the IDML list equals the INDD
objects in that order; in the other 7 the INDD has 4 to 61 language
objects and the IDML lists only some of them (1 or 2), for no reason
found. For the 1,249 IDML languages the names and `Id` are equal in
1,249. `HyphenationVendor` is the second vendor and `SpellingVendor` the
first when their flag is 1 (1,146 and 1,166 of 1,249); otherwise the
stored string is empty or names a vendor the IDML does not show, and
IDML gives `$ID/`, `$ID/InDihyph` or a vendor such as `Hunspell` that
depends on the computer that exported it.

**Vendors without a stored name.** Over the 3,139 language objects of
the corpus of 2026-10 matched with an IDML `Language` by name, an empty
vendor (flag 0, u32 0x01000000, empty string) is written `$ID/` for every
language whose vendor of that kind is never stored with flag 1 anywhere
in the corpus: hyphenation 914 of 914 (847 trustworthy), spelling 894
of 895 (the other, in a stale pair, has `Hunspell`). For the languages
that have a stored vendor in some document, an empty vendor is written
as the exporting computer's dictionary (`Hunspell` 14 and 19, `Duden` 1
and 1, `$ID/` 1 and 1), which no stored value shows; the converter
leaves those out. The two lists of languages without a stored vendor:

- Hyphenation (33): `Albanian`, `Arabic`, `Byelorussian`, `Chinese: Hong
  Kong`, `Chinese: Simplified`, `Chinese: Taiwan`, `Chinese:
  Traditional`, `Icelandic`, `Japanese`, `Korean`, `Neutral`,
  `Vietnamese`, `cy_GB`, `en_US+Medical`, `eu_ES`, `fo_FO`, `fy_NL`,
  `ga_IE`, `gl_ES`, `gv_GB`, `ko_KR`, `la_VA`, `lb_LU`, `mk_MK`, `mn_MN`,
  `ms_MY`, `ne_NE`, `oc_FR`, `sr_RS`, `sr_RS-Cyr`, `sr_RS-Lat`, `tk_TM`,
  `uz_UZ`.
- Spelling (29): the same without `Arabic`, `Vietnamese`,
  `en_US+Medical` and `ko_KR`.

Two other hyphenation vendor flags occur: flag 3 with the text
`DefaultLinguistic` is written `$ID/` (24 of 24, Korean and Chinese:
Traditional), flag 10 with `InDihyph` is written `$ID/InDihyph` (2 of
2). Two spelling vendors with flag 1 and the text `InDitect` are
`Hunspell` in IDML; the converter writes the stored text for flag 1.

**Quotes (chunk 0x2D26).** 34 language objects of the corpus have a
second chunk 0x2D26: a flag byte, the language name as an in-object
string, then four UTF-16 units, the two single quotes and the two double
quotes. IDML writes them as `SingleQuotes` and `DoubleQuotes`: 34 of 34
(Japanese `‘’` `“”`, Romanian `‘’` `»«`, Hebrew `’’` `””`, Korean). Without
the chunk, the quotes come from observation (`idml-values.md`, language
quotes).

## Interface colours (0x1F11)

Layers, pages and XML tags name their colour by the UID of an object of
class 0x1F11. Chunk 0x1F01 of that object: u32 5 (RGB), u16 3, three f64
fractions. IDML writes the colour as one of its named colours, or, for
other colours, as a list of three numbers (0 to 255):

| Red, green, blue | IDML | Red, green, blue | IDML |
|---|---|---|---|
| 0.31, 0.6, 1 | `LightBlue` | 1, 0.6, 0 | `Gold` |
| 1, 0, 0 | `Red` | 1, 0.4, 0 | `Orange` |
| 0.31, 1, 0.31 | `Green` | 0, 0.33, 0 | `DarkGreen` |
| 0, 0, 1 | `Blue` | 0.6, 0.6, 1 | `Lavender` |
| 1, 1, 0.31 | `Yellow` | 0.67, 0.64, 0.71 | `Charcoal` |
| 1, 0.31, 1 | `Magenta` | 0.6, 0.2, 1 | `Violet` |
| 0, 1, 1 | `Cyan` | 1, 1, 1 | `White` |
| 0.5, 0.5, 0.5 | `Gray` | 1, 0.6, 0.8 | `Pink` |
| 0, 0, 0 | `Black` | 0.61, 0.87, 0.61 | `GridGreen` |
| 0.6, 0, 0 | `BrickRed` | 0, 0, 0.53 | `DarkBlue` |
| 0.6, 0.8, 0 | `GrassGreen` | 0.81, 0.51, 0.71 | `Lipstick` |
| 1, 0.71, 0.42 | `GridOrange` | 0.97, 0.35, 0.42 | `Fiesta` |
| 0, 0.6, 0.6 | `Teal` | 0.73, 0.73, 0.73 | `LightGray` |
| 0.48, 0.73, 0.85 | `GridBlue` | 1, 0.6, 0.6 | `Peach` |
| 0.6, 0, 0.2 | `Burgundy` | | |

Evidence: in the layers and pages of the trustworthy pairs every colour
object with these components has this name (1,107 layers and pages; from
491 `LightBlue` down to 1 `Teal`). The last four are from the guide,
grid and pasteboard colours of the preferences (`preferences.md`), where
every colour with these components has this name. Two other colours occur, 1, 0.4863,
0.651 (3 layers) and 0.9412 three times (1 layer); IDML writes them as
the lists 255, 124, 166 and 240, 240, 240, the components times 255.
The converter writes such a list for a colour whose components are whole
multiples of 1/255 and that is not in the table, and leaves the colour
out otherwise. XML tags use the table but no list, as before.

## Pages (0x50F)

| Chunk | Contents |
|---|---|
| 0x140F | u32 applied master spread, u16 (unknown), matrix `MasterPageTransform` |
| 0x5CC | Matrix: `ItemTransform` |
| 0x5DD | Four f64: left, top, right, bottom. IDML `GeometricBounds` is top, left, bottom, right. |

Files from InDesign 3.0 and 4.0 store the page transform and bounds in
chunks 0x151 and 0x154, and chunk 0x140F has no matrix
(`big-endian.md`).

**Page settings.**

| Chunk | Contents | IDML | Without the chunk |
|---|---|---|---|
| 0x1404 | u32 count; if not 0, a UID list of master page items and a UID list of their overrides | `OverrideList`: each item and its override (`n` for 0) | empty |
| 0xCD04 | 6 bytes: u32 at 0, then u16 | `GridStartingPoint` (u32: 0 `TopOutside`, 4 `CenterVertical`; below), `UseMasterGrid` (u16, 1 = true) | |
| 0x563 | u32, u32 code: 1 `Recenter`, 2 `ObjectBased`, 3 `Scale`, 4 `GuideBased`, 5 `UseMaster` | `LayoutRule` | `Off` |
| 0x5FF | u32: 0 `Nothing`, 1 `UseMasterColor`, else an interface colour | `PageColor` | `UseMasterColor` |

Evidence over the 9,366 pages (document and master pages) of the
trustworthy pairs that the converter writes: `OverrideList`,
`UseMasterGrid` and `PageColor` 9,366 of 9,366 each, `LayoutRule` 9,347
of the 9,347 pages that have it. Of the 9,367 IDML pages, 1,352 have
overrides and 2,445 `UseMasterGrid="false"`; 5,111 have no chunk 0x563
and `Off`, 4,117 `UseMaster`, 92 `ObjectBased`, 24 `GuideBased`, 3
`Recenter` and 1 `Scale`; 9,260 have no chunk 0x5FF, 44 code 1, 5 code 0
and 58 an interface colour. `LayoutRule` is in IDML from DOM 8 on (no
page of the DOM 7 files has it).

**Layout grid starting point.** The u32 at 0 of chunk 0xCD04 is
`GridStartingPoint`. Over all pairs of the corpus of 2026-10, 13,458 of
13,458 pages that the converter writes match (10,080 of 10,080 in the
trustworthy pairs): 13,430 have 0 and `TopOutside`, 28 have 4 and
`CenterVertical` (master pages in 14 pairs of version 18.4). Every page
in the corpus has the chunk. Codes 1, 5 and 6 occur only in files
without an IDML (versions 3, 6, 19 and 21), so their values are not
shown; the converter leaves the attribute out for them.
| 0x51A | Margins: four f64 (left, top, right, bottom), u16 own-margins flag |
| 0x528 | Columns: u32 count *n*, *n* f64 column edges, f64 gutter, u16 own-columns flag, u16, u16 column direction (1 vertical, 0 horizontal) |
| 0xCD02 | Layout grid (`GridDataInformation`, below) |

**Master spread colour.** IDML gives each `MasterSpread` a `PageColor`
property equal to the `PageColor` of its pages, which is the same for all
pages of a master in all 1,359 master spreads of the 654 pairs
(`UseMasterColor` in 1,326, a named colour or `Nothing` in the others).
The converter writes the pages' colour. Over all pairs this reproduces
1,352 of 1,352 compared values.

**Margins and columns.** IDML writes them as `MarginPreference`. The
column edges are `ColumnsPositions` (left and right edge of each column,
so `ColumnCount` is *n*/2), the gutter is `ColumnGutter`. A flag of 1
means the page has its own values. With 0, or without the chunk, the
page shows the values in effect on its master page: the page at the same
position, counted from the left by `ItemTransform`, in the applied
master spread, or that spread's only page. That master page can itself
take them from its own master. The stored values of such a page are
often stale.

Evidence: all 325 IDML pages of the same-version pairs that have an INDD
page with the same UID (document and master pages):

- Margins: 156 pages with flag 1 match their own values; 169 take them
  from a master page (146 directly, 23 through two or three masters) and
  match. 325 of 325. Without the rule, 72 pages with flag 0 differ.
- Columns, gutter and positions: 156 with flag 1, 169 from a master page,
  325 of 325. Without the rule, 83 differ.
- The order of the margins: the four values differ in many pages (for
  example 56.69, 42.52, 56.69, 56.69 with IDML `Top="42.51968503937008"`).

In the 250 distinct little-endian files, 2,246 pages hold 0x51A in 2,160
(34 bytes each, flag 0 or 1) and 0x528 in 2,211 (always 18 bytes after
the positions). The last u16 of 0x528 is the column direction: IDML
`ColumnDirection` is `Vertical` where it is 1 and `Horizontal` where it
is 0, taking it from the master page with the columns (above). Evidence:
9,274 of 9,274 pages of the trustworthy pairs (14 vertical, in 3
documents), 12,224 of 12,224 over all pairs. A page whose flag is 0
takes the direction from its master page: 44 such pages store 1 but have
horizontal columns in IDML, like their master pages.

**Layout grid (chunk 0xCD02).** u32 font family UID, a flag byte (1 =
built-in key, `$ID/`), the font style as an in-object string, five f64,
four u32. IDML writes `GridDataInformation`:

| Field | IDML | Evidence |
|---|---|---|
| Font family | `AppliedFont` (Properties, the family name) | 283 of 325 (below) |
| Font style | `FontStyle` | 325 of 325 (`Regular`, `Roman`) |
| f64 1 to 5 | `PointSize`, `CharacterAki`, `LineAki`, `HorizontalScale` (×100), `VerticalScale` (×100) | see below |
| u32 1 to 4 | `LineAlignment`, `GridAlignment`, `CharacterAlignment`; one not identified | see below |

In the first corpus the numbers were 12, 0, 9, 1, 1 and the codes 3, 0,
3, 1 in all 2,246 pages of the 250 distinct little-endian files, and all
832 `GridDataInformation` elements of the corpus IDML files had
`PointSize="12"`, `CharacterAki="0"`, `LineAki="9"`, scales of 100,
`LineAlignment="LeftOrTopLineJustify"` and `AlignEmCenter` for both
alignments. The numbers 12 and 9 occur once, so those fields were
located. The corpus of 2026-10 confirms them: pages with other sizes
(such as 9.2126 and 6.9094) are in many pairs typeset in Japanese, and
`PointSize` and `LineAki` match in 13,458 of 13,458 pages of all pairs.
Named grids made by the user (above) locate `CharacterAki`: 37 of them
over all pairs have a second f64 other than 0 (such as −0.354), and
their IDML has the same value in 37 of 37. With the
flag, `FontStyle` matches in all 13,458 pages (44 trustworthy pages have
flag 1 and IDML `$ID/` before the style). The scales and the codes
still have one value only: the converter writes the scales only when
they are 1, and the three alignments only when the codes are 3, 0, 3,
1. The other 42 pages are in one pair whose IDML
names the family `Minion Pro (OTF)` where the INDD family name is
`Minion Pro`; its `FontFamily` element has the same difference
(`fonts.md`).

**Applied master of a master page.** Pages of master spreads use the same
chunk 0x140F. When it is absent or names UID 0, IDML writes
`AppliedMaster="n"` and `MasterPageTransform="1 0 0 1 0 0"` (220 of 220
master pages in the corpus pairs; 2 of them have the chunk with UID 0 and
an identity matrix). In 147 master pages of 73 distinct INDD files without
an IDML, chunk 0x140F names another master spread of the same document,
never the page's own spread. No pair shows the IDML for this case; the
converter writes it as `AppliedMaster`, as for document pages.

## Page items

Frames, shapes and lines are all class 0x6201; groups are 0x401.

| Chunk | Contents |
|---|---|
| 0x151 | Matrix: `ItemTransform` |
| 0x40D | Groups without chunk 0x151: the matrix (`ItemTransform`) |
| 0x162B | Path geometry (below) |
| 0x15B | Hierarchy: u32 spread, u32 parent, UID list of children |
| 0x6E03 | Attribute list: local formatting (see `attributes.md`) |
| 0x1B916 | u32: applied object style |

**Content type.** A rectangle, oval or polygon with a placed graphic is
`ContentType="GraphicType"`. Without one, chunk 0x1623 (u16) decides: 1
is `GraphicType` (an empty graphic frame), 0 or no chunk `Unassigned`.
In 200 of the trustworthy pairs, the 757 empty shapes with
`GraphicType` all have 1, and the 15,768 with `Unassigned` have 0
(13,226) or no chunk.

Groups store their matrix in chunk 0x40D when they have no chunk 0x151:
with it, the `ItemTransform` of all 5,670 groups of the trustworthy
pairs (8,788 of 8,789 over all pairs) matches; without it, 5,277 of them were
written as the identity, though they have a translation in IDML.

**Path geometry:** u32 path count; per path: u32 point count, points, u16
1 if the path is open. Each point is a u32 type, then f64 values: type 2 =
anchor (x, y) only; types 0 and 1 = left direction, anchor, right
direction. All 3,191 path chunks in the samples parse exactly, and the
points of every page item path match the IDML `PathPointType` values.

**IDML element type.** A frame is a `TextFrame` if a child of class
0x263 exists. Otherwise chunk 0x6204 (u16, then u32) gives a shape code:
1 `GraphicLine`, 2 or 3 `Rectangle`, 4 or 5 `Oval`, 0 and 6 to 8
`Polygon`; code 9 means none. With code 9 or without the chunk the
converter uses the path: two points and open → `GraphicLine`; four
corner points on two distinct x and y values → `Rectangle`; four points
with direction points, all of point type 0 → `Oval`; anything else →
`Polygon`. Path points of type 1 have direction points too, and a closed
four-point path with one or more of them is a `Polygon` in IDML (1,672
shapes in the trustworthy pairs).

Evidence over the 62,908 rectangles, ovals, polygons and lines of the
trustworthy pairs: the code gives the IDML element for 22,579 of 22,587
shapes that have one (7 polygons have code 2 or 3, 1 rectangle code 4);
the path for 40,070 of 40,321 without one. Most of the others (215) are
polygons whose four points of type 0 form an ellipse, as ovals do.

**Text frames:** the frame's child of class 0x263 (multi-column frame) has
a child of class 0x227 (frame column). Chunk 0x220 of the column holds the
frame list (class 0x228). Its chunk 0x205: u32 story, then a UID list of
the columns of all threaded frames in order, which gives
`PreviousTextFrame` and `NextTextFrame`.

**Page item labels.** A page item's `Properties/Label` has the layout and
rule of the document label: u16 0x7B7B, u32 count, then flagged key and
value strings, written in stored order as stored. It is stored in:

| Item | Chunk | Offset |
|---|---|---|
| Frames and shapes (class 0x6201) | 0x6204, after the shape code | 6 |
| Groups (0x401) | 0x2C0B | 0 |
| Buttons (0x1450C) and multi-state objects (0x145D8) | 0x14582 | 0 |

Without these bytes the item has no `Label`. In `Properties` the `Label`
comes first. Evidence: all 278 labelled items of these kinds in the
IDMLs of all pairs (258 in 27 trustworthy pairs: 108 rectangles, 44 text
frames, 40 lines, 36 groups, 18 buttons, 9 multi-state objects, 3
polygons) have the bytes and match key for key; no item has the bytes
without a `Label` in IDML. Flag 1 appears on labelled frames whose IDML
keys and values have no `$ID/` prefix.

## Page item settings

Every page item element in IDML (`TextFrame`, `Rectangle`, `Oval`,
`Polygon`, `GraphicLine`, `Group`) has the attributes below. Each is
stored in a chunk of the item (class 0x6201 or 0x401), or in its
attribute list (chunk 0x6E03, `attributes.md`); without the chunk the
IDML value is the default in the table.

| Chunk | Contents | IDML | Without the chunk |
|---|---|---|---|
| 0x2C10 (groups: 0x418) | u8 1 if a built-in key, then an in-object string | `Name`: the string, or `$ID/` and the key | `$ID/` |
| 0x2C32 | u16, 0 = hidden | `Visible` | `true` |
| 0x2C2D | u32, 1 = locked | `Locked` | `false` |
| 0x142D | u32, 1 = overrides not allowed | `AllowOverrides` on items of master spreads (the spread in chunk 0x15B is a master spread): `false` for 1, else `true`; no item of a document spread and no placed graphic has it (11,791 of 11,791 trustworthy items) | `true` on master spreads |
| 0x21D4E | u32 count *n*, *n* pairs of u32 | `ParentInterfaceChangeCount`: the numbers | empty |
| 0x21D50 | same | `TargetInterfaceChangeCount` | empty |
| 0x21D53 | same | `LastUpdatedInterfaceChangeCount` | empty |
| 0x1424 | u32 master page item, UID list | `OverriddenPageItemProps`: the list in decimal; empty if the master item is 0 | empty |
| 0x22228 | u8 flags | `HorizontalLayoutConstraints` (bits 4–6), `VerticalLayoutConstraints` (bits 0–2): per bit `FixedDimension` if set, else `FlexibleDimension` | as 0x22 |
| 0x324 | u32 at 0, a layer or spread layer UID | `BeforeGroupingLayerReference`, from 21.4 (below) | none |
| 0x324 | i32 at 4 | `BeforeGroupingLayerPosition`, after `ItemTransform`, from 21.4 (also on placed graphics) | `-1` |

| Attribute | IDML | Without the attribute |
|---|---|---|
| 0x5520, 0x551F, 0x551E | `GradientFillStart`, `GradientFillLength`, `GradientFillAngle` | `0 0`, `0`, `0` |
| 0x5526, 0x5525, 0x5524 | `GradientStrokeStart`, `GradientStrokeLength`, `GradientStrokeAngle` | same |
| 0x5522, 0x5523 | `GradientFillHiliteLength`, `GradientFillHiliteAngle` | `0` |
| 0x5528, 0x5529 | `GradientStrokeHiliteLength`, `GradientStrokeHiliteAngle` | `0` |

Rules the IDML follows, over the 92,409 page item elements of the 495
trustworthy pairs:

- `Locked` is on the 36,817 items that are children of a spread or
  anchored in text, and on none of the 55,592 items inside a group or
  another page item.
- `ItemLayer` is on the 35,276 items that are children of a `Spread`
  or `MasterSpread` (35,276 of 35,276), and on none of the items inside
  a group (48,289 of 48,291), inside a rectangle, oval or polygon (2,925
  of 2,925) or anchored in text (1,999 of 1,999). The layer of a nested
  item always equals its parent's. Counted over the 489 trustworthy pairs
  of the corpus without the privately held samples.
- The change counts, `OverriddenPageItemProps` and the layout
  constraints are in IDML from DOM 8 on: every page item of the
  distinct corpus IDML files from DOM 8 on has them, none of the DOM 7
  files does (145 text frames, 335 rectangles, 61 groups).
- A group has no gradient attributes of its own (no group in the pairs
  has 0x551E to 0x5529). IDML gives it, for each gradient attribute, the
  value all its child items have, and leaves the attribute out when they
  differ: 58,068 of the 58,080 gradient values of the 5,808 groups.

Evidence: the INDD values, decoded as above, against the IDML of the
same item, over the page items of the trustworthy pairs that have an
INDD object:

| IDML attribute | Equal |
|---|---|
| `Name` | 92,264 of 92,402 |
| `Visible` | 92,402 of 92,402 |
| `Locked` | 36,810 of 36,810 |
| The three change counts and `OverriddenPageItemProps` | 91,812 of 91,812 each |
| Both layout constraints | 91,812 of 91,812 each |
| Gradient start and length, fill and stroke (four attributes), items other than groups | 86,594 of 86,594 each |
| Gradient angles and highlights (six attributes) | all, 92,396 to 92,402 per attribute (groups by the rule above) |

The 138 names that differ belong to groups that are the states of form
fields; IDML names them by their state type (form fields).

Values other than the default: 206 items with a name given by the
user, 176 hidden, 1,241 with change counts, 1,113 with overridden
properties. Flags 0x22 are in 66,820 items, 0x55 (`FixedDimension
FlexibleDimension FixedDimension` both ways) in 643 and 0x02
(`FlexibleDimension` three times horizontally) in 13; with another bit
set the converter leaves both attributes out. In 14,918 items with
chunk 0x1424 the master item is 0; in 197 of them the list still holds
IDs, and IDML writes the attribute empty.

**Layer position before grouping.** From 21.4 every page item and
placed graphic in IDML has `BeforeGroupingLayerPosition`; no IDML before
21.4 has it (13 distinct corpus IDML files from 21.4, none of the 1,673
earlier ones). Its value is the i32 at 4 of chunk 0x324, or −1 without the
chunk. The converter writes it for files saved by 21.4 or later: 1,793 of 1,793
values over the trustworthy pairs (1,308 polygons, 241 text frames, 131
rectangles, 53 groups, 38 images, 16 EPS, 3 graphic lines and 3 SVG).

Chunk 0x324 of page items and placed graphics:

| Offset | Contents | IDML |
|---|---|---|
| 0 | u32 UID: 0, a layer (class 0x302) or a spread layer (class 0x301) | `BeforeGroupingLayerReference` |
| 4 | i32 | `BeforeGroupingLayerPosition` |
| 8 | u8 0, 1 or 2, then bytes not decoded (in some items an in-object string with a layer name) | |

`BeforeGroupingLayerReference` is the layer the UID gives: the UID itself
for a layer, the u32 at 0 of the spread layer's chunk 0x302 for a spread
layer. 0, no chunk or another class give no attribute. Over the 1,831
page items and placed graphics of the 12 DOM 21.4–21.5 pairs:

| Chunk 0x324 | IDML | Items |
|---|---|---|
| u32 at 0 is 0 | no `BeforeGroupingLayerReference` | 1,667 of 1,667 |
| a spread layer | that spread layer's layer | 36 of 36 |
| a layer | that layer | 14 of 15 |
| no chunk | no reference, position −1 | 113 of 113 |

The exception is one rectangle on a master spread whose chunk names a
layer and position 1; its IDML has position −1 and no reference. No
field that sets it apart was found. The converter's output has 50 of
the 50 references of the pairs (19 polygons, 15 rectangles, 10 text
frames, 6 groups) and no other.

**Stroke weight without an attribute.** An item whose attribute list has
no stroke weight (attribute 0x6E65) takes it from the document's base
list (class 0x6E02, `attributes.md`, values an item does not store):
1 in most documents, 0.2835 in others. IDML writes it when it differs
from the object style's, so items with `[None]` (stroke weight 0) have
it. Groups vary (1,166 without the attribute, 625 with 1 and 30 with
other values, in 200 of the pairs) and get none.

**Overprint.** The attribute list of a page item holds the overprint
flags of the fill (0x6E6A) and the stroke (0x6E67), u16 1 `true`, as in
object styles (object style settings). IDML writes `OverprintFill` on a
rectangle, oval, polygon, graphic line, text frame or EPS text when its
fill puts ink on the page, by the object style rule: the fill colour
(the item's 0x6E68, else its object style's) is not `None`, `Paper` or a
white process colour, and the tint is not 0. The value is the item's
flag; an item without the flag has `false`, which IDML writes only when
the object style turns the fill category off (as for the fill colour,
attributes.md, values an item does not store). `OverprintStroke`
follows the same rule with the stroke colour (0x6E64), tint (0x6E66)
and category. Trustworthy pairs: the rule reproduces all 3,315
`Polygon`, 64 `Rectangle`, 33 `TextFrame`, 33 `EPSText` and 3 `Oval`
`OverprintFill` values and all 68, 30, 20, 2 and 1 `OverprintStroke`
values of polygons, graphic lines, rectangles, ovals and text frames,
with no extra value. Of the items that store 0x6E6A, 27 have a `Paper`
fill and no `OverprintFill`.

A group stores no flag. IDML gives it the flag that its children share,
counting only children whose fill (for `OverprintFill`) or stroke (for
`OverprintStroke`) puts ink on the page by the rule above: the child's
own flag, `false` without one; for a child group, its shared flag. A
group whose children with ink differ, or that has none, gets no
attribute, and neither does a group whose shared flag equals its object
style's value (`false` where the style has none). In documents saved by
21.4 or later, where every object style has the overprint attributes
(object style settings, overprint), children without ink count too,
with their own flag, else their style's value. Over all 1,462 pairs this
gives 320 of 320 `OverprintFill` values of groups (313 in 82
trustworthy pairs) and 2 of 2 `OverprintStroke` values, all `true`,
with no extra value; 4 more are written in a stale pair on groups that
its IDML does not have. 75 of the 320 groups have a child that
has no attribute in IDML. The 21.4 case rests on one group of one
trustworthy pair, whose child without ink has the style value `false`
and whose IDML has no attribute; before 21.4 a child whose stroke is
`Paper` under a style with `OverprintStroke="false"` does not count
(one group).

## Object export options

Page items (class 0x6201 and groups, 0x401) may have chunk 0x1E206, the
alternative text and tagging settings that IDML writes in
`ObjectExportOption`:

| Size | Contents | IDML `ObjectExportOption` |
|---|---|---|
| 4 | u32 alternative text source: 0 `SourceCustom`, 5 `SourceXMLStructure`, 8 `SourceDecorativeImage` | `AltTextSourceType` |
| flagged string | custom alternative text | `CustomAltText` |
| flagged string | | `Properties/AltMetadataProperty NamespacePrefix` |
| flagged string | | `Properties/AltMetadataProperty PropertyPath` |
| 4 | u32 actual text source: 0 `SourceCustom`, 5 `SourceXMLStructure`, 6 `SourceXMPAltText` | `ActualTextSourceType` |
| flagged string | custom actual text | `CustomActualText` |
| flagged string ×2 | | `Properties/ActualMetadataProperty` (as above) |
| 4 | u32 tagging: 0 `TagFromStructure`, 1 `TagArtifact` | `ApplyTagType` |
| rest | 64 bytes (DOM 8–9), 83 (10–20), 88 (21) | not decoded |

A flagged string is a u8 (1: a built-in key, written `$ID/` and the
string; 2: a plain string) and an in-object string. An empty key is
`$ID/`.

Evidence: 69,814 page items with the chunk in the trustworthy pairs; all
eight values match in 69,814 of 69,814 (other than the default: 30
custom and 199 decorative alternative text sources, 197 custom and 14
XMP actual text sources, 205 artifacts, 31 custom alternative texts, 197
custom actual texts). The 22,005 items without the chunk all have the
values `SourceXMLStructure`, `$ID/` and `TagFromStructure`. The chunk
parses in all 363,145 page items of the distinct little-endian corpus
files. The converter leaves out an attribute whose code is not in the
table. Which other attributes `ObjectExportOption` has depends on the
version (`idml-values.md`, export options of page items).

**Object styles** (class 0x1B901) may have chunk 0x1E206 with the same
layout, and IDML writes its first eight values in the style's
`ObjectExportOption` the same way. In the 1,503 pairs outside the
privately held samples, 3,643 object styles have the chunk: 20 store
tagging 1 and have `ApplyTagType="TagArtifact"` (20 of 20, in 2 DOM 20
pairs); all others store the default values and have them in IDML.
One privately held sample adds 1 object style with source 0 and a
custom alternative text: `AltTextSourceType="SourceCustom"` and the text
in `CustomAltText` (1 of 1). Styles without the chunk have the
defaults.

**Export size (chunk 0x1E22B).** A list of keys and values: u32 count;
per entry a u32 length and the key in text segments, a flag byte, two
bytes, a u16 value count and the values, each a u8 length, a u8 and that
many bytes of text. The keys are `UseOrigImage`, `CustomSizeType`,
`CustomSizeValue` and `CustomContentConversion`. `CustomSizeType` is IDML
`SizeType`: `1` `DefaultSize`, `2` `FixedSize`, `3` `RelativeToTextFlow`,
`4` `RelativeToTextSize`; an item without the chunk has `DefaultSize`.

**Generated alternative text.** From 21.4 page items have three more
chunks:

| Chunk | Contents | IDML `ObjectExportOption` |
|---|---|---|
| 0x1E260 | u16: 1 `true`, 0 `false` | `AltTextGenerationError` |
| 0x1E261 | four f64 | `AltTextCropSyncRect`: empty when all four are 0, else the four numbers (below) |
| 0x1E262 | u16: 1 `true`, 0 `false` | `AIGeneratedAltText` |

Without the chunk the values are `false`, `false` and empty; the
converter also writes these for another u16 or a chunk too short for
its values. Evidence, the 1,701 page items other than groups of the 12
DOM 21.4–21.5 pairs: `AltTextGenerationError` 1,701 of 1,701 (22
`true`), `AIGeneratedAltText` 1,701 of 1,701 (3 `true`),
`AltTextCropSyncRect` 1,701 of 1,701 (8 not empty, two distinct
rectangles). Items with a `true` flag have `AltTextSourceType="SourceCustom"`
and the generated or error text in `CustomAltText` (chunk 0x1E206); the
tail of chunk 0x1E206 is the same in all of them and does not hold the
flags. Object styles have `AltTextCropSyncRect=""` (49 of 49).

`AltTextCropSyncRect` writes each f64 with exactly 8 decimals, cut, not
rounded, from the shortest decimal form, joined by commas:
`415.60850393700787` gives `415.60850393` (rounding would give `…394`),
`306.7741732283466` gives `306.77417322`, `370.32` gives `370.32000000`.

**Groups** have no `AIGeneratedAltText` and `AltTextGenerationError` in
their `ObjectExportOption`: none of the 53 groups of the 7 trustworthy
documents from 21.4 has them. The converter leaves them out on groups,
which removes 106 extra values.

## Text wrap

Page items (class 0x6201 and groups, 0x401) and placed graphics have
chunk 0x3703 (44 bytes):

| Offset | Contents |
|---|---|
| 0 | u32 wrap mode: 0 `None`, 1 `JumpObjectTextWrap`, 3 `BoundingBoxTextWrap`, 6 `Contour` |
| 4 | u32 UID of the wrap path object (class 0x3702), or 0 |
| 8 | Four f64 offsets: left, top, right, bottom (IDML `TextWrapOffset`) |
| 40 | u16 master page flag: 1 `ApplyToMasterPageOnly="false"`, 0 `true` |
| 42 | u16 `TextWrapSide`: 0 `BothSides`, 1 `LeftSide`, 2 `RightSide`, 3 `SideTowardsSpine`, 4 `SideAwayFromSpine`, 5 `LargestArea` |

**Wrap path.** Every item with wrap mode 1, 2, 3 or 6 (and the codes
0x10003 and 0x10006) has a wrap path object; mode 0 items have none
(9,061 objects in 735 files of the corpus of 2026-10). The u32 at 4
equals the object's UID in 8,824 of the 8,824 objects whose owner was
found. Its chunks:

| Chunk | Contents |
|---|---|
| 0x162B | Path geometry, the layout of page items. Parses in 8,846 of the 8,846 little-endian objects that have it; 18 have none |
| 0x3709 | 10 bytes: u32 UID of the item (9,061 of 9,061), u32 0 (9,061 of 9,061), u16 custom path flag |
| 0x2C0B, 0x2C2D, 0x377A | On 4,813 of 9,061; not read |

IDML writes the path as `TextWrapPreference/Properties/PathGeometry`,
before `TextWrapOffset`, only when the custom path flag is 1. Over the
2,342 IDML wrap elements that have a wrap path object (1,412 in
trustworthy pairs):

| u16 at 8 of 0x3709 | IDML `PathGeometry` | All pairs | Trustworthy |
|---|---|---|---|
| 1 | present | 35 of 35 | 32 of 32 |
| 0 | absent | 2,307 of 2,307 | 1,380 of 1,380 |

The 35 are 28 polygons (22 `BoundingBoxTextWrap`, 6 `Contour`), one
rectangle, one group, one text frame (`JumpObjectTextWrap`) and 4 images
(`Contour`). In all 35 the IDML paths equal the 0x162B paths: number of
paths (1 to 3), point count, `Anchor`, `LeftDirection` and
`RightDirection` from the point's anchor, left and right, and `PathOpen`
from the u16 after the points (0 `false`). The numbers are the same
(tolerance 1e-6), so no transform applies: the path is in the item's
inner coordinates, those of its own `PathGeometry` or, for a placed
graphic, of its `GraphicBounds` (before the graphic's `ItemTransform`).
It already includes the wrap offsets: the path of an image with a 8.5 pt
top offset and a scale of 0.40885 extends 20.79 (8.5 / 0.40885) beyond
the graphic bounds on each side.

With flag 0 the object still stores a path: for frames and groups the
item's path bounding box grown by the offsets (1,538 of 1,538 cases
compared; in about 500 more the box is also grown by 0.25 to 1.5 pt on
each side), for contour wraps of images the computed contour. IDML omits
these, and the converter writes the path only for flag 1.

Placed graphics also have chunk 0x373D, the contour (IDML
`ContourOption`). See "Contour" below.

**Evidence from the pairs.** For every element with a `Self` in the
corpus pairs, the IDML `TextWrapPreference` was compared with chunk
0x3703 of the INDD object with that UID. Same-version pairs first, then
the pairs whose IDML is from an older version:

| INDD | IDML | Same version | Older IDML |
|---|---|---|---|
| Mode 0 | `TextWrapMode="None"` | 2,625 of 2,625 | 615 of 615 |
| No chunk 0x3703 | `TextWrapMode="None"` | 1,468 of 1,468 | 873 of 873 |
| Mode 1 | `TextWrapMode="JumpObjectTextWrap"` | 2 of 2 (one file) | 1, matched by geometry (below) |
| Mode 3 | `TextWrapMode="BoundingBoxTextWrap"` | 1 of 1 (an image) | none |
| Mode 6 | `TextWrapMode="Contour"` | 3 of 3 (one file) | 1 of 1 (an image) |
| Offsets as left, top, right, bottom | `TextWrapOffset` | 2,631 of 2,631 | 616 of 616 |
| u32 at 40 = 1 (little-endian) | `Inverse="false"`, `ApplyToMasterPageOnly="false"`, `TextWrapSide="BothSides"` | 2,630 of 2,630 | 616 of 616 |
| 0x373D type 5 | `ContourType="SameAsClipping"` | 224 of 225 (1 has no `ContourOption`) | 75 of 75 |

**Contour.** Chunk 0x373D of placed graphics (29 bytes) holds the
contour that IDML writes as `ContourOption`. The preferences chunk 0x373F
(`preferences.md`) and the object style chunk 0x3777 (object style
settings, below) have the same layout.

| Offset | Contents |
|---|---|
| 0 | u32 contour type: 0 `BoundingBox`, 1 `DetectEdges`, 2 `AlphaChannel`, 3 `PhotoshopPath`, 4 `GraphicFrame`, 5 `SameAsClipping`, 6 `SelectSubject` |
| 4 | f64: 5 in every placed graphic and the preferences, 5 or 8 in object styles |
| 12 | u8: 25 everywhere |
| 13 | `00 00 FF FF` everywhere |
| 17 | u8 `IncludeInsideEdges`: 0 `false`, 1 `true` |
| 18 | 11 zero bytes |

Evidence, over the placed graphics of the 1,251 trustworthy pairs (corpus
of 2026-10) whose IDML has a `ContourOption`:

| INDD | IDML | Graphics |
|---|---|---|
| Type 5 | `ContourType="SameAsClipping"` | 2,693 of 2,698 (5 have no `ContourType`, below) |
| Type 2 | `AlphaChannel` | 13 of 13 |
| Type 1 | `DetectEdges` | 8 of 8 |
| Type 0 | `BoundingBox` | 4 of 4 |
| Type 6 | `SelectSubject` | 1 of 1 |
| Byte 17 = 1 | `IncludeInsideEdges="true"` | 1 of 1 (type 2) |
| Byte 17 = 0 | `IncludeInsideEdges="false"` | every other graphic with `ContourType` |

Types 3 and 4 occur in no pair: no IDML in the corpus has either code.
The IDML schema's `ContourOptionsTypes` list leaves `PhotoshopPath` and
`GraphicFrame` as the two names without a code, and the INDD shows which
is which:

- The graphic's chunk 0x1635 holds path data in the layout of chunk
  0x162B (an outline of the picture content). All 5 type 3 graphics of
  v7.0 and later files have it (3 images, 2 EPS, 5 files); none of the
  12 type 4 graphics (3 files) does. Types 1, 2 and 6 have it too (118
  of 118 sampled), types 0 and 5 do not (56 of 56 sampled).
- The wrap outline (chunk 0x162B of the 0x3702 object) of a type 4
  graphic is the frame outline grown by the Top offset on every side.
  Two graphics have a frame that differs from the image bounds (one
  crops the image, one is wider than the placed bounds); both outlines
  follow the frame, not the image. The wrap outline of a type 3 graphic
  is its 0x1635 path, simplified and grown by the Top offset (3 of 3 with
  an outline; one is 2.1 units short at the bottom), not the image box.

So type 3 is drawn from a path of the picture (`PhotoshopPath`) and type 4
from the frame (`GraphicFrame`). The converter leaves the
`ContourOption` of other codes out.

**Contour parameters.** From DOM 21.4 every `ContourOption` has
`ContourTolerance="5"`, `ContourThreshold="25"`,
`ContourAlphaIndex="0"` and `ContourPathIndex="-1"`, after
`ContourPathName`: 211 of 211 elements in the 12 corpus IDML files of
DOM 21.4 and 21.5 (graphics, frames, object styles and preferences), all
with these values. No `ContourOption` of an earlier DOM has them (32,227
elements in the 1,444 IDML files of DOM 7 to 21.3). Every `ContourOption` of DOM 21.4 and
later also has `ContourType`. The contour chunks (graphic 0x373D, object
style 0x3777, preferences 0x373F) may hold them as the f64 at 4, the u8
at 12 and the i16 at 13 and 15, in the layout of the clipping chunk
0x2C1A (f64 tolerance, u8 threshold, i16 index): the 102 contour chunks
of the DOM 21.4–21.5 pairs hold 5, 25, 0 and −1 there. Over all 1,462
pairs, the only other value is f64 8 in 72 object style chunks (24
files of DOM 10.0, 10.2 and 17.0), whose IDML has no `ContourTolerance`,
so the assignment is not shown. The converter writes the four values on every `ContourOption`
with a `ContourType` from DOM 21.4. A `ContourOption` with only
`ContourPathName` has no sample from DOM 21.4; the converter writes it
without them.

`ContourPathName` is not in the chunk. Every `ContourOption` of the
corpus IDMLs has it (25,551 of 25,551 in 1,693 IDML). It is `$ID/` in
25,525; the other 26 name an alpha channel of an image: 13 images with
`ContourType="AlphaChannel"` and their 13 frames, in five documents.
The name comes from image chunk 0x177C:

| Offset | Contents |
|---|---|
| 0 | u32 channel count *n* (0 in most images, which then have 4 bytes) |
| 4 | per channel: a flag byte (3 or 0; meaning unknown), an in-object string (the channel name), then bytes not decoded |

For example `01 00 00 00 | 03 | 02 03 03 00 | 03 80` and 3 UTF-16
units. Over the images of the pairs that have a `ContourOption`:

| Image | `ContourPathName` | Images |
|---|---|---|
| Type 2, *n* ≥ 1 | the first channel name | 13 of 13 |
| Type 2, *n* = 0 or no chunk | `$ID/` | 10 of 10 |
| Any other type | `$ID/` | all (8,629), including 1,075 images with 1 to 7 channels |

No chunk of the type 3 graphics holds a path name (strings searched in
all chunks), so the converter writes `$ID/` for type 3 as for the other
types.

Which channel a type 2 contour names when *n* > 1 is not shown (no
sample); the converter takes the first. Image chunk 0x1714 is not the
source: its alpha channel name is `$ID/` in all 22 type 2 images.

A graphic without chunk 0x373D has the contour of the preferences chunk
0x373F, and without that chunk, type 5 and `IncludeInsideEdges="false"`.
Of the 9,535 graphics (images, EPS, PDF, SVG and imported pages) whose
`ContourOption` the converter writes and the trustworthy IDMLs have,
`ContourType` and `IncludeInsideEdges` are equal in all; this includes
the 319 images without the chunk that have `DetectEdges` because their
document's chunk 0x373F has type 1.

A frame with one placed graphic (`Rectangle`, `Oval`, `Polygon`) has the
contour of its graphic, unless its object style turns the text wrap
category on (all of 0x1B942, 0x37C8 and 0x37C9 in chunk 0x1B92E, IDML
`EnableTextWrapAndOthers="true"`). Then its `ContourOption` has only
`ContourPathName`: 517 of 518 such frames in the trustworthy pairs. In
all corpus pairs, the value is `$ID/` in all 568 `ContourOption`
elements with only that attribute (554 frames and the 14 graphics
below); the converter writes the name of the graphic's contour, which
is `$ID/` unless the graphic has type 2 and a channel (no sample of
that in such a frame). The 8,965 other frames with `ContourType` take
their graphic's type and `IncludeInsideEdges` in all cases, and the
frames of the 13 named images their `ContourPathName`. Frames without a
graphic have no `ContourOption` (all but one).

The IDML has no `ContourType` and `IncludeInsideEdges` on 14 graphics:
5 with type 5 in chunk 0x373D and 9 without the chunk. 12 of them are in
frames whose object style turns the text wrap category on, but 495
graphics in such frames have both attributes. No INDD field is known
that separates them, and the converter writes the type for all 14.

**Master page flag and side.** The 4 bytes at 40 are two u16 in the
file's byte order. The big-endian pair shows it: its 261 page items
store `00 01 00 00` (251, IDML `ApplyToMasterPageOnly="false"`) or
`00 00 00 00` (10, `true`), all with `TextWrapSide="BothSides"`. In
little-endian files the u32 1 is therefore the u16 1 at 40 and the u16 0
at 42. With this layout the converter reproduces, over the 1,251
trustworthy pairs of the corpus after 2026-10, all 256,651
`ApplyToMasterPageOnly` and `TextWrapSide` values of page items, form
fields and placed graphics, where the u32 reading had left 6,322 of
each out (items storing 0 at 40 or a side code). Side codes 1 to 5
occur on few items (14, 4, 9, 1 and 32 in the trustworthy pairs).
Items without the chunk have `false` and `BothSides`.

`Inverse` is `false` on every item of the corpus IDML files (256,651 of
256,651 in the trustworthy pairs); no INDD field is known for it, and
the converter writes `false`.

**Order of the offsets.** Most offsets in the pairs are 0, so the order
rests on a few elements:

- Offset 24 (third) is `Right`: the bounding-box image has 2.83 there
  and 0 elsewhere; its IDML has `Right="2.834645669291339"` and 0 for
  the other sides.
- Offset 32 (fourth) is `Bottom`: both jump-object frames have 14.17
  there and 0 elsewhere; their IDML has `Bottom="14.173228346456694"`
  and 0 for the other sides.
- Offset 16 (second) is `Top`. In a pair whose IDML is from an older
  version (IDML 17.0, INDD 18.1), the INDD has one jump-object frame with
  11.34 at offset 16 and 5.67 at offset 32. Its UID differs from the IDML
  element's, but its path and `ItemTransform` are identical to those of
  the IDML's only jump-object frame, which has `Top="11.338582677165356"`
  and `Bottom="5.669291338582678"`. A sample and its print PDF agree; see
  below.
- Offset 8 (first) is therefore `Left`. It is 0 in every sample that
  has a reference.
- The two contour frames have the same value at all four offsets, as in
  their IDML.

**Evidence from a sample and its print PDF.** The sample has frames
with mode 1. Offset 8 is 0 in all of them; offset 16 is 0, negative or
positive. With jump-object wrap, no text is set beside a frame, and text
above the frame must end above the top of the wrap area. Text line
positions in the PDF were taken from pdftotext word boxes and compared
with the frame bounds:

- Where offset 16 is 0, the body line above a frame ends at most 1.5 pt
  below the frame's top edge.
- Where offset 16 is negative, the body line above may end inside the
  frame, never further below its top edge than the offset's size plus
  1.5 pt. Where the next line position would end further down than
  that, it is left empty.
- A line that lies wholly between a frame's top and bottom edges falls
  inside the band that a large negative offset opens.

So the value at offset 16 moves the top edge of the wrap area, and a
negative value lets text into the frame from above.

**Other values.** One image in the same-version pairs has 0x40001 at
offset 40 and `TextWrapSide="SideAwayFromSpine"`; no other value is
shown, so the converter writes the side and inverse settings only when
the u32 at 40 is 1. Modes other than 0, 1, 3 and 6 have no IDML
evidence; the converter leaves out `TextWrapPreference` for them.

## Frame fitting

The frame fitting settings are attributes in the page item attribute list
(chunk 0x6E03, `attributes.md`). Object styles hold all of them in chunk
0x1B956 (a u16 count, then records of the same layout).

| ID | IDML `FrameFittingOption` attribute | Encoding |
|---|---|---|
| 0x6E83 | `AutoFit` | u32: 0 `false`, 1 `true` |
| 0x6E7E | `LeftCrop` | f64 |
| 0x6E7F | `TopCrop` | f64 |
| 0x6E80 | `RightCrop` | f64 |
| 0x6E81 | `BottomCrop` | f64 |
| 0x6E7C | `FittingOnEmptyFrame` | u32: 0 `None`, 1 `ContentToFrame`, 2 `Proportionally`, 3 `FillProportionally` |
| 0x6E7D | `FittingAlignment` | u32: 0 `TopLeftAnchor`, 1 `TopCenterAnchor`, 3 `LeftCenterAnchor`, 4 `CenterAnchor` |

Evidence, from the same-version pairs:

- **Object styles.** All 337 object styles paired by name hold all seven
  IDs in chunk 0x1B956, and all seven match the style's IDML
  `FrameFittingOption` in 337 of 337 (`FittingAlignment` 4 in 313
  styles, 0 in 24).
- **Crops.** Each crop ID is told apart by non-zero values: wherever IDML
  writes the attribute, the frame's own value, or its style's if the
  frame has none, matches: left 429, top 397, right 433, bottom 451, no
  mismatch. Non-zero values: left 235, top 204, right 239, bottom 258.
- **Fitting on an empty frame.** 301 of 301; codes 0, 1, 2 and 3 occur
  (1,154, 9, 77 and 16 values).
- **Alignment.** 200 of 205. The other 5 are frames in one file with the
  style `[None]`, no local value and a style value of 0, where IDML says
  `CenterAnchor`; not explained. Code 0 is shown in 9 frames, code 4 in
  object styles. Other codes are left out.
- **AutoFit.** 0 and `false` wherever IDML writes it (200 of 200); other
  values are left out.

Codes 1 and 3 of `FittingAlignment` and code 1 of `AutoFit` come from
the corpus after 2026-10, over all pairs (item and object style lists
against their IDML): `AutoFit` 1 `true` in 927 items and styles, 0
`false` in 2,548; `FittingAlignment` 1 `TopCenterAnchor` in 21 object
styles of one 14.0 document, 3 `LeftCenterAnchor` in 1 item. Codes 2
and 5 to 8 do not occur; the converter leaves them out.

**Where IDML writes it.** Only on rectangles, ovals and polygons, never
on text frames (1,154) or lines (136), even when their list has these
attributes. The rule depends on the applied object style's category
list (chunk 0x1B92E, object style settings):

1. **Fitting category off.** When the list lacks 0x1B960
   (`EnableFrameFittingOptions`), IDML writes all seven attributes:
   the item's value where its list has the ID, the style's otherwise.
   This holds for the root `[None]` too, although its IDML element has
   no `Enable…` attributes. In the trustworthy pairs of the corpus after
   2026-10, the root style's list lacks 0x1B960 in 22 documents, and all
   9,560 items there that use the root style have all seven attributes;
   in the other 883 documents with such items, no item that uses the
   root style has all seven.
2. **Otherwise**, let D be the item's local attributes whose value
   differs from its object style's. IDML writes D; with D empty it
   writes no element. An object style without a category list (older
   files) gives all seven of its values when D is empty, unless it is
   the root `[None]`.

Over the trustworthy pairs, the converter reproduces 33,274 of 33,702
`Rectangle/FrameFittingOption` elements, 13,131 of 13,648 for polygons
and 6,929 of 7,207 for ovals, with every attribute of the written
elements except 131 `FittingAlignment` values and 7 values of each of
three crops. Of the elements not reproduced, 585 belong to items the
converter does not write with that tag, and 632 are on items that use
the root `[None]` (style value 0) and do not store 0x6E7D, where IDML
writes only `FittingAlignment="CenterAnchor"` (609 of them in one 20.3
document); 6 rectangles remain. The 131 differing values are of the same kind,
on items of other styles. No stored value tells these items apart from
the items where IDML writes the style's value; the converter writes the
style's value.

## Clipping path settings

Images, PDF and EPS graphics may have chunk 0x2C1A (37 bytes):

| Offset | Contents | IDML `ClippingPathSettings` |
|---|---|---|
| 0 | u32: 0 `None`, 1 `DetectEdges`, 2 `AlphaChannel`, 3 `PhotoshopPath` | `ClippingType` |
| 4 | f64 | `Tolerance` |
| 12 | f64 | `InsetFrame` |
| 20 | u8 | `Threshold` |
| 23 | i16 | `Index` (not for type 2, below) |
| 25 | u8 flags: 0x02 `UseHighResolutionImage`; 0x01 and 0x08 `InvertPath` and `RestrictToFrame` | |
| 26 | 11 bytes, 0 in every sample | |

Evidence: 75 of 235 images in the same-version pairs have the chunk, and
all 75 match on the tolerance, inset, threshold and index (tolerance 2
or 0, threshold 25 or 0). PDF (153 of 206) and EPS (6 of 18) graphics
have the chunk with the same values as images that use the defaults.
Graphics without the chunk (160 images, 53 PDF, 12 EPS) have
`UseHighResolutionImage="true"`, `Threshold="25"`, `Tolerance="2"`,
`InsetFrame="0"` and `Index="-1"` in IDML, and the converter writes
those values for them.

Over the trustworthy pairs of the corpus after 2026-10, every graphic
with the chunk was compared with its IDML element (2,686 graphics):

| INDD | IDML | Graphics |
|---|---|---|
| Type 0 | `ClippingType="None"` | 2,655 of 2,655 |
| Type 1 | `DetectEdges` | 2 of 2 (2 pairs) |
| Type 2 | `AlphaChannel` | 1 of 1 |
| Type 3 | `PhotoshopPath` | 28 of 28 (12 pairs) |
| Flags 0x02 | `UseHighResolutionImage="true"`, `InvertPath="false"`, `RestrictToFrame="false"` | 2,680 of 2,680 |
| Flags 0x00 | `UseHighResolutionImage="false"`, `InvertPath="false"`, `RestrictToFrame="false"` | 5 of 5 |
| Flags 0x09 | `UseHighResolutionImage="false"`, `InvertPath="true"`, `RestrictToFrame="true"` | 1 of 1 (type 1, threshold 111, tolerance 3.9) |
| i16 at 23, types 0, 1 and 3 | `Index` (-1, or 0 in 9 type 3 images) | all |

Bits 0x01 and 0x08 are set together in the one sample, so which is
`InvertPath` and which `RestrictToFrame` is not shown. The converter
writes both when the two bits are equal and leaves both out otherwise.
Other type codes have no sample; the converter leaves out the element
for them.

The one type 2 image stores -1 at 23, and its IDML has `Index="0"`. No
other field of the chunk differs from the type 1 and 3 images, so the
index of the alpha channel is not in this chunk; the converter leaves
`Index` out for type 2.

`IncludeInsideEdges="false"` has no identified field: all 11,823
`ClippingPathSettings` elements in the IDML files of the 1,462 corpus
pairs have it, and the converter writes it.

**Path name.** `AppliedPathName` names the image's path or channel:

| Type | `AppliedPathName` | Graphics |
|---|---|---|
| 0 | `$ID/` | all 12,280 `None` elements of the corpus IDML files |
| 1 | `$ID/` | 2 of 2 |
| 2 | the first channel name of image chunk 0x177C (text wrap, contour) | 1 of 1 |
| 3 | the name in key 0x7D of image chunk 0x1708 | 17 of 17 with an ASCII name |

Key 0x7D of the image properties (13 bytes in all samples) holds a u8
length *n*, *n* bytes of name, then 6 bytes (`00 00 33 33 00 01` or
`00 00 00 00 00 01`). The name bytes are not Unicode. The other 11 type
3 images name their path in a legacy code page: in 5 (Korean documents)
key 0x7D holds bytes that decode in code page 949 to the IDML name; the
other 6 (Japanese documents) have no key 0x7D, and key 0x80 of the same
chunk holds the name as bytes that decode in Shift-JIS. None of these
INDD files has the name as UTF-16 or UTF-8 text, except two where it is
part of a longer text in another record. The file does not record the
code page, so the converter writes the name only when every byte is
printable ASCII (0x20 to 0x7E) and leaves `AppliedPathName` out
otherwise.

**Geometry.** IDML writes `Properties/ClippingPathGeometry` for every
graphic of type 1, 2 or 3 (31 of 31 images, 13 pairs), and for no
graphic of type 0. The paths are those of the graphic's own chunk
0x162B, in the layout of page item paths: the converter's output equals
the IDML element exactly, number for number, in all 31 (1 to 8 paths of
4 to 179 points). The 2,655 graphics of type 0 with chunk 0x162B (1,797
images, 329 PDF, 528 EPS, 1 WMF graphic) have no `ClippingPathGeometry`.
IDML puts it before `GraphicBounds`.

**Placed pages.** IDML has `ClippingPathSettings` on every
`ImportedPage` (42 in 8 pairs, 38 in 7 trustworthy pairs). No placed
page has chunk 0x2C1A, and all 42 have the values of graphics without
the chunk; the converter writes those values for them.

**ImageIOPreference.** Chunk 0x1714 of an image:

| Offset | Size | IDML `ImageIOPreference` |
|---|---|---|
| 0 | u32 | 72 in all 1,300 images with the chunk |
| 4 | u16 | `ApplyPhotoshopClippingPath`: 1 `true`, 0 `false` |
| 6 | u16 | 1 in all (`AllowAutoEmbedding="true"` in all IDML) |
| 8 | flagged string | `AlphaChannelName` (an empty key is `$ID/`) |

Without the chunk, IDML has `ApplyPhotoshopClippingPath="true"` and
`AlphaChannelName="$ID/"`. Evidence: 3,607 of 3,607 images of the
trustworthy pairs for both attributes (14 `false`, 92 `$ID/kNoneName`,
2 plain names). Chunk 0x8C39 (u16 at 0), which looked like the clipping
flag in fewer samples, gives the wrong value in 6 images and is missing
in 549. `AllowAutoEmbedding="true"` is written from observation.

## Placed graphics

Images (0x1702), PDF (0x2501), EPS (0x6601) and SVG (0x6639) are children
of a frame (in its 0x15B list) and share these chunks:

| Chunk | Contents |
|---|---|
| 0x151 | Matrix: `ItemTransform` (437/437 match) |
| 0x1633 | Four f64: `GraphicBounds` left, top, right, bottom |
| 0x8CBC | link list (story links and placed text, link lists): the link is the first UID, at offset 8 |

**Links (0x8C42).** Links of linked stories and linked page items
have another class with the same chunks (story links and placed text).
`LinkClassID` is the class of the link object in decimal: 2,386 of
2,386 IDML links in the 158 little-endian documents whose UID is a link
object in the INDD (19 more UIDs hold other objects, all in stale
pairs). Chunk 0x8C9B:

| Offset | Size | Contents | IDML `Link` |
|---|---|---|---|
| 0 | 4 | 0 in all links | |
| 4 | 4 | 0x101 in all links | (`LinkClientID="257"`) |
| 8 | 4 | UID of the link resource (class 0x8C41) | |
| 12 | 4 | 1 or 0 | `LinkResourceModified`: 1 `false`, 0 `true` |
| 16 | 4 | UID of the graphic (or story) | |
| 20 | 2 | 1 or 0 | `ShowInUI`: 1 `true`, 0 `false` |
| 22 | 6 | three u16, 1 in all links | |
| 28 | 4 | 0 in all links | |
| 32 | 4 + text | import stamp: u32 length, then text segments | `LinkImportStamp` |
| then | 8 | modification time of the file (FILETIME) | `LinkImportModificationTime` |
| then | 8 | time the file was placed or updated (FILETIME) | `LinkImportTime` |

A FILETIME here is the count of 100 ns intervals since 1601-01-01 UTC,
stored as two u32: the high half first, then the low half (each in the
file's byte order). Evidence: the stamp text is `file <n> <size>`, and
`<n>` equals the first time value in 4,686 of 4,686 links with a stamp.
A link with an empty stamp (length 0) has neither `LinkImportStamp` nor
`LinkImportModificationTime` in IDML, but has `LinkImportTime` (13 of
13).

Chunk 0x1B6 of a link (u32, on 59 links) is `PDFIdentifier`, which IDML
writes from DOM 21 on; links without the chunk have `PDFIdentifier="0"`
(81 of 81 DOM 21 links).

**Link resources (0x8C41)**: chunk 0x8C92 is a flag byte, u32 length,
then the URI as bytes (`LinkResourceURI`).

After the URI, chunk 0x8C92 continues:

| Offset after the URI | Field |
|---|---|
| 0 | u8 1, u8 1, u16 0 (all resources) |
| 4 | u32 0 or 1, not identified |
| 8 | u32 stored state: 0 `Normal`, 2 `Embedded`, 3 `Contained` (`StoredState`, below) |
| 12 | u32 UID of a raw data object (class 0x129), or 0 |
| 16 | stamp: u32 length, text segments (as in the link) |
| then | modification time (FILETIME, as in the link) |
| then | file size: u32 high half, u32 low half; `LinkResourceSize` is `<high>~<low>` in lower-case hexadecimal without leading zeros (`0~42ebd`) |
| then | u8, 1 in all resources |
| then | in-object string: the format name; `LinkResourceFormat` is `$ID/` and the name, and the graphic's `ImageTypeName` is the same |

Evidence over the 4,699 links of the trustworthy pairs (4,697 with a
resource object), with the converter's output compared with the
reference:

| IDML | Equal |
|---|---|
| `LinkResourceModified` | all 4,699 (5 with 0 = `true`) |
| `ShowInUI` | all 4,699 (2 with 0 = `false`) |
| `LinkImportStamp` | 4,105 of 4,105 links with the same URI in the INDD and the IDML |
| `LinkResourceSize`, `LinkResourceFormat` | 4,118 of 4,118 links with the same URI |
| `PDFIdentifier` | 81 of 81 |

The resource's stamp differs from the link's in 184 links; IDML then has
the link's stamp and the resource's size. All 63,470 link chunks and
their resource chunks in the distinct little-endian corpus files parse
with this layout.

**Links resolved to another file at export.** In 19 trustworthy
documents, 529 links differ from the INDD: the IDML names the same file
in another folder (344) or a newer file (185). InDesign wrote the
location and state of the file it found on the exporting computer; the
INDD keeps the state of its last save. These values cannot come from the
INDD, and `compare.py` leaves such links out (`docs/measurement.md`).

**Link times.** IDML writes `LinkImportTime` and
`LinkImportModificationTime` as `YYYY-MM-DDTHH:MM:SS` (seconds
truncated) in the local time of the computer that exported the IDML:

- IDML equals the INDD's UTC time plus a whole number of hours in 9,009
  of 9,385 time values; the other 376 belong to links resolved to
  another file at export or have no stamp.
- The offset differs between documents (−8 to +13 hours) and, in 71 of
  284 documents, between links of the same document in step with the
  season (for example 1 and 2 hours, −5 and −4, +10 and +11), with the
  larger offset on summer dates of that hemisphere: the daylight-saving
  rule of the exporting computer's time zone, which the INDD does not
  store.

The converter estimates the offset from the dates of the XMP packet that
have a UTC offset (`xmp:CreateDate`, `xmp:MetadataDate`,
`xmp:ModifyDate`, every `stEvt:when`): it takes the offset of the date
nearest to the link time in day of the year (difference of the days of
the year, not wrapping at the year end; ties: the latest date), and UTC
when there is no such date. Over the trustworthy pairs this gives
`LinkImportTime` for 3,886 of 4,446 links and
`LinkImportModificationTime` for 3,316 of 4,434 (links with the same URI:
3,748 of 4,118 and 3,019 of 4,105). Other rules give less: UTC about
155 values of 9,385, the offset of `xmp:ModifyDate` 6,488, the same rule
with the day difference wrapping at the year end 3,840 import times.
`compare.py` leaves both times out of the value coverage
(`docs/measurement.md`).

**Embedded links.** A link is embedded (`StoredState="Embedded"`) when its
resource names a raw data object at offset 12. That object holds the
linked file's bytes, which IDML writes as the graphic's `Contents`.

Evidence:

- In the 245 distinct little-endian files there are 883 link resources.
  The field at offset 8 is 2 in 123 of them, and exactly those 123 name a
  raw data object at offset 12. The other 760 have 0 at offset 12 (742
  with 0 at offset 8, 18 with 3).
- In the corpus pairs, all 10 resources of embedded links (12 links) name
  a raw data object, and none of the 369 resources of normal links do.
- For all 12 embedded links, the raw data object's bytes equal the
  base64-decoded `Contents` of the IDML graphic (JPEG, PNG, PDF, EPS and
  SVG files, 2 KB to 11 MB).

**Contained links.** The field at offset 8 is 3 on exactly the 50 links
IDML marks `StoredState="Contained"`: 30 linked stories, 17 stories
placed from Word and 3 linked page items. It is 0 on 2,237 `Normal`
links and 2 on 99 `Embedded` links (the 158 little-endian documents
whose IDML has a story link, a link source ID, style mappings or import
options; 19 more `Normal` links have a UID that holds another object, in
stale pairs).

**Settings shared with page items.** Images, PDF, EPS and SVG graphics
carry the page item setting chunks (page item settings, above): 0x2C10
name, 0x2C32 visibility, 0x21D4E, 0x21D50 and 0x21D53 change counts,
0x1424 overridden properties, 0x22228 layout constraints, and 0x1B916
object style (`AppliedObjectStyle`). Many graphics (2,396 images) lack
0x2C10 and 0x2C32; the defaults of the page item table then apply.
Graphics never have `Locked`. Evidence over the 5,131 graphics of the
trustworthy pairs: `Visible`, `Name` and `AppliedObjectStyle` 5,131 of
5,131; the change counts, `OverriddenPageItemProps` and both layout
constraints 5,079 of 5,079 from DOM 8 on, and absent in all 52 DOM 7
graphics. Images also have the five fill gradient attributes
(`GradientFillStart`, `…Length`, `…Angle`, `…HiliteLength`,
`…HiliteAngle`) from their attribute list (chunk 0x6E03) with the
defaults of page items, and `FillColor` when the list has attribute
0x6E68 (77 of 77 images; no image without it has `FillColor`). PDF, EPS
and SVG graphics have no gradient attributes.

**`ImageTypeName`** is `$ID/` and the format name of the link resource
(links, above), on graphics with a link only: 4,696 of 4,699 linked
graphics; no graphic without a link has it (308 images, 111 PDF, 12
EPS).

**Image properties (chunk 0x1708 of an image).** u32 count, then per
record u32 key, u32 data length *n*, a u8 (meaning unknown), *n* bytes;
then 4 zero bytes:

| Key | Data | Meaning |
|---|---|---|
| 0x64 | u32 | width in pixels |
| 0x65 | u32 | height in pixels |
| 0x67 | u32 | colour space: 1 grey, 2 RGB, 4 CMYK |
| 0x6C | u32, 16.16 fixed point | horizontal resolution (ppi) |
| 0x6D | u32, 16.16 fixed point | vertical resolution |
| 0x6F | colour table | present only for indexed colour |

In all 3,607 images of the trustworthy pairs, `GraphicBounds` width and
height equal pixels × 72 / resolution. All 29,055 image property chunks
of the distinct little-endian corpus files parse. IDML writes these
values only on images with a link (3,299 of 3,299; no image without a
link has them):

| IDML | Rule | Equal |
|---|---|---|
| `Space` | 1 `$ID/#Links_Grayscale`, 2 `$ID/#Links_RGB`, 2 with key 0x6F `$ID/#Links_Indexed RGB`, 4 `$ID/#Links_CMYK` | 3,299 of 3,299 |
| `ActualPpi` | both resolutions rounded half up to integers (72.009 → 72) | 3,299 of 3,299 |
| `EffectivePpi` | each `ActualPpi` value divided by the image's scale on the spread, rounded half up | 3,299 of 3,299 |

The scale on the spread: multiply the `ItemTransform` of the image with
those of all its ancestors (frames, groups, the spread; for an item
anchored in text, its own chain only) to get *a b c d tx ty*. The
horizontal scale is √(a² + b²); the vertical scale is |ad − bc| divided
by the horizontal scale. Using √(c² + d²) for the vertical scale fails on
87 skewed images; rounding half to even fails on one image whose value
is exactly 76.5 (IDML: 77).

**Profile** (`Properties/Profile` of `Image`, chunk 0x7C0F): u32 at 0 is
3 → `$ID/Embedded`, 1 → `$ID/Use Document Default`; 0 or no chunk →
`$ID/None`. A profile name follows as an in-object string. 3,607 of
3,607 images (751, 1,652 and 1,204).

**Vector colour policies of PDF and EPS graphics (chunk 0x7C42).** 16
bytes, four u32. Offset 4 is `RGBVectorPolicy`, offset 12
`CMYKVectorPolicy`: 1 `IgnoreAll`, 3 `HonorAllProfiles`. Offset 0 is 1
and offset 8 is 3 in all 334 graphics with the chunk. Without the chunk
the policies follow the document's colour policies (chunk 0x7C44 of the
preferences, `preferences.md`): `RGBVectorPolicy` is `IgnoreAll` when
`RGBPolicy` is `ColorPolicyOff`, else `HonorAllProfiles`;
`CMYKVectorPolicy` is `IgnoreAll` for `ColorPolicyOff` and
`CombinationOfPreserveAndSafeCmyk`, `HonorAllProfiles` for
`PreserveEmbeddedProfiles` and `ConvertToWorkingSpace`. Evidence: with
the chunk 334 of 334 graphics; without it 1,005 of 1,005 graphics in 128
documents (5 combinations of document policies).

**PDF placement (chunk 0x251B of a PDF).**

| Offset | Size | IDML `PDFAttribute` |
|---|---|---|
| 0 | u32 | `PageNumber` |
| 6 | u8 | `TransparentBackground`: 1 `true`, 0 `false` |
| 8 | u32 | `PDFCrop`: 0 `CropContentVisibleLayers`, 2 `CropArt`, 3 `CropPDF`, 4 `CropTrim`, 6 `CropMedia`, 7 `CropContentAllLayers` |

Evidence: 492 of 492 PDFs with the chunk (28 bytes in 486, 64 in 6),
all three fields. Without the chunk, IDML has `PageNumber="1"`,
`TransparentBackground="true"` and `PDFCrop="CropContentVisibleLayers"`
in 507 of 509 PDFs; the other 2 (one document) have `CropArt`, not
explained. Every PDF has `PDFAttribute` (1,001 of 1,001).

**Graphic layers (chunk 0x177A of images, PDFs and imported pages).**

| Offset | Size | Contents |
|---|---|---|
| 0 | 2 | 1 if an image has a `GraphicLayerOption` |
| 2 | 8 | unknown |
| 10 | 4 | layer count *n* |
| 14 | | *n* layer records, in IDML order |

A layer record is a flagged string (`Name`; a key is written with
`$ID/`), u32 layer ID (`Id`), u32 original and u32 current visibility (1
= visible: `OriginalVisibility`, `CurrentVisibility`), i32 ID of the
parent layer (−1 for a top-level layer), and u32 flags: 0x01
`SeparatorLayer`, 0x04 `FXLayer`, 0x08 `Locked`. A layer whose parent
ID is *p* is a child element of the `GraphicLayer` with `Id` *p*.
`Self` is the graphic's `Self`, `GraphicLayerOption1`, and `i` and the
layer ID in hexadecimal for each layer from the top level down
(`u5dbcGraphicLayerOption1i92i8e` is layer 0x8E inside layer 0x92).

Evidence: all 1,064 `GraphicLayer` elements of the trustworthy pairs
(679 PDF, 291 image and 94 imported page layers, 262 of them nested):
name, `Id`, `Self`, both visibilities and nesting 1,064 of 1,064; flag
0x04 ↔ `FXLayer="true"` 11 of 11; flag 0x08 ↔ `Locked="true"` 37 of 37;
flag 0x01 ↔ `SeparatorLayer="true"` 1 of 1. Flags 0x400 (10 group
layers) and 0x800 (5) have no IDML counterpart. `AdjustmentLayer`,
`HasViewState`, `ViewState`, `HasExportState`, `ExportState`,
`HasPrintState` and `PrintState` are `false` in all 1,064.
`GraphicLayerOption` with `UpdateLinkOption="KeepOverrides"` is on every
PDF and imported page (1,039 of 1,039, also when the layer count is 0)
and on the images whose chunk has 1 at offset 0 (11 of 11; the 1,212
images with 0 there have no element). All 38,087 layer chunks of the
distinct little-endian corpus files from InDesign 4.0 on parse; 172 in
InDesign 3.0 files do not, and the converter leaves their layers out
with a warning.

**Layer comps.** Images with a `GraphicLayerOption` also have
`LayerCompOption AppliedLayerComp`: chunk 0x9209 of the image, i32 at
offset 4 (−1, −2 or a comp number). 11 of 11.

## Movies and sounds (classes 0x14801 and 0x14F01)

Evidence: 21 `Movie` and 8 `Sound` elements in 17 trustworthy pairs
(DOM 8.0: 2 pairs, 10.2: 11, 11.0: 1, 13.1: 1, 18.0: 2), and 128 movies
in 42 files and 42 sounds in 12 files of the corpus (distinct,
little-endian, InDesign 3.0 to 18.2; no big-endian sample).

**Where they are.** A movie or sound is listed in the child list (chunk
0x15B) of a spline item (class 0x6201) and is that frame's only child
(170 of 170 objects). Its own chunk 0x15B names the frame as parent (29
of 29 paired) and lists its poster, if any. IDML writes it as a `Movie`
or `Sound` element, the last child of the frame's `Rectangle` (29 of
29), with `Self` the object's UID. The frame is written as a frame
without a graphic: `ContentType="GraphicType"` (its chunk 0x1623 is 1)
and no `ContourOption` in its text wrap (29 of 29 frames).

**Chunks.**

| Chunk | Contents | IDML | Evidence |
|---|---|---|---|
| 0x151 | matrix | `ItemTransform`; identity without the chunk | 29 of 29 (one sound has no chunk and `1 0 0 1 0 0`) |
| 0x162B | path geometry, as page items | `Properties/PathGeometry` | 29 of 29 |
| 0x1633 | four f64 | `Properties/GraphicBounds` (left, top, right, bottom) | 29 of 29 |
| 0x8CBC | link list, as placed graphics | `Link` | 29 of 29 |
| 0x15B | hierarchy: spread, parent frame, children (the poster) | | 29 of 29 |
| 0x14004 | playback settings (below) | `Name`, `Description`, flags, `ControllerSkin` | 29 of 29 |
| 0x1480C (movie), 0x14F03 (sound) | label at offset 0, as group labels (u16 0x7B7B, u32 count, flagged key and value strings) | `Properties/Label` | 2 movies with one pair match; 6 with count 0 and 21 without the chunk have no `Label` |
| 0x1B916 | object style | `AppliedObjectStyle` | 29 of 29 |
| 0x21D4E, 0x21D50, 0x21D53, 0x1424, 0x22228, 0x2C32 | page item settings | change counts, `OverriddenPageItemProps`, layout constraints, `Visible` | 29 of 29 each |
| 0x3703 | text wrap | `TextWrapPreference` | 29 of 29 (7 with mode 0; 22 without the chunk, all `None` with offsets 0) |
| 0x6E03 | attribute list | `TransparencySetting` | 1 movie with a gradient feather |
| 0x2C10 | name chunk of page items | not used: flag 1 and an empty string where present (7 objects); `Name` comes from chunk 0x14004 | |

Not read: 0x14022 (below), 0x8C39, 0x8C24, 0x1623, 0x2C5D, 0x14009,
0x6E20, 0x6EDD and the other page item chunks that 7 of the 29 paired
objects carry (0x1E206, 0x1E22B, 0xB30A, 0x2056D, 0x2055F, 0x3723).
IDML has no `ObjectExportOption`, `AnimationSetting` or `TimingSetting`
on any of the 29 (all 0x2056D counts are 0 and all 0x2055F are `00
00`).

**Playback settings (chunk 0x14004).** A sequence of lists, each a u32
count and that many entries of u32 key and a value whose type depends
on the list: list 1 u16, list 2 u32, lists 3 to 6 unknown (count 0 in
all 168 chunks that parse), list 7 a flag byte and an in-object string.
The chunk ends after list 7 in 167 of 168; one 10.1 movie has one more
list (count 1, key 0x14009, 16 bytes) with no IDML counterpart. A 3.0
movie uses keys 0x14800 to 0x14804 and another layout. Keys within a
list are in no fixed order. Every u16 value is 1: IDML has `true` when
the key is present and `false` when it is not.

| Key | List | `Movie` | `Sound` | Evidence (paired) |
|---|---|---|---|---|
| 0x14000 | string | `Name`, as stored | `Name` | 21 of 21, 8 of 8 |
| 0x14002 | string | `Description`; `""` without the key | `Description` (no sample with the key) | 1 with the key, 28 without |
| 0x14008 | string | `ControllerSkin`; `""` without the key | | 19 of 19 (11 `SkinOverAll`, 1 empty, 7 without the key) |
| 0x14003 | u16 | `CustomPoster` | | 21 of 21 (14 `true`) |
| 0x14006 | u16 | `PlayOnPageTurn` | `PlayOnPageTurn` | 21 of 21 (3 `true`), 8 of 8 (7 `true`) |
| 0x1400C | u16 | `ShowController` | | 19 of 19 (5 `true`) |
| 0x1400E | u16 | `MovieLoop="true"` and `PlayMode="RepeatPlay"`; without it `false` and `Once` | `SoundLoop` | 21 of 21 (2 with the key), 8 of 8 (5 `true`) |
| 0x14004 | u16 | `EmbedInPDF` (never stored on a movie: `false` in 21 of 21) | `EmbedInPDF` | 8 of 8 sounds have it and `true` |
| 0x1400D | u16 | | `StopOnPageTurn` | 8 of 8 (2 `true`) |
| 0x140FF | u16 | not identified (1 movie; no attribute differs) | | |
| 0x14007 | u32 | not identified (0 in 139, 5485 in one unpaired movie) | | |
| 0x140FE | u32 | not identified (5 in all 170) | | |

The 14 movies with `CustomPoster="true"` have a poster without a link,
the 7 with `false` a linked poster; the converter takes the key. A chunk
whose lists 3 to 6 are not empty gives the flags without the strings
and a warning; a damaged chunk gives the defaults and a warning.

**Values without a stored field.** These are the same in every IDML of
the corpus with these elements (19 files, paired or not: DOM 8.0, 10.1,
10.2, 11.0, 13.1, 18.0). No stored field was found for them; the
converter writes them as defaults.

| Element | Attribute | Value | Samples |
|---|---|---|---|
| `Movie` | `FloatingWindow` | `false` | 27 of 27 |
| `Movie` | `FloatingWindowPosition` | `Center` | 27 of 27 |
| `Movie` | `FloatingWindowSize` | `Full` | 27 of 27 |
| `Movie` | `ShowControls` | `false` | 26 of 26 (DOM 8.0 to 13.1) |
| `Sound` | `DoNotPrintPoster` | `false` | 13 of 13 |
| both | `LocalDisplaySetting` | `Default` | 40 of 40 |

`ShowControls`, `ControllerSkin` and `ShowController` are on all 26
movies of DOM 8.0 to 13.1, also on the 7 whose chunk has neither key
0x14008 nor 0x1400C, and on none in the one DOM 18.0 file. They follow
the version, not the stored keys. No IDML of DOM 14 to 17 has a movie;
the converter writes them below DOM 18.

**`FilePath`** is the `LinkResourceURI` of the media's own link as a
native path: without `file:`, percent-decoded as UTF-8, and with `\`
for `/` in a path that starts with a drive letter (`C:/`). From the
IDML's own link URI this gives `FilePath` in 29 of 29 (25 Windows
paths, 4 Mac paths). From the INDD's link it gives 8 of 29: the other
21 links were resolved to another file on the exporting computer, and
the IDML has that file's path in both `Link` and `FilePath`. A media
object without a link has no `FilePath`.

**Children.** IDML order (29 of 29): `Properties` (`PathGeometry`,
`GraphicBounds`, then `Label`), `TransparencySetting`,
`TextWrapPreference`, the poster `Image`, `Link`.

- Text wrap: as for placed graphics (chunk 0x3703; without it mode
  `None` and offsets 0), 29 of 29. `ContourOption` is in the wrap of
  every movie and sound with a poster (26 of 26) and of none without (3
  of 3), as a frame has one only with a graphic. All 26 are
  `SameAsClipping`, `false`, `$ID/`; no media object has chunk 0x373D,
  and the poster's contour and the preferences' contour agree in all
  26, so either can be the source. The converter uses the poster's.
- Poster: 125 of 128 movies and 9 of 42 sounds list one child, an image
  (class 0x1702). IDML writes it as an `Image` child (26 of 26 paired),
  like any image: 12 linked, 14 with their file in the document
  (`Properties/Contents`). Its `EffectivePpi` uses the transforms of the
  image, the movie or sound, the frame and their ancestors (12 of 12
  linked posters).
- `Link`: the layout of image links (chunks 0x8C9B and 0x8C92). For the
  8 links whose URI is the same in INDD and IDML, `LinkResourceFormat`
  (`$ID/Flash H264 Video`, `$ID/MP3`, `$ID/Flash Video`, `$ID/SWF
  (Shockwave Flash)`), `LinkResourceSize` and `LinkImportStamp` match 8
  of 8.

**Media file properties (chunk 0x14022).** The same kind of typed list,
with list types u16, u32, u64, f64, four f64 and flagged string (29 of
29 paired chunks end after the sixth list). Keys seen: 0x14002 and
0x14004 (u16); 0x140FE, 0x14F00 (sounds: 44100, the sample rate) and
0x14F02 (sounds: 128) (u32); 0x14000 (u64); 0x14006 (f64, movies: the
duration in seconds); 0x14001 (four f64, movies: the frame size, for
example 0 0 640 640); 0x14003 and 0x14005 (strings; 0x14005 of sounds
is an older import path that matches neither link URI). IDML writes
none of these: no IDML in the corpus has `IntrinsicBounds`,
`CanChoosePosters` or `PosterAvailable`, a `NavigationPoint` or a
`Movie` `URL`.

**References.** `MovieBehavior/@MovieItem` (6 in 5 pairs) and
`SoundBehavior/@SoundItem` (2 in 1 pair) name a `Movie` or `Sound` of
the same IDML (8 of 8); see button behaviours. `TimingTarget` elements
with `TargetRole` 132354 (3 movies) and 132356 (7 sounds), in 9 pairs,
name a written `Movie` or `Sound` in 10 of 10; see timing lists.

## Text on a path (class 0xB320)

A shape or text frame with text on its path names a text path object
in chunk 0xB30A (600, 392 or 336 bytes). Items without text on their
path can have the chunk too, with 0 in the first u32.

| Offset in 0xB30A | Contents | IDML `TextPath` |
|---|---|---|
| 0 | u32 text path UID (class 0xB320), 0 for none | `Self` |
| 4 | u32, the same UID | |
| 8 | u16 1, u16 4, u32 3 in all 41 | `PathAlignment="CenterPathAlignment"`, `TextAlignment="BaselineTextAlignment"`, `PathEffect="RainbowPathEffect"`, `PathSpacing="0"` (which field is which is not known) |
| 16 | u8: 1 `Flipped`, 0 `NotFlipped` | `FlipPathEffect` |
| 18 | f64 | `StartBracket` |
| 26 | f64 | `EndBracket` |

The text path object has chunk 0xB334: u32 (its own UID), u32 0, then a
UID list with one multi-column frame (class 0x263). That frame's 0x15B
child list holds a column of class 0xB318, which gives the story and
the thread as the column of a text frame does (text frames, below):
`ParentStory`, `PreviousTextFrame` and `NextTextFrame` (`n` in every
sample).

IDML writes `TextPath` as a child of its shape or frame, directly after
`Properties`, with the attributes in the order of the table (then the
two thread attributes). The converter writes the four constant values
only when the bytes at 8 are those of every sample.

Evidence: 42 `TextPath` elements with an INDD object in the pairs (36
in trustworthy pairs; parents: polygons, an oval and text frames), all
values equal in 42 of 42, both `FlipPathEffect` values occurring.

## EPS text (class 0x660B)

Text kept from a placed EPS or PDF graphic as text that cannot be
edited. IDML writes it as an `EPSText` page item. It is listed in the
0x15B child list of a spread layer or a group (483 of 634 are in
groups), and has the usual page item chunks (0x151 transform, 0x6E03
attributes, 0x1B916 object style, 0x3703 text wrap, 0x2C10 name, …) but
no path.

| Chunk | Contents | IDML |
|---|---|---|
| 0x151 | Matrix | `ItemTransform` |
| 0x154 | Four f64: left, top, right, bottom | `Properties/PathBoundingBox` `Left`, `Top`, `Right`, `Bottom` |
| 0x6612 | 60 bytes: four f64 in the same order, then f64 72 and zeros (not identified) | `Properties/EPSTextAttributeBounds` `Top`, `Left`, `Bottom`, `Right`, from the four f64 |
| 0x6611 | Text record (below) | `Properties/EPSTextData` |

**Text record (chunk 0x6611).** u32 version (0x00010002 in all 634), a
flagged in-object string (the font name), nine f64 (a matrix of font
size, 0, 0, font size, x, y, then three numbers), a flagged in-object
string (the text) and a tail of 210 bytes: u32 at 0 (16 in all), zeros
to 72, u32 at 72 (varies), u16 at 76 (0 or 1), u32 at 78 (14 in all),
zeros to 210.

IDML `EPSTextData` is this record in big-endian byte order, without the
u32 at 72 and at 78 of the tail, in base64 in lines of 76 characters:
each number big-endian, each string as in big-endian data (tag 2, flag,
the byte after the tag, u16 length, each segment header big-endian,
byte segments copied and UTF-16 code units big-endian), and the zero
areas copied. So `EPSTextData` is 8 bytes shorter than the chunk.

IDML writes `Properties` (`PathBoundingBox`, `EPSTextData`,
`EPSTextAttributeBounds`) and then `TextWrapPreference`; `EPSText` has
no `ContentType`, no path and no export options. Its other attributes
are those of other page items (page item settings, above); the values
that every `EPSText` has come from `element_values.xml`.

Evidence: 634 `EPSText` elements in 14 pairs (633 in 13 trustworthy
pairs), versions 8.1 to 20.5. The transform, both bounds, the text data
and the text wrap equal the IDML in 634 of 634. `StrokeType` (634),
`OverprintFill` (33) and `StrokeDashAndGap` (7) are not reproduced yet:
IDML writes `StrokeType="StrokeStyle/$ID/Solid"` on 627 items whose
attribute list has no stroke type.

## Form fields and multi-state objects

Seven classes are page items that IDML writes as interactive elements:

| Class | IDML | Elements (documents) |
|---|---|---|
| 0x1450C | `Button` | 284 (43) |
| 0x1450D | `CheckBox` | 72 (5) |
| 0x1450E | `RadioButton` | 11 (4) |
| 0x1450F | `TextBox` | 27 (4) |
| 0x14511 | `ComboBox` | 1 (1) |
| 0x14512 | `SignatureField` | 2 (2) |
| 0x145D8 | `MultiStateObject` | 18 (16) |

Counts are over the pairs of the corpus of 2026-10: 48 documents, all
trustworthy, saved by InDesign 8 to 20. Each element's `Self` is the
object's UID (415 of 415). A field is listed like any page item, in the
child list of its spread, group or anchor, and its fields and states
nest (a button inside a group inside a multi-state object's state).

**Fields with states** (button, check box, radio button, multi-state
object) have no chunk 0x15B and no 0x151:

- Chunk 0x14521: u32 active state ID, u32 count, then per state u32
  state ID, u16 enabled (1, or 0 for `Enabled="false"`), u16 key, u16
  (0). IDML writes one `State` per entry, in order (705 of 705), with
  `Self` the field's `Self`, `i` and the state ID in hexadecimal,
  `Active="true"` for the active state ID and `Enabled` from the u16
  (705 of 705; 4 not enabled).
- Chunk 0x14526: u32 spread, u32 parent, u32 count, then per key u32
  key, u32 *k*, *k* UIDs: the items each state shows, by its key (one
  group per state in 705 of 705). The chunks parse to their end in all
  385 fields. The spread decides `AllowOverrides` as chunk 0x15B does
  for other items.
- Chunk 0x14527: six f64, the transform (`ItemTransform`, 385 of 385).

**State types.** `Properties/Statetype` follows from the state ID. For
a multi-state object it is the ID itself (`type="long"`, IDs 9 to 15;
72 of 72 states). For the others it is an enumeration (633 of 633):

| ID | `Statetype` | States | Name of the state's group without a name of its own |
|---:|---|---:|---|
| 0 | `Up` | 284 | `$ID/$$$/StateType/Normal` |
| 1 | `Rollover` | 109 | `$ID/$$$/StateType/Over` |
| 2 | `Down` | 61 | `$ID/$$$/StateType/Down` |
| 3 | `UpOn` | 83 | `$ID/$$$/StateType/NormalOn` |
| 4 | `UpOff` | 83 | `$ID/$$$/StateType/NormalOff` |
| 6 | `RolloverOff` | 7 | `$ID/$$$/StateType/OverOff` |
| 7 | `DownOn` | 3 | `$ID/$$$/StateType/DownOn` |
| 8 | `DownOff` | 3 | `$ID/$$$/StateType/DownOff` |

The key is not the state type: a button's second state has key 2
whether it is `Rollover` (ID 1) or `Down` (ID 2). ID 5 has no sample; a
state with an ID not in the table is left out with a warning. A state's
group has no name chunk (0x418), or one with flag 1 and an empty name;
IDML names it by the state type, as in the table (633 of 633 groups of
buttons, check boxes and radio buttons). The groups of multi-state
objects have names of their own (72 of 72).

**Fields with child items** (text box, combo box, signature field) have
the usual chunks 0x151 (transform) and 0x15B, whose children IDML writes
inside the element: a `Rectangle` or `TextFrame` (30 of 30). Text boxes
can be anchored in text, with the anchor's `AnchoredObjectSetting`.

**`Properties/PathBoundingBox`.** The bounds of the paths of the items
the field shows, in the field's own coordinates: the curves through the
anchor and direction points (not only the anchors) of the items of every
state, or of the child items, each through its transform and those of
the groups and fields between it and the field. Items inside a frame
(an oval inside an oval) do not count. The converter takes each item's
box in its own coordinates and the box around its corners through its
transform, from the innermost item out: 415 of 415 equal to 6
significant digits, 379 of them as text (the others differ in the last
digit or two). The field has no `PathGeometry`.

**Attributes from the attribute list (chunk 0x6E03).** Strings have value
type 0x1451F or 0x1B02 (a flag byte and an in-object string), numbers
0x6E68 (f64), flags 0x6E65 (u16).

| ID | IDML | On | Evidence |
|---|---|---|---|
| 0x14534 | `Name` | all | 415 of 415, 237 distinct |
| 0x14535 | `Description` | all but multi-state objects | 397 of 397 (23 distinct); 3 multi-state objects have `Description=""` without it |
| 0x1453D | `Required` (1 `true`) | check box, radio button, text box, combo box, signature field | 113 of 113 (6 `true`); buttons have the attribute but IDML writes no `Required` |
| 0x14550 | `ExportValue` | check box, radio button | 83 of 83 (9 distinct) |
| 0x14552 | `Multiline` | text box | 27 of 27 (8 `true`) |
| 0x14553 | `Scrollable` | text box | 27 of 27 (9 `true`) |
| 0x14540 | `FontSize` | text box, combo box | 28 of 28 (4 distinct); signature fields have it, IDML writes none |
| 0x1455F | `AppliedFont` | text box | 24 of 24 (2 distinct); the 3 text boxes without it have neither `AppliedFont` nor `FontStyle` |
| 0x14542 | `FontStyle` | text box with 0x1455F | 24 of 24 |

The flags `ReadOnly`, `PrintableInPdf`, `CheckedByDefault`, `Password`,
`RightToLeftField`, `SortChoices`, `HiddenUntilTriggered`,
`InitiallyHidden` and `VisibilityInPdf` have one value in every sample,
and so do the candidate u16 attributes (0x14539 to 0x1453C, 0x14545,
0x14549, 0x14551, 0x14554 to 0x14558, 0x145E1); which holds which cannot
be shown. Where every IDML has the value, it comes from the value files
(`idml-values.md`, form fields). `ChoiceList` of the combo box (0x1455D,
one sample) is not decoded.

**Values of the page item.** `Visible`, `Locked`, the change counts,
the layout constraints and `ItemLayer` follow the page item rules
(page item settings). The gradient attributes are, as for a group,
the values all the items the field shows directly have (the state
groups or the child items), and IDML leaves an attribute out where they
differ: the six gradient attributes are equal in 400 of 415 fields (4
of them without the start and length values). The fill, stroke and corner values in
the field's attribute list are not IDML's: IDML's `FillColor` and
corner values of buttons are not in the list, and other stored values
differ, so they are not written. Fields with states have no object
style chunk (0x1B916); IDML names `[None]` for 363 of their 385 and
another style for 22, and where that is stored is not known, so
`AppliedObjectStyle` is left out for them, and so are the anchor
settings of such a field anchored in text, which IDML compares with the
style (12 anchored check boxes and radio buttons with a style other
than `[None]` have no `AnchoredObjectSetting`). A field has no
`ObjectExportOption`.

Timing lists of buttons and animations: animation and timing, below.

Behaviours of buttons: button behaviours, below.

### Button behaviours

Evidence: 206 behaviour elements in 193 buttons of 26 pairs (all
trustworthy, versions 8.0 to 18.0), and 547 behaviour objects in 78
documents of the corpus (InDesign 3.0 to 18.2, both byte orders). The
converter writes every behaviour type that has a paired sample, and
`compare.py` finds all their values in its output.

**Behaviour list (chunk 0x15601).** A form field lists its behaviours
by event:

```
u32 groups
  per group: u32 event code, u32 count k, k behaviour UIDs
```

- The chunk parses to its end in 712 of 712 fields (all field classes;
  271 have 0 groups). Only buttons have groups (441 buttons).
- Every behaviour object is listed in exactly one group of one field
  (547 of 547). No group is empty.
- IDML writes the behaviours as children of the button, in group order
  and, within a group, in stored order (193 of 193 buttons). In the five
  buttons with two groups the stored order is also ascending event
  code, so these two orders cannot be told apart.
- They are the last children of the button, after every `State` (193 of
  193). The schema allows them in any order there.

| Event code | `BehaviorEvent` | Paired behaviours |
|---|---|---:|
| 0x15602 | `MouseDown` | 32 |
| 0x15603 | `MouseUp` | 145 |
| 0x15604 | `MouseEnter` | 29 |

Unpaired groups also have 0x15605 (31) and 0x15607 (1). Their events
are not known: the behaviour is written without `BehaviorEvent`, with a
warning.

**Behaviour objects.** Each behaviour type is a class. IDML `Self` is
the object's UID (206 of 206); timing targets of role 132353 reference
these UIDs (53 of 53 resolve in the converter's output). The object has
one data chunk, and some also chunk 0x156E1, a label with the layout of
the document label. Chunk 0x156E1 has count 0 in all 112 occurrences,
and no IDML behaviour has `Properties/Label`; a label with pairs would be
written there (no sample).

| Class | IDML element | Data chunk | Type code | Objects (paired elements) |
|---|---|---|---|---:|
| 0x15613 | `GotoFirstPageBehavior` | 0x15614 | 0x15601 | 10 (7) |
| 0x15614 | (go to last page, no pair) | 0x15619 | 0x15602 | 2 (0) |
| 0x15615 | `GotoNextPageBehavior` | 0x1561A | 0x15603 | 88 (21) |
| 0x15616 | `GotoPreviousPageBehavior` | 0x1561B | 0x15604 | 37 (24) |
| 0x1561B | `GotoURLBehavior` | 0x15622 | 0x15605 | 45 (11) |
| 0x1562C | `MovieBehavior` | 0x1562C | 0x15606 | 99 (6) |
| 0x15636 | `ShowHideFieldsBehavior` | 0x15634 | 0x15607 | 29 (26) |
| 0x15664 | `ClearFormBehavior` | 0x15650 | 0x15609 | 3 (1) |
| 0x1566E | `SubmitFormBehavior` | 0x1565A | 0x1560A | 5 (1) |
| 0x15678 | `OpenFileBehavior` | 0x15664 | 0x1560B | 1 (1) |
| 0x156D3 | `GotoAnchorBehavior` | 0x156F0 | 0x15617 | 27 (18) |
| 0x156DD | `GotoNextViewBehavior` | 0x15703 | 0x15619 | 12 (12) |
| 0x156E8 | (view zoom, no pair) | 0x1570A | 0x1561A | 5 (0) |
| 0x156F4 | `SoundBehavior` | 0x1571C | 0x1561B | 7 (2) |
| 0x15625 | `GotoPageBehavior` | 0x156DE | 0x1561C | 54 (30) |
| 0x1562F | (animation, no pair) | 0x1566C | 0x1561D | 16 (0) |
| 0x1563F | `GotoStateBehavior` | 0x1566D | 0x1561E | 80 (37) |
| 0x15643 | `GotoNextStateBehavior` | 0x1567D | 0x1561F | 17 (4) |
| 0x15660 | `GotoPreviousStateBehavior` | 0x15680 | 0x15620 | 8 (4) |
| 0x156F9 | `PrintFormBehavior` | 0x15721 | 0x15621 | 2 (1) |

The class and the element match in 206 of 206 paired behaviours. The
type code is constant per class in 547 of 547 objects. The three
classes without a pair are named by their built-in name keys
(`$$$/Forms Action/GoTo Last Page`, `…/View Zoom`, `…/Animation`); the
converter leaves them out with a warning.

**Data chunk.** All data chunks start with a common header:

| Field | Contents | Evidence |
|---|---|---|
| u32 | UID of the field that owns the behaviour | 206 of 206 equal to the IDML parent button |
| u32 | type code (table above) | constant per class, 547 of 547 |
| flag byte, in-object string | the name: flag 1 and a built-in key `$$$/Forms Action/…` | flag 1 in 547 of 547 |
| u16 | `EnableBehavior` (1 `true`) | 1 in 547 of 547; all 206 paired are `true`. That 0 is `false` is assumed |

The type's fields follow (all u32 unless stated otherwise); the chunk
ends after them in 546 of 547 objects. The exception is a 3.0 movie
behaviour that ends after the operation. Big-endian objects (2 files of
8.0, 3 files of 4.0) parse to their end with the flag and string tag
swapped (`big-endian.md`).

| Type | Fields | IDML | Evidence |
|---|---|---|---|
| first, last, next, previous page, next view | navigation kind (0 first, 1 last, 2 previous, 3 next, 5 next view), zoom | `ZoomSetting` from the zoom | kind constant per class, 203 of 203 objects; zoom 64 of 64 |
| go to page | navigation kind 6, page index, zoom | `PageNumber` = index + 1, `ZoomSetting` | 30 of 30 (pages 1 to 6) |
| go to anchor | flag byte (0 in 27 of 27), in-object string, anchor u32, zoom | `FilePath`, `ZoomSetting`, `Properties/AnchorItem` (`type="long"`) | 18 of 18 |
| go to URL | flag byte, in-object string | `URL` | 11 of 11, plain and `navto://` URLs |
| open file | flag byte, in-object string | `FilePath` | 1 of 1 |
| submit form | u32 (0 in 5 of 5), flag byte, in-object string | `URL` | 1 of 1 |
| clear form, print form | none | | 1 and 1 |
| show/hide fields | count n, n × (field UID, action: 0 hide, 1 show) | `FieldsToHide`, `FieldsToShow` | 26 of 26 |
| go to state, next state, previous state | multi-state object UID, kind (0, 1, 2; constant per class, 105 of 105), u16 (0 in 105), u16 (1 in 45 paired, 0 in 3 unpaired), i32 state ID (-1 for next and previous) | `AssociatedMultiStateObject`; go to state `Properties/Statetype` (`type="long"`) = state ID | 45 of 45; state IDs 37 of 37 |
| movie | movie UID, operation (0 `Play`), i32 navigation point | `Operation`, `NavigationPointID` | 6 of 6 (all -1) |
| sound | sound UID, operation (0 `Play`, 1 `Stop`), f64 (1.0 in 5, 0.0 in 2 of 7), u32 (0 in 7) | `Operation` | 2 of 2 |
| view zoom (no pair) | u32 (0 in 5) | | |

- Zoom codes: 0 `InheritZoom` (every page navigation behaviour and 8
  anchors), 2 `FitWindow` (10 anchors). No other code occurs. Movie
  operation 3 (2 unpaired objects) and sound operation 2 (1) are not
  known. An unknown code leaves the attribute out, with a warning.
- `FieldsToHide` lists the UIDs with action 0 and `FieldsToShow` those
  with action 1, each in stored order, as references separated by
  spaces. With no such UID the attribute is written empty. The action
  is 0 or 1 in all 149 corpus entries.
- `AnchorItem` is the stored u32 when `FilePath` is not empty (5 of 5,
  anchors in another file). When `FilePath` is empty it is 0 (13 of
  13): the stored u32 is 0 in 8, and in 5 it is a UID with no object.
- In the converter's output the button (206 of 206) and every
  `AssociatedMultiStateObject` (45 of 45), `FieldsToHide` UID (124 of
  124) and `FieldsToShow` UID (25 of 25) exist as `Self`.
- `MovieItem` and `SoundItem` are the stored movie and sound UIDs: each
  names a `Movie` or `Sound` of the same IDML (6 and 2 of 6 and 2;
  movies and sounds). A UID that is not a written movie or sound is
  left out.
- The sound's f64 and last u32 and the submit u32 have no IDML
  attribute.

**Values with no stored field.** These are the same in every sample,
and no stored field was found for them. The converter writes them as
defaults:

| IDML | Value | Samples |
|---|---|---|
| `GotoAnchorBehavior` `AnchorName` | `$ID/` | 18 of 18 |
| `GotoStateBehavior` `GoBackOnRollOff` | `false` | 37 of 37 |
| `GotoNextStateBehavior`, `GotoPreviousStateBehavior` `LoopsToNextOrPrevious` | `true` | 8 of 8 |

The second u16 of a state behaviour is 1 in all paired samples, which is
consistent with `LoopsToNextOrPrevious="true"` but does not prove it.

**`Name`.** No behaviour has a name of its own: the name is a built-in
key with flag 1 in all 547 objects. IDML writes the key's name in the
language of the exporting InDesign, which follows the saving edition
(the XMP black name, saving edition): in all 26 pairs the edition
matches the language of every behaviour name (1 English, 7 Korean and
18 Chinese documents). The converter writes the names below and leaves
`Name` out for a key or edition without a sample. A name with flag 0
(no sample) would be written as stored.

| Key (`$$$/Forms Action/…`) | English | Korean | Chinese |
|---|---|---|---|
| `GoTo Anchor` | `Go To Destination` (10) | `대상으로 이동` (8) | |
| `GoTo First Page` | | `첫 페이지로 이동` (3) | `跳至第一頁` (4) |
| `GoTo Next Page` | | `다음 페이지로 이동` (1) | `跳至下一頁` (20) |
| `GoTo Previous Page` | | `이전 페이지로 이동` (1) | `跳至上一頁` (23) |
| `GoTo Next View` | | `다음 보기로 이동` (12) | |
| `GoTo Page` | | | `跳至頁面` (30) |
| `GoTo URL` | | | `前往 URL` (11) |
| `SwitchToMSOState` | | `상태로 이동` (13) | `跳至狀態` (24) |
| `SwitchToNextMSOState` | | `다음 상태로 이동` (1) | `跳至下一個狀態` (3) |
| `SwitchToPrevMSOState` | | `이전 상태로 이동` (1) | `跳至上一個狀態` (3) |
| `Movie` | | | `影片` (6) |
| `Sound` | | | `聲音` (2) |
| `Show/Hide Fields` | | | `顯示/隱藏欄位` (26) |
| `Open File` | | | `開啟檔案` (1) |
| `Submit Form` | | | `送出表格` (1) |
| `Reset Form` | | | `清除表格` (1) |
| `Print Form` | | | `列印表格` (1) |

The Chinese names are Traditional Chinese. Of the 93 trustworthy pairs
with the black name `黑色`, 92 name their paper swatch `紙張`
(Traditional Chinese) and one has no paper swatch; the corpus has no
Simplified Chinese saving edition.

**Attribute order.** The type's attributes first, in schema order, then
`Name`, `EnableBehavior` and `BehaviorEvent`. Example:
`<GotoPageBehavior Self="u762" ZoomSetting="InheritZoom" PageNumber="1" Name="跳至頁面" EnableBehavior="true" BehaviorEvent="MouseUp" />`.

**Not shown.** Behaviours of other field types (the schema allows most
types on check boxes, radio buttons, text boxes, combo boxes, list boxes
and signature fields; the corpus has none, and the converter leaves them
out with a warning); `AnchorItem` of a live anchor in the same document;
URLs stored with flag 1 (6 unpaired objects, key
`$$$/Dialog/Behaviors/GoToView/DefaultURL`, and one empty submit URL),
which the converter leaves out.

## Animation and timing

Spreads and buttons keep timing lists, page items an animation, and the
document a list of motion presets. Evidence: the 43 pairs of the corpus
whose IDML has any of these elements (little-endian, versions 8.0 to
18.0; all trustworthy). The layouts are the same in all versions. A
sweep of the first occurrence of each chunk in the spreads, buttons,
spline items, groups and preferences of all 1,251 trustworthy pairs
found non-empty timing lists, preset lists or animations only in these
43 documents.
The converter writes all of them by the rules below, and `compare.py`
finds all 3,783 of their values in its output for these 43 pairs.

Strings below:

- **Text string**: u32 length in UTF-16 code units, then text segments.
- **Name**: a flag byte (1 = built-in key, `$ID/` in IDML) and an
  in-object string.

### Timing lists (chunks 0x2056D and 0x2056E)

Spreads keep their timing lists in chunk 0x2056D, buttons (class
0x1450C) in chunk 0x2056E. Most page items also have chunk 0x2056D,
with a count of 0.

```
u32 lists
  per list:   u32 trigger, u32 groups
    per group:  u32 targets
      per target: u32 UID, u32 role, u32 action, u32 (0 in all 163), f64 delay
    then:       u32 plays, u16 (0 in all 159)
```

The chunk parses to its end in 96 of 96 owners. IDML writes a
`TimingSetting` exactly when the list count is not 0: 43 of 43 spreads
and 53 of 53 buttons with lists have one; 20 spreads and 119 buttons
with count 0 have none.

| IDML | Source | Evidence |
|---|---|---|
| `TimingList` `Self` | owner `Self` + `TimingSetting1TimingList` + list index (from 0) | 96 of 96 |
| `TriggerEvent` | trigger code: 1 `OnPageLoad`, 5 `OnClick`, 6 `OnRelease`, 7 `OnRollover` | 43 / 2 / 45 / 6; spreads all 1 |
| `TimingGroup` `Self` | list `Self` + `TimingGroup` + group index (from 0) | 159 of 159 |
| `Plays` | u32 plays | 159 of 159 (all 1) |
| `TimingTarget` `Self` | group `Self` + `i` + target UID in hex | 163 of 163 |
| `DynamicTarget` | `u` + target UID in hex | 163 of 163 |
| `DelaySeconds` | f64 delay | 163 of 163 (0 and 0.25) |
| `TargetRole` | u32 role, in decimal | 163 of 163 |
| `TargetAction` | u32 action, in decimal | 163 of 163 (all 132353) |
| `Placement` | target index in its group (from 0) | 163 of 163 |

Roles by target class: 132353 button behaviours (classes 0x1562C,
0x1563F, 0x15643, 0x15660, 0x156F4; 53 targets), 132354 movies (3),
132355 spline items, groups and multi-state objects (100), 132356
sounds (7). The stored value is written as is.

Every target of the samples names an element the converter writes:
a page item, a button behaviour, or a movie or sound (7 sound and 3
movie targets of 163; movies and sounds). The converter leaves out a
target whose element it does not write, with a warning, and numbers
`Placement` over the targets kept. A group or list left empty is left out too: no sample has
an empty one (159 groups, 96 lists).

Example, a spread with one list, one group and one target:
`01 00 00 00 | 01 00 00 00 01 00 00 00 | 01 00 00 00 | 63 04 00 00 03 05 02 00 01 05 02 00 00 00 00 00 | 00 00 00 00 00 00 00 00 | 01 00 00 00 00 00`.

IDML writes the spread's `TimingSetting` after `FlattenerPreference`
and before the pages, and the button's after `TextWrapPreference` and
before the `State` elements (53 of 53). Multi-state objects have chunk
0x2056D with count 0 in all samples; where their timing lists would be
stored is not shown.

### Motion presets (class 0x20517)

Chunk 0x2053E of the preferences object (class 0x2202): u32 *n*, then
*n* preset UIDs. IDML writes one `MotionPreset` in designmap.xml per
UID, in this order, after the `NamedGrid` elements (63 presets in 30
documents; 5 more documents have the chunk with *n* = 0 and no
`MotionPreset`).

Chunk 0x20532 of a preset:

| Field | IDML |
|---|---|
| text string | `Properties/Contents`, as is (63 of 63; IDML writes it as CDATA) |
| 4 bytes | not mapped; they vary without pattern (`00 00 00 00`, `5C 00 50 00`, …) |
| name | empty, flag 1 in all 63 |
| name | `Name`: `$ID/` and the string for flag 1 (63 of 63, all flag 1) |

The chunk parses to its end in 63 of 63. The stored name is not always
the one inside the preset's XML (`appear` stored, `Appear` in the XML's
`<name>`); IDML takes the stored name (2 of 2).

### Animation settings (chunk 0x2055F)

Every spline item (class 0x6201), group (0x401), button (0x1450C) and
multi-state object (0x145D8) has chunk 0x2055F, and so do placed
graphics. Two bytes `00 00` mean no animation: IDML writes no
`AnimationSetting` (1,996 of 1,996 objects with this chunk in the 43
documents, items and graphics). A longer chunk means an animation, and
IDML writes `AnimationSetting` (100 of 100: 57 rectangles, 22 text
frames, 13 ovals, 6 multi-state objects, 2 groups). Longer chunks also
occur in 12 objects that are not written as page items (classes 0x129,
0x1D6, 0x301, 0x3E03, 0x8C41, 0x8C4B, 0xCA8B).

| Offset | Type | IDML | Evidence |
|---:|---|---|---|
| 0 | u16 | not mapped | 1 in 100 of 100 |
| 2 | u16 | `HasCustomSettings`: 1 `true`, 0 `false` | 100 of 100 (20 `true`) |
| 4 | u32 | `Properties/Preset type="object"`: the preset UID | 100 of 100 |
| 8 | f64 | `Duration`, in seconds | 100 of 100 (1, 0.5833…, 1.0416…) |
| 16 | u32 | not in IDML: 24 (frames per second) | 100 of 100 |
| 20 | u32 | not in IDML: frames, `Duration` × 24 | 100 of 100 |
| 24 | u32 | `DesignOption`: 0 `FromCurrentAppearance`, 2 `ToCurrentLocation` | 44 / 56 |
| 28 | u32 | not mapped: 0 in all | 100 of 100 |
| 32 | u32 | `Plays` | 100 of 100 (87 × 1, 13 × 2) |
| 36 | u16 | not mapped: 0 in all | 100 of 100 |
| 38 | u32 | `EaseType`: 0 `NoEase`, 4 `CustomEase` | 3 / 97 |
| 42 | 2 × f64 | `TransformOffsets`, each rounded to 6 significant digits | 100 of 100 (`0.499924 0.499886`) |
| 58 | | motion path key frames, motion path points, properties (below) | |

From offset 58:

```
u32 n             key frames of the motion path
  per key frame:  u32 frame, u32 (2 in all 155), f64 x, f64 y
u32 m             points of a motion path without key frames
  per point:      u32 (2 in all 4), f64 x, f64 y
u32 p             animated properties
  per property:   text string (name), text string (the same name again),
                  u32 k keys, per key: u32 frame, u32 (6 in all 528), f64 value
```

The chunk parses to its end in 100 of 100.

- `Properties/MotionPath`: one `AnimationDataPathKeyFrameType
  KeyFrame="frame"` per key frame, with `PathPoint Anchor="x y"
  LeftDirection="x y" RightDirection="x y"` (98 of 98 with *n* > 0;
  left and right direction equal the anchor in all 155 points). No
  `MotionPath` when *n* = 0 (2 of 2).
- `Properties/MotionPathPoints`: when *m* > 0, a `PathPointArray` with
  one `PathPointType` per point, anchor and both directions `x y` (2 of
  2; both have *n* = 0).
- Properties by name: `Alpha_Amount` → `OpacityArray`, `Rotation_Z` →
  `RotationArray`, `Scale_X` → `ScaleXArray`, `Scale_Y` → `ScaleYArray`;
  each key is `AnimationDataKeyFrameType KeyFrame="frame" Value="value"`
  (all 396 arrays). A property with no keys has no element (1 of 1),
  and neither has a property that is not stored (4 items have no
  `Alpha_Amount`, and no `OpacityArray`). The second name equals the
  first in 396 of 396.
- `Properties` children are in the order `Preset`, `MotionPath` or
  `MotionPathPoints`, `OpacityArray`, `RotationArray`, `ScaleXArray`,
  `ScaleYArray` (100 of 100).

Numbers other than `TransformOffsets` are in the shortest form
(`764.0000000000001`, `-552.6140386840932`, `0.5833333333333334`; all
100 elements). IDML writes `AnimationSetting` after
`ObjectExportOption` and before child items and placed graphics, and
after the `State` elements of a multi-state object (100 of 100).

### Values without a stored field

These attributes have one value in every sample, and no stored field
was found for them. The converter writes that value:

| Attribute | Value | Samples |
|---|---|---:|
| `TimingGroup/@PlaysLoop` | `false` | 159 |
| `TimingTarget/@ReverseAnimation` | `false` | 163 |
| `AnimationSetting/@PlaysLoop` | `false` | 100 |
| `AnimationSetting/@InitiallyHidden` | `false` | 100 |
| `AnimationSetting/@HiddenAfter` | `false` | 100 |
| `MotionPreset/@EditLocked`, `@DeleteLocked`, `@NameLocked` | `false` | 63 each |
| `MotionPathPoints/@PathOpen` | `true` | 2 |

Candidate fields are 0 in every sample: in a timing target the u32
after the action (`ReverseAnimation`?), after a group's plays the u16
(`PlaysLoop`?), in chunk 0x2055F the u32 at 28 (`InitiallyHidden` and
`HiddenAfter`?) and the u16 at 36 (`PlaysLoop`?). Mapping them needs a
sample with a `true` value.

### Not shown

- Codes without samples: `DesignOption` 1 (the schema's third value is
  `ToCurrentAppearance`), `EaseType` 1 to 3, trigger codes other than
  1, 5, 6 and 7. The converter leaves such an attribute out with a
  warning.
- Curved motion paths: every path point has u32 2 before its
  coordinates and left and right directions equal to the anchor.
- Chunk 0x2056C of spreads (a UID list), the 4 bytes after a preset's
  contents and the frame fields at 16 and 20 of chunk 0x2055F are not
  needed for IDML.
- Big-endian files: no samples.

## Placed InDesign pages (class 0x6607)

A placed page of another InDesign document is a child of a frame, like
an image, and has the chunks of placed graphics (transform 0x151,
bounds 0x1633, link 0x8CBC, text wrap). IDML writes it as
`ImportedPage`. Chunk 0x2505 (68 bytes) holds the page: its u32 at 0
plus 1 is `PageNumber`.

The converter writes `ImportedPage` with `PageNumber`, the attributes
of placed graphics (`ImageTypeName` from the link format, `$ID/InDesign
Format Name`), `Properties/GraphicBounds`, `TextWrapPreference` and
`Link`. Not decoded, and left out: `ImportedPageCrop` (41 of 42 are
`CropContent`, 1 `CropBleed`; the byte at 18 of 0x2505 is 0 in 28 and
1 in 13 `CropContent` items, so it is not that field),
`MetadataPacketPreference` (an XMP packet of an object of class 0x12609
that chunk 0x12629 names), `GraphicLayerOption` and `PDFAttribute`.
`ClippingPathSettings` is described under clipping path settings.

Evidence: 42 `ImportedPage` elements in 8 pairs (38 in 7 trustworthy
pairs). `ItemTransform`, `GraphicBounds` and `PageNumber` equal the
IDML in 42 of 42.

## Graphics pasted without a link

A graphic with no link (its chunk 0x8CBC names no link) can hold its file
itself:

| Class | Chunk | Contents |
|---|---|---|
| Image (0x1702), EPS (0x6601) | 0x8C23 | u32 raw data object (0 = none) |
| PDF (0x2501) | 0x2521 | u32 raw data object (0 = none) |

EPS graphics (class 0x6601) without a link name their raw data object in
chunk 0x8C23 too: over the trustworthy pairs of the corpus after
2026-10 the converter reproduces 497 of the 515 EPS `Contents` (483
were missing before; 18 differ and are not examined). Linked graphics
can have the chunk as well; their IDML has no `Contents`, and the
converter does not use it for them.

Evidence from the corpus pairs: the raw data object equals the IDML
`Contents` for 124 of 124 PDFs and 2 of 2 images without a link. In the
whole corpus, two linked and embedded PDFs also have a 0x2521 object,
different from the link resource's; with no pair to compare, the
converter uses the link resource's.

### Images that keep their file in their preview

An image (class 0x1702) without a link whose chunk 0x8C23 is 0 or
absent keeps its file in its preview (next section): chunk 0x170D names
an object of class 0x1708, whose chunk 0x119 names a raw data object.
IDML writes that object's bytes as `Contents`. The converter does so
only for images, and not for an image whose chunk 0x8C1B names an
object (see the end of this section). Linked graphics, EPS and PDF
graphics do not use their preview as `Contents`.

Evidence, over the 9,608 graphics (`Image`, `EPS`, `PDF`, `SVG`, `WMF`,
`ImportedPage`) in the reference IDMLs of the 1,252 trustworthy pairs,
each paired with its INDD object by `Self`:

| Images | Count | IDML `Contents` | Preview data equals `Contents` |
|---|---:|---:|---:|
| No link, 0x8C23 = 0 | 359 | 359 | 359 |
| No link, no chunk 0x8C23 | 17 | 17 | 17 |
| No link, 0x8C23 names a raw data object | 77 | 77 | 4 (the 0x8C23 object equals it in 77) |
| Linked, embedded | 101 | 101 | 38 |
| Linked, not embedded | 6,886 | 0 | – |

- The 376 images of the first two rows are in 31 pairs, InDesign 8.0 to
  18.x. None of them lacks `Contents` in its IDML. Of the 362 that the
  converter writes, 357 have chunk 0x8C1B set to 0 and 5 have no chunk
  0x8C1B.
- Over the whole little-endian corpus (5,734 distinct files), 2,456
  images without a link have 0x8C23 = 0 or no 0x8C23. All of them have
  the complete chain: 0x170D names a class 0x1708 object whose chunk
  0x119 names a raw data object. No image without a link has a 0x8C23
  that names anything other than 0 or a raw data object. 1,773 of them,
  in 150 files (InDesign 3.0 to 21.x), have 0x8C1B = 0 or no 0x8C1B;
  the converter writes their preview data as `Contents`. 15 more are in
  3 big-endian files (InDesign 8.0 and 11.x).
- The 17 images with no chunk 0x8C23 have no chunk 0x8CBC either; 5 of
  them (InDesign 8.0 and 11.x) have only 11 or 12 chunks.
- Every EPS (483) and PDF (111) graphic without a link names a raw data
  object, so the case occurs only for images. For EPS graphics without a
  link the preview never equals `Contents` (0 of 483).
- Formats of the 376 `Contents`: 357 in the `EPSImage` form below, 17
  JPEG, 2 TIFF. Of the 2,456 in the whole corpus: `EPSImage` 1,539,
  JPEG 514, TIFF 391, PNG 12.
- The converter reproduces 362 of 362 such `Contents` that it writes in
  the trustworthy pairs, in 20 documents, with no `Contents` where the
  reference has none. The other 14 images belong to structures the
  converter leaves out.

**The `EPSImage` form.** 357 of the 376 `Contents` start with the 8
ASCII bytes `EPSImage`, then five u32 (little-endian): bytes per row,
width, height, bits per channel, channels. Pixel data follows, height ×
bytes per row bytes, with nothing after it: the length is 28 + height ×
width × channels in 357 of 357 (8 bits per channel in all; 3 channels in
182, 4 in 175). All 357 have 0x8C23 = 0. The converter copies the bytes
and does not read this form.

**Images that name an old link object.** 762 images without a link
and with 0x8C23 = 0 or no 0x8C23, in 79 files of InDesign 2.0 to 5.0
(683 images in 53 little-endian files, 79 in 26 big-endian files), have
no chunk 0x8CBC, and their chunk 0x8C1B (u32) names an object of class
0x8C01. That object's chunk 0x8C2A names the image back in 759 of 762.
No file of these versions has an IDML pair, so it is not known whether
IDML would write the preview as `Contents`. The converter treats these
images as linked graphics whose link it does not read: no `Contents`,
and the preview goes to `Conversion::previews`. In files of later
versions, 0x8C1B of such an image is 0 or absent in every case.

Not known: why these images keep their file in the preview rather than
in a raw data object named by 0x8C23. None of the 77 images whose 0x8C23
names a raw data object has an `EPSImage` `Contents`. The one WMF
graphic without a link in the pairs has a `Contents` different from its
preview; it is not examined.

## Graphic previews

Placed graphics also have chunk 0x170D, the UID of an object of class
0x1708, whose chunk 0x119 names a raw data object. In the 245 distinct
little-endian files, these objects are TIFF (613), JPEG (411), PNG (307),
GIF (27) and one other. They equal the IDML `Contents` of embedded links
in 38 of 101 and of EPS graphics without a link in 0 of 483, so they are
most likely screen previews. The exception is the images of the
previous section, whose preview is their file. The package does not
include the other previews: IDML has no place for a preview.
`indd::convert` returns the previews of graphics without `Contents` in
`Conversion::previews`, so an application can show one when the linked
file is missing. An image whose `Contents` is its preview's data is not
in that list: the package holds its file.

## Embedded data in IDML

The reference IDML files write `Contents` inside the graphic's
`Properties` as base64 (with `=` padding) in lines of 76 characters joined
by a line feed, with no line feed at the end. The text is split into
CDATA sections of 262,144 characters. The converter writes the same form.

## Stories (0x201)

Chunk 0x223: u32 length, u16, u32 first strand, UID list of more strands,
then other fields. Each strand has chunk 0x261: u16 count, then (u32
length, u32 data object UID) pairs. Each data object has chunk 0x262:

| Field | Contents |
|---|---|
| u32 | Kind: 0x202 text, 0x203 character style runs, 0x204 paragraph style runs |
| u32 | Owning strand |
| u16 | Run count |
| runs | Each: u32 record size, then the record |
| u32 | Total length |

Each record starts with a u32 run length in UTF-16 code units. Text
records continue with text segments. Style records continue with the
style UID.

**Paragraph-style records and paragraph ranges.** Counts are over the
INDD files of the 1,252 trustworthy pairs and the 37,156 stories that
both IDMLs have.

- Every paragraph-style record ends at a paragraph end (U+000D):
  87,496 of 87,496 records.
- After its text attribute list (`attributes.md`), a paragraph-style
  record has a u16 count and that many u32 values. In 82,842 of the
  87,496 records they are the lengths of the record's paragraphs, in
  order, and add up to the run length. In the other 4,654 some values
  have high bits set (for example 0x10000F74). The converter does not
  read these values.
- IDML starts a `ParagraphStyleRange` at every paragraph-style record,
  also between neighbouring records with the same style and the same
  decoded attributes. There are 2,496 such boundaries in 459 stories:
  913 between two data objects of the strand and 1,583 within one. 153
  of them are between records whose bytes after the run length are
  identical. Other rules split a record's range further (XML elements,
  `xml.md`; tracked changes, below).
- With one range per record, the text lengths of the non-empty
  paragraph ranges equal the reference in 37,133 of 37,156 stories,
  including 455 of the 459 stories with equal neighbours. No story
  has more ranges than the reference. Merging neighbours with equal
  formatting matches 36,810 stories. Of the 23 other stories, 3 have
  different text and 20 have ranges that the reference splits inside
  one record (`unknowns.md`, resources and text).
- Character-style records with the same style and decoded attributes
  are neighbours only across a data-object boundary: 3,288 boundaries
  in 533 stories, none within one data object. IDML splits there too.
  The converter writes a `CharacterStyleRange` per character-style
  record (and further cuts), and the character range lengths equal the
  reference in 525 of these 533 stories and in 37,112 of all 37,156.

**Stories outside the document's list.** The document's story list does
not name the stories of text frames anchored in the XML backing story.
IDML writes them like the others and lists them at the end of
`StoryList`: one trustworthy document (in two pairs) has 9 such stories,
whose frames are anchored in its backing story; its IDML has all 9
after the listed stories. The converter adds the stories of the text
frames anchored in the backing story, and of frames anchored in those
stories, after the listed ones, in text order. The order IDML gives
them is not that order (it starts with a later one), so `StoryList`
stays different there.

**Story settings.** Three chunks of the story object (trustworthy
pairs, 18,610 stories):

| Chunk | Layout | IDML | Without the chunk | Evidence |
|---|---|---|---|---|
| 0xA44C | flag byte (1 for a built-in key), in-object string | `Story` `StoryTitle` (`$ID/` and the key for flag 1) | `$ID/` | 18,610 of 18,610 (30 with a name) |
| 0x50F96 | u16: 1 | `StoryPreference` `StoryDirection="RightToLeftDirection"` | `LeftToRightDirection` | 18,610 of 18,610 (780 right to left, 10 documents) |
| 0x2EE (16 bytes) | u16 at 0; f64 at 2; u16 at 10 (not identified); u16 at 12 (1 `true`); u16 at 14 | `StoryPreference` `StoryOrientation` (u16 at 0: 0 `Horizontal`, 1 `Vertical`), `OpticalMarginSize`, `OpticalMarginAlignment`, `FrameType` (u16 at 14: 0 `TextFrameType`, 1 `FrameGridType`) | 12 (13 Q where text sizes are in Q, below), `false`, `Horizontal`, `TextFrameType` | alignment 18,610 of 18,610; size below; orientation and frame type below |

`OpticalMarginSize` over the 37,156 stories of the 1,252 trustworthy
pairs of 2026-10 (DOM 8.1 to 21):

| Story | Stories | IDML `OpticalMarginSize` |
|---|---:|---|
| with chunk 0x2EE | 3,805 | the f64 at 2 (all) |
| no chunk, `TextSizeMeasurementUnits` `Points` | 32,979 | 12 (all) |
| no chunk, `TextSizeMeasurementUnits` `Q` | 372 (76 pairs) | `9.2125984251969` (13 Q, all) |

The Q documents are DOM 12.1, 13, 16.2, 18 and 20.3. The text size
unit is the u32 at 12 of preferences chunk 0x1202 (`preferences.md`,
view). The size of new frames in the preferences is not the
source: in 3 pairs it differs from the stories without the chunk. Two
DOM 8.1 pairs in points have 13 Q in the preferences and 12 in their
13 stories; one DOM 16.2 pair in Q has 12 in the preferences and 13 Q
in its 3 stories. The text size unit gives the story value in all
three. Another value of the direction or alignment u16 leaves the
attribute out.

Orientation and frame type, over the
28,669 stories of all corpus pairs (stale pairs included), with chunk
0x2EE as (u16 at 0, u16 at 14):

| Chunk | Stories | IDML `FrameType`, `StoryOrientation` |
|---|---:|---|
| none | 25,206 | `TextFrameType`, `Horizontal` (all) |
| (0, 0) | 3,359 | `TextFrameType`, `Horizontal` (all) |
| (0, 1) | 4 | `FrameGridType`, `Horizontal` (all) |
| (1, 0) | 47 | `TextFrameType`, `Vertical` (all) |
| (1, 1) | 53 | `FrameGridType`, `Vertical` (all) |

The vertical and frame grid stories are in documents typeset in
Japanese (DOM 12, 13 and 18). Another frame type value leaves
`FrameType` out. For another orientation value the converter uses the
orientation of the story's frames (text orientation, below).

**Frame grids.** Over all pairs of the corpus of 2026-10:

- Chunk 0xCD41 of a text frame's multi-column frame object (class
  0x263, the child that the frame's chunk 0x15B lists) is `00 00` for a
  plain frame (23,537 of 23,537) and starts with u16 1 for a frame grid
  (248 of 248; 100, 146, 192 or 238 bytes). IDML writes an empty
  `GridDataInformation` in the `TextFrame` for exactly these 248 frames,
  after `Properties`, with `GridView="GridViewEnum"`,
  `CharacterCountLocation="BottomAlign"` and `CharacterCountSize` equal
  to the `CharacterCountSize` of the document's story grid preference
  (chunk 0xCD2E, `preferences.md`): 248 of 248 in 39 documents. The rest
  of the chunk is not decoded.
- The stories of these frames are the frame grid stories of chunk 0x2EE
  (above): 57 of 57. They have chunk 0xCD02 in the story object, with
  the layout of the page chunk (layout grid, below), and IDML writes a
  `GridDataInformation` in the `Story`, after `StoryPreference` and
  before `InCopyExportOption`, with the same values: 57 of 57 for every
  attribute. 223 other stories have the chunk but are not frame grid
  stories, and IDML writes no `GridDataInformation` for them. One frame
  grid story in the trustworthy pairs has the IDML element but no
  chunk.

The converter writes both elements by these rules.

**Owned items (run kind 0x209).** Each record: u32 run length, u16
count, then that many (u32 class, u32 UID) pairs, the objects owned by
the text position at the start of the run. An item anchored in text has
the character U+FFFC at that position and is owned through an object of
class 0x262, whose chunk 0x2C8 (u32, u32, UID list) lists the anchored page
item. IDML writes the page item element in place of the U+FFFC.
A text variable instance (class 0xCA64) is owned by a U+0018 at its
position; see `text-variables.md`. Footnotes (class 0x24F) and endnotes (class
0x2805) are owned by a U+0004 (`footnotes.md`), text and paragraph
destinations through class 0x1353C by a U+FEFF (`hyperlinks.md`).

**Text owners.** The text-owner strand (run kind 0x2A4, `tables.md`)
gives each stretch of a story's text an owner. In the 495 trustworthy
pairs of the research run the owners were the story itself (19,418
stretches), a table (class 0xB608, 11,844), a deleted text (class 0xA40A,
1,889), a footnote (class 0x24F, 502) and a note (class 0xA429, 186). The
cell field is 1 for footnotes and 0 for the story, deleted texts and
notes. Each footnote, note and deleted-text stretch ends with U+000D
(2,577 of 2,577), which IDML does not write, as for a table cell.

**Ruby strand (run kind 0x420D).** A story can list a strand of class
0x420C (chunk 0x4216: u32 data object, u32 story) whose data objects
(class 0x42B9) have chunk 0x262 with run kind 0x420D. The runs cover the
whole story text. After the run length a record has u16 1 if attributes
follow (0 otherwise), a u16 count and text attribute records
(`attributes.md`). Over the little-endian corpus: 911 stories, 11,514
runs, 7,442 with attributes. The records hold only ruby attributes, a
copy of those on the character runs. IDML does not use the copy: all
185 IDML ruby ranges of the pairs have the character run's values, and
where the two differ (5 ranges, whose strand string lacks the U+3000
separators; 16 ranges with 0x423E only on the character run) IDML
follows the character run. IDs found only in the strand, such as 0x4232
in 6,176 records, are not in IDML. The converter skips this strand.

**Notes (class 0xA429).** A note is owned by a U+FEFF (186 of 186), and
IDML writes a `Note` element in its place, inside the character range;
the `Note` holds the note's text stretch as paragraph and character
ranges. Chunk 0xA412: u32 length *n* and *n* UTF-16 units of text
segments (the user name), then two FILETIME values (u32 high part, u32
low part; 100 ns since 1601-01-01 UTC), creation and modification, then
u16 (0 in all 186). Attributes, in this order:

| Attribute | Value |
|---|---|
| `Collapsed` | `false` in all; the trailing u16 may hold it, but it never varies |
| `CreationDate`, `ModificationDate` | the two times as local time, by the link time rule below |
| `UserName` | the user name; `$ID/Unknown User Name` when the first document user of that name has flag 2 |
| `AppliedDocumentUser` | `dDocumentUser<index hex>` of the first document user (document chunk 0xA443) with that name; `n` if none has it |

Check: over all pairs the converter's notes equal the IDML notes on these
five attributes in 211 of 211 (compared as multisets per pair, since
`Note` has no `Self`).

**Tracked changes.** Deleted text is an object of class 0xA40A, owned by
the character that follows the deletion (any character; 1,696 of 1,889
in the research run were U+F035). Its text is the stretch the text-owner
strand gives to its UID, without the final U+000D. IDML writes it as
`<Change ChangeType="DeletedText">` inside the character range of the
owning character, before that character and before any element that
replaces it, holding the deleted text as paragraph and character ranges
(one `Change` per object: 1,889 of 1,889 in 21 pairs).

A story strand of class 0xA465 has runs of kind 0xA466 that cover the
whole story text (positions count characters). Each record: u32 run
length, u16 entry count, then per entry a flag byte (0), a string (the
user name, in-object form), u16 kind, FILETIME (u32 high part, u32 low
part) and u16 (0). Kind 1 is a deletion at the start of the run, with the
user and time of that deleted text; kind 2 marks the run's text as
inserted, which IDML writes as `<Change ChangeType="InsertedText">`
around it (2,073 of 2,073 entries, one element each). Records of
deleted-text stretches have no entries. `Change` attributes, in this
order: `Date`, `ChangeType`, `UserName`, `AppliedDocumentUser`, the last
two by the rule for notes.

**Where IDML puts an inserted-text `Change`.** IDML writes it at the
lowest level that holds its whole extent, as for hyperlink sources
(`hyperlinks.md`, extent and placement). The 3,962 `Change` elements of
the 21 trustworthy pairs with tracked changes sit as follows:

| Parent | Content | Elements |
|---|---|---:|
| `CharacterStyleRange` | inserted text within one range, also across a `Br` where the range goes on, and empty changes | 1,989 |
| `CharacterStyleRange` | deleted text | 1,887 |
| `CharacterStyleRange` | a `HyperlinkTextSource` with the change's extent | 43 |
| character-level `HyperlinkTextSource` | inserted text from inside the source to its end | 13 |
| `ParagraphStyleRange` (story or cell) | `CharacterStyleRange` children, and paragraph-level sources inside the extent | 23 |
| paragraph-level `HyperlinkTextSource` | `CharacterStyleRange` children | 4 |
| `Cell` | deleted text at the cell's end | 2 |
| `Story` | `ParagraphStyleRange` children | 1 |

So a change over several character ranges of one paragraph range is a
child of the `ParagraphStyleRange`, one over several paragraph ranges
a child of the `Story`, and one over several character ranges inside a
paragraph-level source a child of the source. A change with the extent
of a source holds it (`hyperlinks.md`, sources in tracked changes). The
ranges are split at the ends of such a change, as at a source.

The converter writes deleted text before the owning character. It
writes inserted text that lies in one text run in a `Change` inside the
character range. Inserted text over several runs (once the runs are
split at the paragraph-level sources) is written above them: as a child
of the paragraph range, or of the story where the runs belong to more
than one paragraph range, which then ends and starts again at the
change's ends. Inside a lifted change the character ranges have no
`Change` of their own. A table, an anchored item (the schema allows no
page item in a `Change`) or an XML marker in the extent keeps the
change inside each character range, opened again after the element; so
does a change that does not nest with a paragraph-level source.

Over the 21 trustworthy pairs the output has 3,969 `Change` elements,
and 3,960 of the 3,962 reference elements have an equal one (`Date`,
`ChangeType`, `UserName`, compared as multisets per pair). The
differences are the 4 changes of the export defect below and a few
changes still split. compare.py gains
13 range starts at the ends of lifted changes. Where a hyperlink source
starts with inserted text, IDML writes an empty `Change` before the
source (`hyperlinks.md`, sources at inserted text).

**Export defect.** In one trustworthy pair, 4 inserted-text changes
start inside a paragraph-level source and end after it. IDML writes each
inside the source, holding the text past the source's end, and writes
text after the source that the INDD stores once. The converter writes
the INDD's text once, so this story counts as "story text differs" in
compare.py.

A deletion owned by the U+000D that ends a table cell, which no
character range holds, is the last child of the `Cell`, after its last
`ParagraphStyleRange` (2 in one trustworthy pair, 1 in a stale pair;
every other deletion of the corpus is owned by a character inside a
range). With it the converter writes all 1,889 deleted-text `Change`
elements of the trustworthy pairs.

**Dates of notes and changes.** IDML writes `CreationDate`,
`ModificationDate` and `Date` as local time of the exporting computer,
like link times: the converter applies the link time rule below (the
offset of the XMP date nearest in day of the year). With it, 211 of 211
notes and 6,024 of 6,027 changes have an equal element in the output;
the other 3 are deleted texts, not examined further. The 21 pairs with tracked changes come from at most two
computers in one time zone, so the rule is checked on one time zone
only.

**Index markers (class 0x13006).** An index marker is owned by a U+FEFF,
which is not text in IDML: IDML writes a `PageReference` in its place.
Its layout and attributes are in `index.md`.

**Anchored object settings (chunk 0x2800).** The anchor object (class
0x262), object styles and the preferences have a 62-byte chunk 0x2800:

| Offset | Contents | IDML `AnchoredObjectSetting` |
|---|---|---|
| 0 | f64 | `AnchorYoffset` |
| 16 | f64 | `AnchorXoffset` |
| 32 | f64, the negative of the value at 0 in every sample | |
| 40 | u16: 0 `InlinePosition`, 1 `Anchored`, 2 `AboveLine` | `AnchoredPosition` |
| 42 | u16: 1 `TextFrame`, 2 `PageMargins`, 3 `PageEdge`, 4 `AnchorLocation` | `HorizontalReferencePoint` |
| 44 | u16: 2 `PageMargins`, 3 `PageEdge`, 4 `LineBaseline`, 6 `Capheight` | `VerticalReferencePoint` |
| 46, 50 | u16, u16 (below) | `AnchorPoint` |
| 48 | u16: 0 `RightAlign`, 1 `CenterAlign`, 2 `LeftAlign` | `HorizontalAlignment` |
| 52 | u16: 0 `TopAlign`, 1 `CenterAlign`, 2 `BottomAlign` | `VerticalAlignment` |
| 54 | u16: 0 `false`, 1 `true` | `SpineRelative` |
| 56 | u16: 0 `false`, 1 `true` | `PinPosition` |

`AnchorPoint` from the u16 at 46 and at 50: (0, 2) `BottomRightAnchor`,
(2, 2) `BottomLeftAnchor`, (2, 0) `TopLeftAnchor`, (0, 0)
`TopRightAnchor`, (2, 1) `LeftCenterAnchor`. The field at 46 is 0 for a
right and 2 for a left point, the one at 50 is 0 for top, 1 for centre
and 2 for bottom, as the alignment codes; the converter writes only
these five combinations.

Evidence, corpus of 2026-10: the 6,363 object styles whose name matches
one IDML style (5,457 in trustworthy pairs), the 1,076 anchored items
matched by `Self` with their IDML element (944 trustworthy; where the
item element lacks an attribute, its object style's value), and the
1,295 preference chunks (`preferences.md`). Every field above matches
in every one. Codes seen: `AnchoredPosition` `Anchored` in 41 and
`AboveLine` in 37 styles, in 116 and 2 items; `SpineRelative` `true` in
2 styles (the only ones with 1 at 54); `HorizontalAlignment`
`RightAlign` in 24 and `CenterAlign` in 37 styles. On the items, 42 and
44 are (4, 6) in 4 items, (2, 2) in one, (3, 3) in one and (1, 4) in
the others. The two fields change together in every sample, so
which one is the horizontal point is assumed from the order of the IDML
attributes; codes 2 and 3 mean the same in both.

IDML writes an anchored item's `AnchoredObjectSetting` by the category
rule of other object style settings: every value when the item's object
style turns the category off (`EnableAnchoredObjectOptions`, ID 0xCA2F
missing from the style's category list; 670 items, all with every
value), and otherwise the values that differ from its object style (406
items, of `[None]` or of styles with the category on). Where it writes
every value, it also writes `LockPosition="false"` and
`AnchorSpaceAbove="0"`, the values of every such element in the corpus
(`idml-values.md`, anchored object settings of page items).

**Items inside an anchored item.** The children of an anchored group
(and the items inside them) have an `AnchoredObjectSetting` too. IDML
applies the rule above to each of them with the anchor's chunk 0x2800
values and the child's own object style: every value where the child's
style turns the category off, else the values that differ from that
style. With this rule the converter writes 584 more `AnchoredObjectSetting`
elements over the trustworthy pairs of the corpus after 2026-10 (344 on
text frames, 114 ovals, 61 rectangles, 30 polygons, 22 graphic lines, 7
groups, 6 text boxes), with every value equal and no extra value; 6,503
values of these elements were missing before, and 388 in 2 or 3
documents per element still are (not examined).

**Positions count characters.** A text record's run length counts
UTF-16 code units, but every other position counts characters, a
surrogate pair being one: the lengths in a strand's chunk 0x261 (also
for the text strand), and the run lengths of style runs, owned items and
text owners. Evidence: the 6 stories of the little-endian corpus whose
text has a character outside the Basic Multilingual Plane (emoji, all in
one pair). In all 6 the text records add up to the number of UTF-16
units, and the other strands and all chunk 0x261 lengths to the number
of characters; with that reading, each emoji gets the character style
range IDML gives it (6 of 6). The converter applies the same reading to
hyperlink range trees, for which no sample with such a character exists.

U+FEFF characters can be XML markers, which IDML does not write
(`xml.md`).

INDD stores a forced line break as U+000A; IDML writes it as U+2028. The
last paragraph return of a story is not written to IDML.

## Story links and placed text

Stories placed from another story (linked stories), from a Word or
Excel file, and the text frames that linked page items copy, carry the
elements below. Evidence base: the 159 distinct corpus pairs whose IDML
has any of them (158 little-endian), and for the presence rules all
45,640 stories of the distinct little-endian pairs. No story has an
element below without its stored data, and none has the data without
the element.

### Link lists (chunk 0x8CBC)

Chunk 0x8CBC is a list of link UIDs: 4 bytes (`01 01 00 00`), u32
count *n*, then *n* UIDs. It occurs on stories (0x201), spline items
(0x6201), groups (0x401), graphics, link resources and more; the empty
list (8 bytes) is the common case (28,569 spline items). Graphics and
movies read the UID at offset 8, the first entry. No object in the
corpus has more than one entry.

### Story links

A story with a non-empty 0x8CBC list has a `Link` child in IDML, and
`Link Self` is `u` and the listed UID in hexadecimal: 47 of 47 stories
whose UID is in both files; no story with a link lacks the IDML `Link`,
and none the other way round, over the 45,640 stories.

The link object has the layout of a graphic link (placed graphics,
links), with the story's UID at offset 16 of chunk 0x8C9B (47 of 47),
and its resource (class 0x8C41) the same chunk 0x8C92:

| IDML | Equal |
|---|---|
| `LinkResourceURI` | 45 of 47 (2 links to another document, resolved to another path at export) |
| `LinkResourceFormat` (`$ID/` and the format name) | 47 of 47: `Internal Linked Story` 28, `External Linked Story` 2, `Microsoft Office Word 2007 Import Filter` 17 |
| `LinkImportStamp` | 47 of 47 (a plain number such as `1653409666` for linked stories, `file …` for Word files) |
| `LinkResourceSize` | 47 of 47 (`0~0` for linked stories, the file size for Word files) |
| `LinkResourceModified`, `ShowInUI` | 47 of 47 each |
| `StoredState="Contained"` | 47 of 47 (resource field 3, placed graphics, link resources) |

`RenditionData` and `PDFIdentifier` follow the rules of graphic links:
present on the 17 version-14 Word links and the 49 version-21.0 links,
absent on the 30 version-10 links.

Link object classes (`LinkClassID` is the class in decimal):

| Class | `LinkClassID` | Links | URI |
|---|---|---|---|
| 0x8C42 | `35906` | all graphic links; 17 stories placed from Word | `file:` |
| 0x21D03 | `138499` | 30 linked stories | `idinternalcontent:<id>`, `idexternalcontent:<path>?<id>` |
| 0x21D32 | `138546` | 3 linked page items (text frame, group) | `idinternalSharedArticle:`, `idexternalSharedArticle:` |

The converter writes story links. Links of page items (class 0x21D32)
are not written: their page item's `LinkedPageItemOption` was not
studied.

### Link source IDs (`LinkResourceId`)

`idinternalcontent:<id>` names the story a link copies by an ID, and
that story has `LinkResourceId="<id>"`. A text frame can have one too
(the source of a linked page item). The IDs are in chunk 0x21D06 of the
document object (UID 1):

| Offset | Type | Contents |
|---|---|---|
| 0 | u32 | not identified (non-zero even when the list is empty) |
| 4 | u32 | count *n* |
| 8 | *n* × (u32, u32) | ID, UID of a story or spline item |

IDML writes `LinkResourceId="<ID>"` (decimal) on the element whose
`Self` is that UID. In 36 of 36 distinct pairs whose IDML has any
`LinkResourceId`, the set of (UID, ID) equals the chunk's list exactly
(195 values: 189 `Story`, 6 `TextFrame`; 31 trustworthy documents). In
the other 1,500 pairs the list is empty. Listed UIDs are stories and
spline items, all `TextFrame` in IDML. IDs are below 32,768. The
converter writes the attribute on stories and text frames; a listed UID
that is not written is ignored.

### Linked story options (chunk 0x21D12)

Chunk 0x21D12 (10 bytes) on a story. IDML writes `Story/LinkedStoryOption`
when the story has the chunk and a link (30 of 30). Two stories with the
chunk and no link have no `LinkedStoryOption`; stories placed from Word
have no chunk.

| Offset | Seen | IDML |
|---|---|---|
| 0–5 | `00 00 01 00 00 00` in all 30 | `UpdateWhileSaving="false"`, `WarnOnUpdateOfEditedStory="true"`, `RemoveForcedLineBreaks="false"` in all 30 (which byte holds which is not shown; the converter writes these values) |
| 6 | u32 | `ApplyStyleMappings`: 1 `true` (28), 0 `false` (2) |

The preferences object (0x2202) has the same chunk (`00 00 01 00 00 00 00
00 00 00` in every document); the document's `LinkedStoryOption` is
written from observed values (`idml-values.md`).

### Style mappings (chunk 0x21D30)

Chunk 0x21D30 holds five lists. Each list: u32 count, then per entry a
kind byte (2 or 3), an in-object string (source name), a kind byte (2),
an in-object string (destination name) and a u32 rule.

| List | IDML |
|---|---|
| 1 | `ParaStyleMapping` |
| 2 | `CharStyleMapping` |
| 3–5 | empty in every sample (the schema has `TableStyleMapping` and `CellStyleMapping`; which list is which is not shown) |

| Rule | `MappingRuleType` | IDML name | Seen |
|---|---|---|---|
| 0 | `StyleMappingRule` | as stored | 4 |
| 1 | `GroupMappingRule` | `:*` after source and destination | 60 |
| 2 | `StyleToGroupMappingRule` | `:*` after the destination | 30 |

The kind byte does not add `$ID/` (kind 3 is on `[Basic Paragraph]`
under a localized name). Group names may contain `/`
(`<group>/<subgroup>`), written as stored. Attributes: `Self` is the
owner's `Self`, then `ParaStyleMapping` or `CharStyleMapping` and the
index in its list from 0; `SourceStyleName`, `DestinationStyleName`,
`MappingRuleType`.

- **Story**: a story chunk longer than 20 bytes gives the story's
  elements (32 of 32 stories; 107 elements equal, `Self` included). The
  empty form is 20 zero bytes (75 stories), and no story with it has
  mappings.
- **Document**: chunk 0x21D30 of the preferences object (class 0x2202),
  in `designmap.xml` with `Self="dParaStyleMapping<i>"`. Non-empty in 1
  of 1,553 documents, the only one with `ParaStyleMapping` in
  `designmap.xml` (2 `StyleMappingRule` entries, equal). 1,431 documents
  have the empty chunk, 121 none.

Rule code 3 and entries in lists 3 to 5 are not seen; the converter
leaves them out with a warning.

### Import options of placed text (chunk 0x12202)

Story chunk 0x12202 is 8 bytes: u32 UID of an import options object,
u32 0 (in all). The class of that object decides the `Properties`
child:

| Class | IDML | Stories |
|---|---|---|
| 0x12210 | `WordRTFImportPreferences` | 39 of 39 |
| 0x12213 | `ExcelImportPreferences` | 9 of 9 |
| UID 0 | none | 20 |

**Word (class 0x12210).** Chunk 0x12210: 19 u32 (*s0* … *s18*). IDML
writes a list of 19 items for versions 8 to 12 and 20 for 14 to 20 (no
version-13 sample). This mapping reproduces all 39 stories (8 with 19
items, 31 with 20; 10 distinct option sets):

| Item (20-item list) | Type | Value |
|---|---|---|
| 0, 1 | boolean | *s0* ≠ 0, *s1* ≠ 0 |
| 2 | enumeration | *s5*: 0 `PageBreak`, 2 `None` (1 sample) |
| 3 | boolean | `true` (no stored field) |
| 4 | enumeration | `UnformattedTable` (no stored field) |
| 5, 6 | boolean | *s8* ≠ 0, *s9* ≠ 0 |
| 7 | boolean | `false` (no stored field) |
| 8, 9 | enumeration | *s11*, *s12*: 0 `ResolveClashUseExisting`, 2 `ResolveClashAutoRename` (1 sample each) |
| 10 to 13 | boolean | *s14*, *s15*, *s16*, *s17* ≠ 0 |
| 14 | boolean | `false`, only in the 20-item list (no stored field) |
| 15, 16 | boolean | `true` (no stored field) |
| 17 | long | *s4* (1 or 2) |
| 18, 19 | boolean | `false` (no stored field) |

The 19-item list is the same without item 14. In every sample *s0* =
*s1*, *s14* = *s15* and *s16* = *s17*, so the order within each pair is
not shown, and items 0/1, 10/11 and 12 are told apart only by assuming
the same stored layout in both list lengths. Code 1 of *s5*, *s11* and
*s12* is not seen; the converter leaves the property out with a warning
for a code not in the table.

**Excel (class 0x12213).** Chunk 0x12213:

| Offset | Type | Seen | IDML item |
|---|---|---|---|
| 0 | u32 | 1 | |
| 4 | u32 | 0 | |
| 8 | u32 | 3 | |
| 12 | u32 | 0 | |
| 16 | u32 | 0 or 1 | 3: 0 `ExcelFormattedTable` (5), 1 `ExcelUnformattedTable` (4) |
| 20 | u32 | 1 | |
| 24 | flag byte, in-object string | flag 1, `Sheet1` | 7: `$ID/Sheet1` |
| then | flag byte, in-object string | flag 0, the range (4 distinct values) | 8: the range |
| then | flag byte, in-object string | flag 1, empty | 6: `$ID/` |
| then | u32 | 1 | |

The strings are written as names (`$ID/` and the string for flag 1).
Every sample has the list `Spreadsheet` (enumeration), `3` (long),
`false`, the table option, `true`, `true`, item 6, item 7, item 8, `1`
(long). Items 0, 1, 2, 4, 5 and 9 have no identified field: the longs
`3` and `1` equal the u32 at 8 and the last u32 in every sample, which
does not show that they come from them.

### Style mapping preferences (chunk 0x12216)

Story chunk 0x12216: u32 *p*, u32 *c*, then 2·*p* names (paragraph
styles: source, destination, …) and 2·*c* names (character styles),
each a flag byte (0 to 3) and an in-object string. When *p* + *c* > 0,
IDML writes `Properties/StyleMappingPreferences`: a list of two lists of
strings, the paragraph names and the character names (empty when *c* =
0), as stored (flag 1 does not add `$ID/`). 67 of 67 stories with the
chunk (29 non-empty; *p* and *c* up to 13); no story has
`StyleMappingPreferences` without the chunk. The import options come
before it in `Properties`; no story has Excel options together with it.

### Element order

In all 107 stories with these elements InDesign writes: `Properties`
(import options, then `StyleMappingPreferences`), `StoryPreference`,
`GridDataInformation`, `LinkedStoryOption`, `InCopyExportOption`,
`ParaStyleMapping`, `CharStyleMapping`, `Link`, then the text. The
schema allows this order (`Story.rnc`). In `designmap.xml` the document
mappings follow the `idPkg:Story` references.

### Plugin data

Stories of 39 version-14.0 documents also carry data of two third-party
plugins (`DocsFlowImportSettings`, the `WordsFlow…` properties, the
`Story` attributes `Observers` … `ComponentId`). The published IDML
schema rejects it, and it follows the plugins of the exporting computer;
the converter does not write it (`unknowns.md`, plugin data;
`docs/measurement.md`).

## Styles (0x205)

Paragraph and character styles share the class. Chunk 0x230: u32 next
style (0 = itself), u32 based-on style, fields not yet identified, u16 1
for paragraph styles or 0 for character styles, u16 `Imported` (1 =
true), u8 1 if the name is a built-in key (`$ID/` in IDML), the name as
an in-object string, then, in newer files, a GUID string
(`StyleUniqueId`). The name's offset varies (23–26
bytes), so the converter locates it as a flag byte followed by a valid
in-object string.
All 486 style names and 291 `NextStyle` values in the pairs match.

**Imported and unique ID.** Over the 4,694 paragraph and character
styles of the trustworthy pairs whose IDML style has the same name, the
u16 after the kind equals `Imported` in 4,694 (180 imported). The GUID
is a 36-character in-object string after the name's string; the byte
after its string tag is not always 0. Every `StyleUniqueId` in the
corpus IDML files is a GUID of lowercase hexadecimal digits in groups of
8, 4, 4, 4 and 12 (7,953) or `$ID/` (4,299), so the converter accepts
only that form, searching from the end of the name. A search from the
name's own flag byte took a style name of 36 characters for the GUID.

IDML has `StyleUniqueId` on every paragraph and character style, the
root styles included, when the document was saved by 11.2 or later
(header or last session of the save history): the stored GUID, or
`$ID/` for a style without one. Earlier documents have none. Over the
trustworthy pairs the converter reproduces 6,313 of 6,316 paragraph and
3,734 of 3,735 character style values. The exceptions are pairs whose
IDML was exported by another minor version than the INDD records: four
11.4 documents whose IDML has DOM 11.0 and no `StyleUniqueId` (34
values written though the IDML has none), and one 11.0 document whose
IDML (DOM 11.4) has `$ID/` (3 values missing); one paragraph style has
another GUID in IDML.

**Kind field.** The kind and the `Imported` u16 after it can be read
as one u32 in most files, because the second u16 is 0. The InDesign 7.5
template fixture `scml-template/scml.indt` (no IDML) has 1 there in 600
of its styles: 151 have `00 00 01 00` before the flag and 449 have
`01 00 01 00`. The 151 are all listed in the tree of the root character
style group (chunk 0x28C2 = 0xCA0D, below) and the 449 in the tree of the
root paragraph style group, so the kind is the first u16 alone. Read as a
u32, the 151 character styles were taken for paragraph styles, which gave
`ParagraphStyle/…` references and a `NextStyle` that the schema does not
allow on a character style. In every other distinct little-endian corpus
file the u32 is 0 or 1 (2,125 styles), and the kind agrees with the root
group in all of them. In the two big-endian files the u16 kind is also
the first two bytes (`00 01` for their three paragraph styles, `00 00`
for their two character styles).

IDML writes a `BasedOn` of the root `[No paragraph style]` or
`[No character style]` as a string (`$ID/[No paragraph style]`), and any
other base as an object reference.

**Attribute list (chunk 0x23F).** The style's text attributes
(`attributes.md`, text attribute lists). IDML writes on a style exactly
the text attributes this list stores. It adds no value from the base
style, and it writes a stored value also when it equals the base's.
Evidence: the 11,983 paragraph and character styles of the trustworthy
pairs that match an INDD style by kind and name. In every one, each
stored ID with a known mapping is an attribute of the IDML style, and
every IDML text attribute comes from a stored ID, except `Label` (6
styles) and `HyphenQuality` (7 styles).

Most lists are short. The root paragraph style stores the full list
(287 to 362 IDs, more in later versions). Over all pairs, no other paragraph
style stores more than 14 % of its root's list (the most is 41 of 289),
and `NormalParagraphStyle` stores at most 21. The only other styles with
a full list are 7 character styles, the same style object in 7 files of
one document family (DOM 10.0 and 10.2): each stores 120 IDs, and IDML
writes 126 or 128 attributes on them, almost all with the root values.
Nothing else in these styles differs from the short-list styles: they
have a base (the root character style), `Imported` is false, and their
chunks are the same.

**Keyboard shortcuts.** Ten bytes before the name's flag byte is a u32
key; the two bytes 6 and 5 before the flag are modifier bytes *m0* and
*m1*. Evidence: the 6,957 paragraph and character styles of all pairs
whose IDML style has the same name.

| Key | `KeyboardShortcut` | `ExtendedKeyboardShortcut` |
|---|---|---|
| 0 (5,272 styles) | `0 0` | `0 0 0` |
| 0xC000*xx*, *xx* a digit `0`–`9` | *m0* + 256 × *m1* and the code below | `0 0 0` |
| 0x8000*xx* | `0 0` | *m0* + 256 × *m1*, *xx*, then 1 |

The 103 styles with a key other than 0 are in 38 files. With key
0x8000*xx*, *xx* is a character code: over all pairs, the 21 styles of
11 trustworthy pairs with such a key and DOM 15 or later (codes 49 to 52,
66 and 73; modifiers 1, 17, 256 and 257) have this
`ExtendedKeyboardShortcut` in IDML, for example `256 49 1` for *m0* 0,
*m1* 1 and code 0x31.

The key code follows the platform of the last session of the save
history (the second u16 of its record), not the style: with platform 0
digits 0 to 7 give 82 to 89, 8 gives 91 and 9 gives 92 (every digit
occurs); with platform 3 the code is 96 + the digit. This is a rule of
the exporting edition (`preferences.md`): over the trustworthy pairs of
the corpus of 2026-10 it reproduces `KeyboardShortcut` for 3,154 of
3,154 character styles and 6,927 of 6,928 paragraph styles (a rule by
*m1* failed for 26 character and 33 paragraph styles with *m1* 0 and
platform 3). The converter writes the attribute on every style other
than the root styles. IDML has `ExtendedKeyboardShortcut` from DOM 15 on;
the converter writes it from version 15.

**Preview colour.** Fourteen bytes before the name's flag byte is a
u32: 0, or the UID of an interface colour (class 0x1F11). IDML writes it
as the style's `PreviewColor` property: `Nothing` for 0, otherwise the
colour named as for layers. Over all pairs of the corpus after 2026-10
(styles other than the root styles, matched by name): 8,457 of 8,457
paragraph styles and 3,638 of 3,638 character styles. Two character
styles of one document (two pairs) have a colour: UID 0x20, RGB 0.5 0.5
0.5, `Gray`, and UID 0x35, RGB 0.48 0.73 0.85, `GridBlue`. The root
styles have no `PreviewColor` in IDML. The converter leaves the property
to the observed values when the u32 is neither 0 nor an interface colour.

**Export settings (chunk 0x28F0).** A u32 count of export tag maps,
the maps, then u16 values to the end of the chunk:

| Field | Contents |
|---|---|
| u32 | number of tag maps *n* |
| *n* maps | export type, tag, class (three strings), u32 attribute count *k*, *k* pairs of strings |
| u16 | `SplitDocument` (1 `true`, 0 `false`) |
| u16 | `EmitCss` |
| u16 | `IncludeClass` (DOM 13 on) |
| u16 … | more values in later versions, not identified |

A string is a u32 length in UTF-16 units followed by text segments (as
the font version, `fonts.md`); an empty string is a length of 0. Export
types are `EPUB` and `PDF`; tags such as `p` or `H3` and classes may be
empty. No map in the corpus has attributes, so the layout of the pairs
is assumed and the converter writes no map that has them. The chunks
of every paragraph, character and object style of all pairs parse.

IDML has `SplitDocument` and `EmitCss` when the document was saved by
10.1 or later, and `IncludeClass` from 13.0 (header or last session of
the save history), on every paragraph and character style, the root
styles included. Without the chunk the values are `false`, `true`,
`true`. The trustworthy pairs include four whose INDD header says 10.0
and whose IDML (DOM 10.2) has the attributes, and six of 10.0 whose
IDML (DOM 10.0) has none. Over the trustworthy pairs the converter
reproduces `SplitDocument` and `EmitCss` of 7,287 of 7,287 paragraph
styles and 4,067 of 4,067 character styles, and `IncludeClass` of 5,760
and 3,500, with no extra value.

**Tag maps.** IDML writes one `StyleExportTagMap` per map after the
style's `Properties`, in stored order:
`Self="u<style UID in hex>StyleExportTagMapn<type>"`, `ExportType`, `ExportTag`, `ExportClass`, `ExportAttributes=""`,
and the style's `SplitDocument` and `EmitCss`. 306 of 306 elements in
the trustworthy pairs, every attribute equal.

**Empty nested, line and GREP styles.** Paragraph styles have
`EmptyNestedStyles`, `EmptyLineStyles` and `EmptyGrepStyles` (DOM 8.1,
and 10 on). Each is `false` when the style's list of nested styles
(attribute 0x1B75), line styles (0x1BBB) or GREP styles (0x1BBA) has
items, where the list is that of the first style in the based-on chain
that has the attribute; an empty list is stored as a count of 0. This
gives the IDML value of 5,401 of 5,403 paragraph styles for each of the
three (all pairs; the other 2 are not written).

## Style groups and object styles

**Root groups** (class 0xCA8C for paragraph and character styles, 0x1B972
object styles, 0x20241 cell styles, 0x1044F table styles) are named in
IDML by UID (`RootParagraphStyleGroup Self="u7e"`). Chunk 0x28C2 says
which kind: 0xCA0C paragraph, 0xCA0D character, 0x1B924 object, 0xB669
cell, 0xB668 table (all 75 pairs). Children: chunk 0x28DC (text styles)
or 0x1B95A (object styles), each u32, u32, UID list. A built-in root style
such as `[No character style]` need not be listed.

**Groups** (class 0xCA8B): chunk 0x28D3 is parent, root, UID list of
children; chunk 0x28D2 a flag byte and the name. IDML names every group
`$ID/<name>` (20 of 21 groups), and a style inside groups is referenced as
`ParagraphStyle/<group>:<group>:<name>` with `:` escaped as `%3a`. All 412
paragraph styles and 21 groups in the pairs match.
A group inside another group is named by its full path from the
top-level group, joined by `:`, as in its `Self`:
`Self="ParagraphStyleGroup/$ID/Page > Running Text%3aNotes"` has
`Name="$ID/Page > Running Text:Notes"`. Over all pairs: 72 of 72 nested
paragraph style groups, 25 of 25 character style groups and 2 of 2
object style groups (three levels at most); top-level groups have `$ID/`
and their name (622 of 622).
A `:` inside a group's name is written `\:`, as in a style's own name
(below): such a group has `Name="$ID/<a>\: <b>"` and
`Self="ParagraphStyleGroup/$ID/<a>\%3a <b>"`, and its styles have
`Name="<a>\: <b>:<style>"`. No pair of the corpus has such a group; this
rests on one privately held sample (1 top-level paragraph style group
with 6 paragraph styles, all matching).
Cell style groups work the same way: the root cell style group's
children (chunk 0x2024E) include groups of class 0xCA8B, and IDML writes
each as `<CellStyleGroup Self="CellStyleGroup/$ID/<group>"
Name="$ID/<group>">` holding its styles, in the order of the children (2
groups with 6 cell styles in 1 trustworthy DOM 18 pair). No table style
group occurs in the pairs; the converter writes them the same way.

**Style names.** Over the styles of the 489 trustworthy pairs, a style's
IDML `Name` is its group path and its own name joined by `:` (1,170
paragraph, 759 character, 8 object and 6 cell styles in groups, such as
`Name="Listes:Liste non numérotée"`), and its `Self` is the tag and that
name with `%` written `%25`, `:` written `%3a` and CR written `%0d`. Two
more rules:

- A `:` inside a style's own name is written `\:` in `Name`, so `\%3a`
  in `Self`: `Name="ss01\: People"`, `Self="CharacterStyle/ss01\%3a
  People"` (12 paragraph, 6 character and 3 object styles).
- A built-in style inside a group has `$ID/` before the whole path:
  `ParagraphStyle/$ID/INDEX%3aIndex Section Head` with
  `Name="$ID/INDEX:Index Section Head"` (one paragraph and one character
  style).

The same holds for object styles and cell styles in groups
(`ObjectStyle/Worksheet%3aworksheet`, `CellStyle/Standard
Table%3aHeader Row`). Elsewhere `%3a` stays plain: languages are
`Language/$ID/English%3a USA`.

**Object styles** (class 0x1B901): chunk 0x1B907 is u32 based-on style,
u8 1 for a built-in name, then the name. A page item's chunk 0x1B916 is
its applied object style (`AppliedObjectStyle`, 671/671 rectangles). A
style based on the root `[None]` has its `BasedOn` written as a string.

## Object style settings

Object styles (class 0x1B901) hold their settings in these chunks.
Evidence: the 337 object styles of the same-version pairs whose name
matches an IDML `ObjectStyle` (259 of them other than `[None]`); all
counts are matches of 337 unless stated.

| Chunk | Contents | IDML |
|---|---|---|
| 0x1B92B | Attribute list, u16 count, page item records (`attributes.md`) | `FillColor`, `StrokeColor`, `StrokeWeight`, `StrokeType`, `CornerOption`, `CornerRadius`, `GradientFillAngle` (0x551E), `GradientStrokeAngle` (0x5524) |
| 0x1B956 | Attribute list, frame fitting (see frame fitting) | `FrameFittingOption` |
| 0x1B924 | Text frame settings (below) | `TextFramePreference`, `TextFrameFootnoteOptionsObject` |
| 0x285B | u16 story orientation at 0, f64 at 2, u16 at 12, u16 frame type at 14 | `StoryPreference` (`OpticalMarginSize` from the f64, `OpticalMarginAlignment` from the u16 at 12: 0 `false`, 1 `true`) |
| 0x50F28 | u16 story direction | `StoryPreference/StoryDirection` |
| 0x3776, 0x3777 | Text wrap, as chunks 0x3703 and 0x373D of page items | `TextWrapPreference` |
| 0x1B92E | u32 count, IDs of the categories the style turns on | `Enable…` attributes (below) |
| 0x1B946 | u32 paragraph style, 0 = none | `AppliedParagraphStyle` (`n` for none, and for a style without the chunk: 5,556 of 5,556 values of the trustworthy pairs of the corpus after 2026-10, 173 of them without the chunk) |
| 0x1E244 | 78 bytes: six f64 at 30 | `FlexLayoutAttributeOption` `FlexPaddingTop`, `FlexPaddingRight`, `FlexPaddingBottom`, `FlexPaddingLeft`, `FlexGapRow`, `FlexGapColumn`; without the chunk 12, 12, 12, 12, 20, 20 (below) |
| 0xCD32 | u16 0 for none, or u16 1 and the UID of a named grid | `AppliedNamedGrid` (named grids, above) |
| 0x1B94D | u16, 1 = true | `ApplyNextParagraphStyle` (below) |
| 0x2800 | Anchored object settings, as in the preferences | `AnchoredObjectSetting` (below) |
| 0x1B907 | u32 based-on style, flag byte and name, u32 shortcut key | `BasedOn`, `Name`, `KeyboardShortcut` (below) |
| 0x1E234 | 52 bytes: u16 flags at 8, 10, 12 and 14, f64 at 16, 24, 32 and 40 | `TransformAttributeOption`: `TransformAttrX`, `TransformAttrY`, `TransformAttrHeight` and `TransformAttrWidth`, each written when its flag is 1 (below) |

**Flex layout spacing.** In chunk 0x1E244 the six f64 at 30 are the
four paddings and the two gaps. A style without the chunk (`[None]`
included) has 12 for each padding and 20 for each gap. With this the
converter reproduces all 226 values of each of the six attributes in the
trustworthy pairs (none was written before). The four paddings are
equal in every sample, as are the two gaps, so the order inside each
group follows the IDML attribute order and is not proven.

**Settings found in the corpus after 2026-10.** Object styles other
than `[None]`, matched by `Self` with their IDML style over the 1,251
trustworthy pairs (4,305 styles; with `[None]`, 5,556):

| Field | IDML | Matches |
|---|---|---|
| 0x1B94D u16: 0 `false`, 1 `true`; no chunk `false` | `ApplyNextParagraphStyle` | 3,963 with 0, 3 with 1, 339 without the chunk; `[None]` has no attribute |
| 0x1B907, u32 after the name: 0 | `KeyboardShortcut="0 0"` | every style with 0 (other keys are followed by two modifier bytes as for paragraph styles, but their codes differ from those of paragraph styles; the converter leaves them out) |
| 0x3776 (44 bytes) u16 at 40: 1 `false`, 0 `true`; no chunk `false` | `TextWrapPreference` `ApplyToMasterPageOnly` | 3,914, 84 and 1,558 of 5,556 |
| 0x1B924 u16 at 140, 1 = true (142 bytes or more) | `TextFramePreference` `UseNoLineBreaksForAutoSizing` | 5,518 of 5,518 (24 true) |
| 0x2800 f64 at 16 | `AnchoredObjectSetting` `AnchorXoffset` | 5,551 of 5,551 (28 not 0); 5 styles have no chunk |
| 0x2800 u16 at 42: 1 `TextFrame`, 4 `AnchorLocation` | `AnchoredObjectSetting` `HorizontalReferencePoint` | 5,547 and 4 |

The converter reads the anchor fields wherever it reads chunk 0x2800:
object styles, anchored frames and the preferences.

**Attribute list.** The IDs of page items carry over. `CornerOption` 0
is `None` and 0x5A16 `InverseRoundedCorner` (1 style). The two gradient
angles are told apart by one style with −90 and 0. Each corner radius
and corner option has its own ID, as in page items (`attributes.md`,
corners), and the converter writes each corner from its ID.

**Overprint.** The attribute list holds the overprint flags of the
fill (0x6E6A), the stroke (0x6E67) and the gap (0x6E8B), u16 1 `true`,
0 `false`. IDML writes `OverprintFill` only when the fill colour (0x6E68)
puts ink on the page: it is not the swatch `None` or `Paper`, its tint
(0x6E69) is not 0, and it is not a white process colour (CMYK 0 0 0 0,
or RGB 255 255 255). The same holds for `OverprintStroke` with 0x6E64
and 0x6E66, and `OverprintGap` with 0x6E89 and 0x6E8A. The root `[None]`
has none of the three. Documents saved by 21.4 or later (12 trustworthy
pairs of 21.4 and 21.5) have all three on every object style, the root
included, whatever the colours. Over the trustworthy pairs the converter
reproduces 235 of 235 `OverprintFill`, 1,512 of 1,512 `OverprintStroke`
and 49 of 49 `OverprintGap` values with no extra value. The white RGB
case rests on 2 styles of two pairs of one 13.1 document (89 other RGB
fills and strokes are written). Every object style flag in the corpus
is 0. Page items use the same IDs (page item settings, overprint).

**Export settings (chunk 0x28F0).** Object styles have the chunk of
paragraph and character styles (styles, export settings). IDML writes
`EmitCss` (the second u16) for documents saved by 10.1 and
`IncludeClass` (the third) for documents saved by 13.0, the root
`[None]` included; there is no `SplitDocument`. Without the chunk both
are `true`. Trustworthy pairs: `EmitCss` 5,031 of 5,031,
`IncludeClass` 4,019 of 4,019 (every value is `true`). One 12.1
document has an object style tag map (`ObjectStyleExportTagMap`); it is
not written.

**ARIA label.** From DOM 21.2 every `ObjectStyle`, `[None]` included,
has `EpubAriaLabel=""` and `EpubAriaLabelSourceType="NoneARIALabel"`,
after `EpubAriaRole`: 178 of 178 styles in the 44 corpus IDML files of
DOM 21.2 to 21.5. The 60 styles of the 15 files of DOM 21.1 have
neither, nor does any style of an earlier DOM. No value varies, so no
INDD field is identified; the converter writes both on every object
style from DOM 21.2. They are attributes of the style. Its
`ObjectExportOption` has `EpubAriaLabel="$ID/"` and
`EpubAriaLabelSourceType="AutomaticARIALabel"` from DOM 21.1, as page
items do (`idml-values.md`, export options of page items).

**Optical margin (chunk 0x285B).** The f64 at 2 is `OpticalMarginSize`
and the u16 at 12 `OpticalMarginAlignment` (1 = true), as in the story
chunk 0x2EE (stories). Over all pairs of the corpus of 2026-10, both
match in 3,515 of 3,515 object styles (2,661 of 2,661 in the trustworthy
pairs). The IDML sizes are 12 (3,172 styles), 9.2126 (336), 8 (4) and
9.9213 (3); 4 styles have `OpticalMarginAlignment="true"`. The u16 at 10
is not identified.

**Text frame settings (chunk 0x1B924).** 222 bytes; 162, 142 or 106 in
files from older versions (942, 48, 66 and 61 object styles in the
little-endian corpus). The converter reads it only with these sizes.
The InDesign 4.0 file has 104 bytes, with another layout; the converter
leaves it out with a warning (`big-endian.md`). In the corpus after
2026-10, 1,129 object styles in 263 files of InDesign 4.0 to 6.0 have 104
bytes; none of these files has an IDML, so the layout cannot be checked.

| Offset | Contents | Attribute |
|---|---|---|
| 0 | f64 | `TextColumnFixedWidth` |
| 8 | f64 | `TextColumnGutter` |
| 32 | u16, 1 = true | `VerticalBalanceColumns` |
| 34, 42, 50, 58 | four f64, inset spacing | `InsetSpacing` (below) |
| 66 | u32 | `TextColumnCount` |
| 70 | u16, 1 = true | `UseFixedColumnWidth` |
| 74 | u16, codes as for frames | `VerticalJustification` |
| 76 | u16, codes as for frames, and 4 `XHeight` | `FirstBaselineOffset` |
| 116 | u16, codes as for frames | `AutoSizingType` |
| 118 | u16, codes as for frames | `AutoSizingReferencePoint` |
| 120, 122 | u16 1 = true, f64 | `UseMinimumHeightForAutoSizing`, `MinimumHeightForAutoSizing` |
| 130, 132 | u16 1 = true, f64 | `UseMinimumWidthForAutoSizing`, `MinimumWidthForAutoSizing` |
| 144 | u16, 1 = true | `FootnotesSpanAcrossColumns`, `SpanFootnotesAcross` |
| 146 | f64 | `FootnotesMinimumSpacing`, `MinimumSpacingOption` |
| 154 | f64 | `FootnotesSpaceBetween`, `SpaceBetweenFootnotes` |
| 190 | f64 | `ColumnRuleStrokeWidth` |
| 198 | u32 swatch, 0 = `n` | `ColumnRuleStrokeColor` |
| 210 | f64 | `ColumnRuleStrokeTint` |

The fields from offset 32 to 132 were found by testing every offset
against the IDML style, over the 2,155 object styles of the trustworthy
pairs that match an IDML style by name (1,000 with 222 bytes, 607 with
142 and 520 with 162). Each is the only offset that matches all styles
of the 222- and 142-byte layouts:

| Offset | Values seen (222 / 142 bytes) |
|---|---|
| 32 | 1 true in each layout, all match |
| 70 | 142: 1 true; 222: all false |
| 74 | 222: 4 `CenterAlign`; 142: 3 `CenterAlign`, 2 `BottomAlign` |
| 76 | 222: 952 `AscentOffset`, 42 `EmboxHeight`, 6 `XHeight`; 142: 584, 1 and 22; 162: 516 `AscentOffset`, 4 `EmboxHeight` |
| 116 | 3 distinct values in each layout |
| 118 | 142: 5 distinct values |
| 120, 122 | 142: 6 true, 6 distinct heights |
| 130, 132 | 142: 2 true, 3 distinct widths |

In the 162-byte layout the justification and auto-sizing fields have one
value in every style, and in the 106-byte layout (28 styles) every field
but offset 76 does; the converter assumes the offsets of the larger
layouts for 162 bytes and reads only offset 76 from 106 bytes.
`IgnoreWrap`, `MinimumFirstBaselineOffset`, `VerticalThreshold`,
`UseFlexibleColumnWidth`, `TextColumnMaxWidth` and
`UseNoLineBreaksForAutoSizing` have one value in every style (false or
0), so no field can be shown for them; the converter writes the observed
value (`idml-values.md`). Code 4 of `FirstBaselineOffset` is shown only
in styles; the converter reads it in frames too.

Footnote and column rule values: 305 of 305 styles whose chunk has them.
The column rule colour maps one to one over 41 (file, UID) pairs. Only
one style (3 copies) has unequal insets, and it shows only the top inset
(offset 50), so the converter writes `InsetSpacing` only when all four
are equal (334 of 337).

**Story settings.** Frame type: 0 `Unknown`, 1 `TextFrameType`, 2
`FrameGridType`. Orientation: 0 `Unknown`, 1 `Horizontal`. Direction: 1
`LeftToRightDirection`, 0 or no chunk `UnknownDirection`. 337 of 337
each. The f64 at 2 is 12 in every style, like `OpticalMarginSize`, and is
not used.

**Text wrap.** 234 styles have chunk 0x3776 with mode 0, offsets 0 and
the u32 at 40 = 1, and chunk 0x3777 type 5: IDML `None` with
`ContourType="SameAsClipping"`. 103 styles have neither chunk and IDML
`None`. Chunk 0x3777 is the contour with the layout of chunk 0x373D
(text wrap, contour). In the trustworthy pairs of the corpus of 2026-10,
3,965 object styles have it: 3,964 with type 5 and one with type 0, whose
IDML style is the only one with `ContourType="BoundingBox"`. Every other
IDML object style, with or without the chunk, has `SameAsClipping`
(5,555 of 5,556 styles), so a style without the chunk takes type 5.
`ContourPathName` is `$ID/` in every `ContourOption` of the object
styles of the corpus pairs (7,423 of 7,423, DOM 7 to 21).

**Categories (chunk 0x1B92E).** An ID in the list means the attribute is
`true`. Over the 1,684 object styles other than `[None]` of the
trustworthy pairs whose name matches an IDML style (fewer for attributes
that IDML has only from a later version), each attribute below equals
the presence of its ID in every style:

| ID | Attribute | From DOM |
|---|---|---|
| 0x1B933 | `EnableFill` | 7 |
| 0x1B934 | `EnableStroke` | 7 |
| 0x1B935, 0x1B936 | `EnableStrokeAndCornerOptions` | 7 |
| 0x1B93E | `EnableTextFrameGeneralOptions` | 7 |
| 0xADC8 | `EnableTextFrameBaselineOptions` | 7 |
| 0xADC9 | `EnableTextFrameAutoSizingOptions` | 8 |
| 0x1B940 | `EnableStoryOptions` | 7 |
| 0x1B960 | `EnableFrameFittingOptions` | 7 |
| 0x1B93F | `EnableParagraphStyle` | 7 |
| 0xADCB | `EnableTextFrameColumnRuleOptions` | 15.1 |
| 0xCA2F | `EnableAnchoredObjectOptions` | 7 |
| 0x1B942, 0x37C8, 0x37C9 | `EnableTextWrapAndOthers` | 7 |
| 0xADCA | `EnableTextFrameFootnoteOptions` | 12 |
| 0x6EA1 to 0x6EA7 | `EnableTransformAttributes` | 13 |
| 0x1B97A, 0x1B97C to 0x1B97E | `EnableExportTagging`, `EnableObjectExportAltTextOptions`, `EnableObjectExportEpubOptions`, `EnableObjectExportTaggedPdfOptions` | 9 |
| 0x1B937 | `EnableTransparency` of `ObjectStyleObjectEffectsCategorySettings` | 7 |
| 0x1B948, 0x1B950, 0x1B958 | `EnableTransparency` of the fill, stroke and content effects categories | 7 |

Where a row has several IDs, they are all present or all absent in every
style, so the corpus does not tell which one the attribute follows; the
converter writes the attribute only when they agree.

The transparency categories do not change which transparency values
IDML writes on a style (`transparency.md`, object styles).

Versions are those of the INDD header, major and minor. Over the 489
trustworthy pairs: `EnableTextFrameColumnRuleOptions` is on no style in
the 42 documents of 15.0 (four builds), and on every style in the 7 of
15.1 and on all later ones. The footnote values of the text frame
settings (`FootnotesSpanAcrossColumns`, `FootnotesMinimumSpacing`,
`FootnotesSpaceBetween` of `TextFramePreference`) are on no style of
DOM 12 (127 styles) or 13.0 (12 styles), and on every style from 13.1.

**The root style `[None]`** has none of the `Enable…` attributes and none
of the four `ObjectStyle…EffectsCategorySettings` elements in 489 of 489
trustworthy references, though its INDD object has the category list.
The converter still reads the list: the text frames that use `[None]`
depend on it (text frame preferences). The four export
attributes are equal in every style (84 true, 1,358 false). With the 88
pairs of the earlier corpus, fill and stroke, and the general and
baseline frame options, were not told apart; the larger corpus has
styles that differ in them (10 without fill, 13 without stroke, 506
without general options and 531 without baseline options).

**Anchored object settings** are in chunk 0x2800, as for anchors (see
stories). A style without the chunk (6 styles of versions 10.1 and 10.2)
has the values of preferences without it (`preferences.md`, anchored
objects).
The other values of object styles come from IDML observation
(`idml-values.md`).

**Transform attributes (chunk 0x1E234).** Over the 1,251 trustworthy
pairs after 2026-10, 2,426 object styles have the chunk, 52 bytes each.
The u16 at 8, 10, 12 and 14 are 1 exactly where IDML writes
`TransformAttrX`, `TransformAttrY`, `TransformAttrHeight` and
`TransformAttrWidth`, and the f64 at 16, 24, 32 and 40 are their
values: 3 of 3 X, 1 of 1 Y, 11 of 11 height and 30 of 30 width values
(36 styles; 2,390 styles have all four flags 0 and no such attribute,
though many store values other than 0). Bytes 0–7 and 48–51 are 0 in
every chunk. IDML has the element from DOM 13 (`idml-values.md`); the
converter writes the values the style sets into it.

## Master spread names and sections

Master spread chunk 0x1402: a flag byte and the name prefix (`A`), a flag
byte and the base name (`Master`). IDML `Name` is `<prefix>-<base>`, and
the master's pages are named by the prefix (99/99 match).

**Sections (class 0x4C01).** The document's chunk 0x4C01 lists them.
Section chunk 0x4C02:

| Field | Contents |
|---|---|
| u8, string | `SectionPrefix` |
| u8, string | `Marker` |
| u32 | First page of the section; 0 for the section that starts at the document's first page |
| u32 | Page number start (`PageNumberStart`) |
| u32 | Page number style: 0x4C15 = `Arabic`, 0x4C17 = `LowerRoman`, 0x4C12 = `Kanji`, 0x4C13 = `DoubleLeadingZeros`, 0x4C16 = `UpperRoman`, 0x4C19 = `LowerLetters`, 0x4C1A = `SingleLeadingZeros` (below) |
| u32 | Continue numbering (1 = true, `ContinueNumbering`) |
| u16 | 0 in every chunk |
| u16 | Include section prefix (1 = true, `IncludeSectionPrefix`) |
| u8 flag, string | `AlternateLayout`: the string, with `$ID/` before it if the flag is 1 |

In the 546 sections of the trustworthy pairs, 539 chunks have all these
fields; the prefix, marker and alternate layout equal the IDML values in
539 of 539 (417 named layouts such as `Letter V`, 82 empty, 40 `$ID/`).
The 7 shorter chunks are in DOM 7 and 8 files and end after the second
u32 above.

**Include section prefix.** Over the 1,345 sections of the 1,252
trustworthy pairs after 2026-10, 1,336 chunks have the u16 pair after
continue numbering. The first u16 is 0 in all of them. The second is 1
in all 11 sections with IDML `IncludeSectionPrefix="true"` (10 distinct
files) and 0 in all 1,325 with `false`. The other 9 chunks, one each in
9 DOM 7 files, end before the field; IDML gives them `false`.

**Section name.** IDML `Name` equals `SectionPrefix` in all 1,345
sections: 15 sections in 14 distinct files have a prefix, and 1,330
have an empty prefix and an empty name. The prefix does not depend on
`IncludeSectionPrefix` (9 of the 15 include it, 6 do not).

**Alternate layouts.** A section with a layout name (not empty and not
`$ID/`) starts an alternate layout, and so does the first section.
`AlternateLayoutLength` of a section is the number of pages from its
first page to the start of the next layout, or to the end of the
document (538 of 539). The `AppliedAlternateLayout` of a document page
is the section that starts its layout; master pages have `n`. Both are
in IDML from DOM 8 on. Over the trustworthy pairs the converted
`AppliedAlternateLayout` equals the IDML value for 9,347 of 9,347 pages.

**Page descriptor.** A document page has a `Descriptor` property, a list
of the section prefix, the page number style, `ContinueNumbering`,
`IncludeSectionPrefix`, the page number and the marker; from DOM 20 on
the page number is in the list twice. Over the trustworthy pairs: 7,800
of 7,924 pages; 64 others are in sections with a style the converter
does not know (IDML gives it as an empty string), and the converter
leaves their descriptor out.

In the descriptor, a return (U+000D) in the marker is a paragraph
separator (U+2029); the section's `Marker` attribute keeps the return.
Over the 15,855 pages of the trustworthy pairs after 2026-10, 568 pages
(6 distinct files) are in sections whose marker ends with a return, and
their descriptors end with U+2029 in its place (568 of 568). No marker
has a return elsewhere. 1,080 pages have a marker without a return,
which the descriptor repeats as it is, and 14,207 have an empty marker.

Evidence:

- In every corpus pair the first section's IDML `PageStart` is the
  document's first page, and its first-page field is 0. All but one pair
  have one section; one has four. All 79 sections that the converter
  writes match on `PageStart`, `Length`, `ContinueNumbering` and, where
  IDML writes it, `PageNumberStart`. IDML writes `PageNumberStart` only for sections with
  `ContinueNumbering="false"` (14 of 14); a continuing section can store a
  start number that IDML leaves out.
- 84 distinct INDD files without an IDML have more than one section (254
  sections). The first section listed has first page 0 in all 84. Each of
  the other 170 names a page of the document (170 of 170). The list is not
  always in page order, so the converter sorts sections by their first
  page. A section ends where the next one starts; that gives IDML
  `Length`.
- The style is 0x4C15 in all 423 sections of the 250 distinct
  little-endian files, and those in the pairs are `Arabic`. The
  InDesign 3.0 file stores 0x4C06 (`big-endian.md`).
- Style 0x4C17 is lower-case Roman. No pair has it. The evidence is a
  sample and its print PDF. The PDF's page labels (`/PageLabels` in the
  document catalog) give the pages of the sample's 0x4C17 sections style
  `/r`, lower-case Roman, and the pages of its 0x4C15 section style
  `/D`, decimal.
- Style 0x4C12 has no pair either. The evidence is a sample typeset
  vertically and its print PDF. The folios on the pages of its 0x4C12
  section are Chinese numerals written digit by digit (〇 一 二 … 九,
  so 10 is 一〇 and 100 is 一〇〇), counting from the section's start
  number. The PDF's page labels belong to a larger document and do not
  show the style. `Kanji` is the only value of the schema's
  `PageNumberStyle` enumeration that uses such numerals.

Pairs of the corpus after 2026-10 show four more codes. Over every
valid distinct file, each section whose code the converter did not know
was matched with the IDML `Section` of the same UID:

| Code | IDML `PageNumberStyle` | Sections with an IDML section | Sections without |
|---|---|---|---|
| 0x4C1A | `SingleLeadingZeros` | 51 | 30 |
| 0x4C13 | `DoubleLeadingZeros` | 21 | 3 |
| 0x4C19 | `LowerLetters` | 14 | 2 |
| 0x4C16 | `UpperRoman` | 3 | 10 |

No section has another value for these codes. In the `Descriptor` of a
page, whose second item is the section's style, IDML writes a page of a
`SingleLeadingZeros` section with a string there, the section prefix
again: 1,249 descriptors in the IDML files of the corpus (1,223 with an
empty prefix), none with the enumeration value. 0x4C18 (one section) and
0x4C06 (InDesign 2.0 and 3.0 files) occur only in files without IDML.
The converter writes `PageNumberStyle` for the seven codes and leaves it
out (with a warning) for other codes.

The converter names document pages by their number in their section,
counting on from the previous section when numbering continues. The
section at the document's first page starts at its page number start
even when it continues numbering: the document continues the numbering
of a book. Over the 1,252 trustworthy pairs after 2026-10, the IDML
page number of the first page equals that field in 1,252 of 1,252,
including 18 documents (18 distinct files) whose first section
continues numbering from a start above 1. The 49 later sections that
continue numbering count on from the previous section (49 of 49), though
41 store another start. In a section with `IncludeSectionPrefix`, the
page name is the section prefix followed by the number: `2-1`, `2-2`
for prefix `2-`, and `1장_01` for a prefix `1장_` and style 0x4C1A.
After these rules, page names and descriptors equal the IDML values on
15,855 of 15,855 pages of those pairs. In a
section with style 0x4C17 it writes the number in lower-case Roman (i,
ii, iii), as in the PDF labels above, and in a section with style 0x4C12
in Chinese digits, as the folios show. No pair shows IDML page names in
such sections. It writes upper-case Roman numerals for 0x4C16, two and
three digits with leading zeros for 0x4C1A and 0x4C13, and the letters a
to z for 0x4C19 (later numbers as Arabic numbers); the page names of the
pairs above measure these.

## Document preferences (class 0x2202)

One object of class 0x2202 holds document-wide preferences. Chunk 0x533
(`DocumentPreference`): f64 page width at 0, f64 page height at 8, byte 58
2 for facing pages and 1 otherwise, four f64 bleeds from offset 70 (inside,
top, outside, bottom; `preferences.md`), u32 intent at 142 (0 print, 1
web, 2 mobile). All values match the 75 pairs. Files from InDesign 7.0
and 7.5 have a 126-byte chunk with the fields at other offsets
(`preferences.md`, document setup). Files from InDesign 3.0 and 4.0 have
a 118-byte chunk with another layout; the converter leaves it out with a
warning (`big-endian.md`).

**Page binding (u16 at 64).** 0 is `PageBinding="LeftToRight"`, 1
`RightToLeft`. Evidence:

- The u16 is 0 in all 247 distinct little-endian public files that have
  the 146-byte chunk. All 88 distinct corpus IDML files have
  `PageBinding="LeftToRight"`, and in all 73 two-page spreads and master
  spreads of those files the first page lies left of the second.
- A sample typeset vertically, whose print PDF shows columns ordered
  right to left, stores 1. In each of its two-page spreads and master
  spreads the first page lies right of the second: the book is bound on
  the right. The schema's other value, `Default`, has no sample.

The converter writes `PageBinding` from this field and leaves it out,
with a warning, for other codes. Pages are written in the order the
spread lists them, for both bindings.

## Text frame preferences

From the frame's multi-column frame object (class 0x263):

| Chunk | Offset | `TextFramePreference` attribute |
|---|---|---|
| 0x2D1 | u32 0 | `TextColumnCount` (1,052/1,052) |
| 0x2D1 | f64 4 | `TextColumnGutter` (93/93) |
| 0x2D1 | f64 14 | `TextColumnFixedWidth` (1,045/1,045) |
| 0x2CE | u16 0 | `FirstBaselineOffset`: 0 LeadingOffset, 1 AscentOffset, 2 CapHeight, 3 EmboxHeight, 4 XHeight (below) |
| 0x2CE | u16 2 | `VerticalJustification`: 0 Top, 1 Center, 2 Bottom, 3 Justify (350/350) |
| 0x2CE | u16 20 | `VerticalBalanceColumns` (18/18) |
| 0x2CE | u16 22 | `AutoSizingType`: 0 Off, 1 HeightOnly, 2 WidthOnly, 3 HeightAndWidth (61/61) |
| 0x2CE | u16 24 | `AutoSizingReferencePoint`: 0–8, top-left to bottom-right by rows (58/58) |
| 0x2CE | u16 26, f64 28 | `UseMinimumHeightForAutoSizing`, `MinimumHeightForAutoSizing` |
| 0x2CE | u16 36, f64 38 | `UseMinimumWidthForAutoSizing`, `MinimumWidthForAutoSizing` |
| 0x2CE | u16 46 | `UseNoLineBreaksForAutoSizing` |
| 0x2D1 | u8 12 | `UseFixedColumnWidth` |
| 0x2D1 | f64 32 | `TextColumnMaxWidth` (in 40-byte chunks) |
| 0x3730 | u16 | `IgnoreWrap` |
| 0x22646 | u32 0 | `ColumnRuleOverride`: 1 true, 0 false (below) |
| 0x22646 | f64 28, u32 36 | `ColumnRuleStrokeWidth`, `ColumnRuleStrokeColor` (a swatch; 0 = `n`) |
| 0x22608 | u16 2, f64 4, f64 12 | `FootnotesSpanAcrossColumns` (1 = true), `FootnotesMinimumSpacing`, `FootnotesSpaceBetween` |
| 0x2834 | 24 bytes | `BaselineFrameGridOption` (below) |

**Span of footnotes.** The u16 at 2 of chunk 0x22608 is
`FootnotesSpanAcrossColumns`. Before 2026-10, 2,655 frames with 0 have
`false` in IDML; the 22 frames with 1 (8 documents) all have an object
style with span `true` and the footnote category on, and IDML leaves the
attribute out, as for any value equal to the style's. Writing it from
the chunk removes the 82 extra `FootnotesSpanAcrossColumns` values of
the trustworthy pairs after 2026-10 and adds no wrong value.

**Frames without chunk 0x2CE, and the 22-byte chunk.** Frames of
InDesign 14.0 and 15.0 can lack chunk 0x2CE (517 frames in 24 documents
before 2026-10). Their IDML has `FirstBaselineOffset="LeadingOffset"`
on all 517, although their styles have `AscentOffset`; where IDML writes
the other values they are `TopAlign`, `false`, `Off`, `CenterPoint`,
minimums off and 0, and no line breaks off. These are codes 0, reference
point 4 and no minimums. InDesign 7.0 frames can have a 22-byte chunk
0x2CE (125 frames, 4 documents): offsets 0, 2 and 20 are as in the
longer chunk (11 of 11, 11 of 11 and 13 of 13 values); it has no
auto-sizing fields, and DOM 7 IDML has no auto-sizing attributes. The
converter writes these frames' `TextFramePreference` with those values:
over the trustworthy pairs after 2026-10, 670 more elements, with no
wrong or extra value (`FirstBaselineOffset` 2,731 of 2,731,
`AutoSizingType` 16,202 of 16,202).

The frame itself (class 0x6201) holds the inset spacing in chunk 0x3723
(44 bytes): f64, u32, then four f64 (left, top, right, bottom). IDML
writes `InsetSpacing` as a list of top, left, bottom and right, or as
the f64 at offset 0 (below). A frame without the chunk has 0 for all
five.

Evidence over the text frames of the trustworthy pairs that the
converter writes (`TextFramePreference` values reproduced): the
auto-sizing minimums and their flags 4,069 to 4,071 of 4,069 to 4,071
each (5 frames with 108 pt minimums, 4 without line breaks),
`UseFixedColumnWidth` 747 of 747 (9 true), `TextColumnMaxWidth` 23,043
of 23,043 (one frame with 210.24; the 30-byte chunks of DOM 7 files have
no such field and their IDML no such attribute), `IgnoreWrap` 643 of the
817 frames that have it (74 true; frames without the chunk have `false`,
which the converter writes: 1,871 of 1,871 values in the corpus after
2026-10), column rule width and colour
7,277 and 7,323 of 7,277 and 7,323, footnote spacings 4,351 of 4,351
each. Without chunk 0x22646 the IDML has width 1 and `Color/Black`
(2,816 frames); without chunk 0x22608, 12 and 6 (1,430 frames). The
column rule and footnote settings are written from the versions in
which IDML has them (`idml-values.md`).

`InsetSpacing`: IDML writes it as a list where the frame is a plain
rectangle and as one number (`<InsetSpacing type="unit">15</InsetSpacing>`)
where it is not. A plain rectangle is a frame whose path (as written in
`PathGeometry`) is one path of exactly four straight points (both
direction points on the anchor), each sharing its x or y coordinate with
the next (compared to 1e-4 pt), so that they are the corners of a
rectangle along the axes of the frame's inner coordinates, and whose
corner options in effect (its own `TopLeftCornerOption` to
`BottomRightCornerOption`, else its object style's along `BasedOn`) are
all `None`. Chunk 0x3723 holds no shape flag: its u32 at offset 8 is a
UID (the frame's UID plus a few in most frames). Evidence over the text
frames of the trustworthy pairs (except `own/`), in spreads, master
spreads and stories (anchored frames):

| Frame | List | One number | None |
|---|---|---|---|
| Plain rectangle | 40,603 | 0 | 6,551 (DOM 7 to 10) |
| Four-point rectangle with a corner option in effect | 0 | 584 | 0 |
| Curved path | 0 | 771 | 0 |
| Straight path of 2 or 3 points | 0 | 29 | 0 |
| Straight path of 4 points, not along the axes | 0 | 131 | 0 |
| Straight path of 5 to 7 points | 4 | 77 | 0 |
| Straight path of 9 to 32 points | 0 | 124 | 0 |

The tolerance matters: 4 plain rectangles have corners whose coordinates
differ in the last digit (-2395.597908385931 and -2395.597908385932),
and IDML writes them as lists. A path with more than four points is not
a plain rectangle even when its extra points add no corner: 32 of the 77
frames with 5 to 7 straight points reduce to a rectangle once repeated
points and points on a side are removed (a closed path that repeats its
first point at the end, open paths that repeat the first point, a
7-point path with 3 extra points on one side, a 6-point path with an
extra point on the bottom side), and all 77 are one number (29 with 5
points, 34 with 6, 14 with 7). The 4 lists among them are exceptions,
all with 5 points: 3 copies of one frame in one document, and one frame
whose closing point differs from its first by 3.5e-15.

The one number is the f64 at offset 0 of chunk 0x3723, whatever the
four insets are, equal or not. In one DOM 15 document, 101 anchored
star-shaped frames (10 points) have 0 at offset 0 and four insets of 9,
and two curved frames (44 and 28 points) have 0 at offset 0 and insets
of 36, 0, 25.2 and 0; IDML writes `0` for all 103. In every other
one-number frame of the trustworthy pairs the f64 at offset 0 equals
the four insets.

From DOM 11 every frame has `InsetSpacing`. Before DOM 11 a frame
that is not a plain rectangle always has it: all 200 such frames of the
trustworthy pairs of DOM 7 to 10 (one number: 0, 4, 4.94, 5 or 15). For
a plain rectangle it follows the rule of the general category below
(857 frames with it, 6,551 without): IDML writes it where
the frame's insets differ from its object style's (chunk 0x1B924 at 34,
compared as a set of four values, since the order of the style's
fields is not shown) or the style turns the category off. Over the
trustworthy pairs of the corpus after 2026-10 the converter reproduces
42,337 of 42,341 `InsetSpacing` values; the 4 that differ are the list exceptions above.

`MinimumFirstBaselineOffset` is 0 on every frame and object style of the
corpus IDML files, so its field cannot be found. IDML writes it on a
frame exactly where the baseline category rule below writes the
baseline attributes; the converter writes `0` under that rule: 1,753 of
1,753 values, none extra.

**Values written on frames.** IDML writes an attribute of a frame's
`TextFramePreference` when its category is off in the frame's object
style (the category ID is not in the style's list, chunk 0x1B92E, also
for `[None]`), or when the frame's value differs from the style's
value. The style's values are its own, or, if it has no text frame
settings, those of the style it is based on, then `[None]`'s.

| Category | ID | Attributes |
|---|---|---|
| General | 0x1B93E | `TextColumnCount`, `TextColumnGutter`, `TextColumnFixedWidth`, `UseFixedColumnWidth`, `UseFlexibleColumnWidth`, `TextColumnMaxWidth`, `VerticalJustification`, `VerticalThreshold`, `IgnoreWrap`, `VerticalBalanceColumns`, `InsetSpacing` |
| Baseline | 0xADC8 | `FirstBaselineOffset`, `MinimumFirstBaselineOffset` |
| Auto-sizing | 0xADC9 | the seven auto-sizing attributes |
| Footnotes | 0xADCA | the four `Footnotes…` attributes |
| Column rules | 0xADCB | the ten `ColumnRule…` attributes |

Evidence over the 489 trustworthy pairs. Frames with style `[None]`
write a whole category in a document if and only if `[None]`'s list
lacks the ID (counting documents with such frames):

| Category | ID missing | ID present |
|---|---|---|
| Auto-sizing (DOM 8 on) | written in 28 of 28 documents | written in 0 of 224 (one more has frames whose values differ) |
| Footnotes (13.1 on) | 21 of 21 | 0 of 153 |
| Column rules (DOM 15 on) | 35 of 35 | 0 of 64 |
| General, baseline | (ID present in all 254) | 0 of 254 |

Exceptions: `TextColumnMaxWidth` is on every frame from DOM 8 (22,775 of
22,775), `TextColumnCount` on every frame from DOM 10 (18,679 of 18,680;
before, it follows the rule: absent in 4,006 frames where it equals the
style), and `InsetSpacing` on every frame from DOM 11. The footnote
values are on no frame before 13.1: none of the 3 documents of 13.0 has
them, though one has frames whose style has the category off.

Applied to the converter's frame values and the reference styles'
values, the rule leaves out 379,953 values that the IDML does not have,
keeps the 200,434 it has, and leaves out one value that the IDML has (a
`TextColumnFixedWidth` equal to its style's).

`ColumnRuleOverride`: the u32 at offset 0 of chunk 0x22646 (60 bytes).
In the conversions of the 1,251 trustworthy pairs after 2026-10, 11,319
frames have the chunk: 2 frames (a 15.0 and an 18.4 document) have 1,
and IDML has `ColumnRuleOverride="true"` on both; the other 11,317 have
0, and IDML has `false` wherever it writes the attribute. The converter
writes `true` for 1 and `false` otherwise, also for frames without the
chunk: 21,167 of 21,167 values, no extra value. The same 2 frames are
the only ones whose chunk 0x2265A (32 bytes) is not all zero, so the
corpus cannot tell the two chunks apart; offset 0 of 0x22646 is taken
because the chunk holds the other column rule values of the frame.

**Baseline frame grid of text frames.** Chunk 0x2834 of the
multi-column frame (24 bytes) holds the frame's baseline grid:

| Offset | Type | `BaselineFrameGridOption` attribute |
|---|---|---|
| 0 | u16, 1 = true | `UseCustomBaselineFrameGrid` |
| 2 | f64 | `StartingOffsetForBaselineFrameGrid` |
| 10 | u16: 0 `TopOfPage`, 1 `TopOfMargin`, 2 `TopOfFrame`, 3 `TopOfInset` | `BaselineFrameGridRelativeOption` |
| 12 | f64 | `BaselineFrameGridIncrement` |
| 20 | u32 | UID of an interface colour (class 0x1F11), 0 for the document's colour: `BaselineFrameGridColor` |

Without the chunk the values are `false`, 0, `TopOfInset`, 12 and the
document's colour (187 of 187 frames before 2026-10). The text frame
settings of an object style (chunk 0x1B924) hold the same fields at
offset 82 (u16 82, f64 84, u16 92, f64 94, u32 102).

IDML writes the element by the category rule above with category
0xADC8: when the category is off in the applied style, or the frame has
no style object, it writes all four attributes and the colour; otherwise
each attribute whose value differs from the style's, and the colour when
the frame's colour UID differs from the style's. A frame with nothing to
write has no element. The colour is the document's baseline frame grid
colour (`preferences.md`) for UID 0, otherwise the interface colour named
as for layers. The element has the colour as its only `Properties`
child and follows `TextFramePreference`.

Evidence before 2026-10: all 23,940 text frames of the 606 trustworthy
pairs (category off: 749 of 749 with every value; no style object: 4 of
4; category on with values that differ: 269 of 269 with exactly those
values; only the colour UID differs: 32 of 32; nothing differs: no
element in 22,886 of 22,886). One frame with offset 118 places the
starting offset at 2. Object styles: 1,412 of 1,412 match their
`ObjectStyle/BaselineFrameGridOption`.

Over the 1,251 trustworthy pairs after 2026-10, the converter's elements
by this rule are 1,961 of the 1,961 reference elements on the frames it
writes (the other 372 are on frames it does not write), with no extra
element. All attributes are reproduced (1,692 to 1,915 each); 1,685 of
1,727 colours are, and the 42 others are on frames with UID 0 in
documents whose document colour the converter gets wrong
(`preferences.md`). The object styles' four values are reproduced in
5,556 of 5,556 styles; code 1 `TopOfMargin` occurs in 6 styles of 6
documents, with `UseCustomBaselineFrameGrid="true"`.

**Text orientation (chunk 0x2DE).** The multi-column frame holds a
matrix (six f64) in chunk 0x2DE. Its first four values are 1 0 0 1 for
horizontal text and 0 1 −1 0 (a quarter turn) for vertical text. IDML
has no frame attribute for this; it writes the orientation on the story
(`StoryPreference`, `StoryOrientation`). Evidence:

- All 18,207 multi-column frames in the 239 distinct little-endian
  public files that have text frames have 1 0 0 1. All 2,094 stories in
  the corpus IDML files have `StoryOrientation="Horizontal"`.
- A sample typeset vertically has 0 1 −1 0 in the frames of some
  stories and 1 0 0 1 in the others. In its print PDF, the text of every
  frame with the quarter turn is set in vertical columns ordered right to
  left (glyphs of a column share an x position and follow each other
  downwards), and the text of every frame with 1 0 0 1 is set in
  horizontal lines, such as the running heads. The frames of one story
  always agree.
- In the rotated frames, `TextColumnFixedWidth` (chunk 0x2D1) equals
  the frame's height, not its width: the columns run down the page.

The last two values of the matrix are not identified. The converter
writes `Vertical` for a story whose frames all have the quarter turn,
and otherwise `Horizontal`, the value every IDML has. A story whose
frames disagree or have another matrix gets a warning. Two frames in
the InDesign 3.0 file have no chunk 0x2DE; they do not count.

**First baseline offset.** IDML writes `FirstBaselineOffset` on a frame's
`TextFramePreference` only when it differs from the frame's object style.
Over the frames of the corpus pairs, compared with the value written on
the frame or, if absent, on its object style:

| Code | IDML value | Frames |
|---|---|---|
| 1 | `AscentOffset` | 1,121 of 1,121 (13 on the frame, 1,108 from the object style) |
| 2 | `CapHeight` | 10 of 10 (copies of one document) |

No pair has code 0. The evidence for it is a sample and its print PDF. In
the PDF, the first baseline in each frame with code 0 lies below the
frame's top edge by exactly the leading of that first line, for first
lines with several different leadings. Of the values in the IDML schema
(`AscentOffset`, `CapHeight`, `LeadingOffset`, `EmboxHeight`, `XHeight`,
`FixedHeight`), only `LeadingOffset` depends on the leading.

Code 3 is `EmboxHeight`. No public file has it: the 18,207 multi-column
frames of the 239 distinct little-endian public files have code 1 or 2
only. The evidence is a sample and its print PDF, and a sample typeset
vertically with the same print PDF:

- The frames measured have code 3, `TopAlign` and one line. No chunk
  of these frames or of their multi-column frame objects holds the
  measured distance as a number, so it is not a stored minimum offset.
- A first line set in a CJK font lies below the frame's top edge by
  0.880 of its point size. The font's ideographic em box (its `BASE`
  table) has its bottom at −0.120 em, so the em box top is at 0.880 em.
  The font's cap height (0.742 em), its x-height (0.503 em), the leading
  and a fixed offset of 0 give other distances. Its ascent is also
  0.880 em.
- A first line set in a Latin font lies below the frame's top edge by
  0.825 of its point size. The font's ascent is 0.710 em, its cap height
  0.650 em and its x-height 0.400 em; the leading and a fixed offset of
  0 do not match either. So code 3 is not `AscentOffset`, which is code
  1 in any case.
- Of the values in the IDML schema, only `EmboxHeight` remains. The
  Latin font has no em box data; the measured 0.825 em equals an em box
  centred on half the cap height (0.325 + 0.5).

The converter leaves out codes other than 0 to 3.

**Text frame defaults of the document.** The preferences object (class
0x2202) has chunks 0x22646 and 0x22608 with the frame layouts, for the
document's `TextFramePreference`: f64 at 28 `ColumnRuleStrokeWidth` and
u32 at 36 `ColumnRuleStrokeColor` (a swatch UID; 195 of 195 documents
before 2026-10), and u16 at 2, f64 at 4 and f64 at 12 the footnote
span and spacings. Without chunk 0x22646 the values are 1 and
`Color/Black`. Every chunk 0x22608 in the corpus holds 0, 0, 12 and 6,
and every IDML has `false`, `false`, 12 and 6, so its offsets rest on the
frame layout. IDML writes the column rule values from DOM 15 and the
four `Footnotes…` values from 13.1 (save history, above). Over the
trustworthy pairs after 2026-10: column rule width and colour 576 of
576 each; footnote values 860 of 876 each (the other 16 were exported by
InDesign 13.1 from a document the INDD shows as saved by 13.0).

## Kinsoku and mojikumi tables

Kinsoku tables are objects of classes 0x4209 (hard), 0x420A (soft),
0x42B4 (Korean), 0x42B5 (Simplified Chinese), 0x42B6 (Traditional
Chinese) and 0x4204 (custom); mojikumi tables are classes 0x4206 and
0x4203 (custom, below). IDML writes one `KinsokuTable` or
`MojikumiTable` per object in `designmap.xml`, kinsoku tables first,
each in UID order (mojikumi tables of both classes together). Chunk 0x100B is
a flag byte (1 = built-in key, `$ID/`) and the name; `Self` is
`KinsokuTable/<Name>` or `MojikumiTable/<Name>`. Implemented in
`src/model/cjk.rs`.

Evidence: 8 pairs have such objects, and their IDML lists exactly them,
by name and in that order (6 with one table of each kind, 2 with 6
kinsoku and 16 mojikumi tables). The other 70 pairs have neither objects
nor elements.

**Custom kinsoku table (chunk 0x4214).** Five u16 counts, then that many
UTF-16 units for each of five lists: `CantBeginLineChars`,
`CantEndLineChars`, a list not identified, `HangingPunctuationChars` and
`CantBeSeparatedChars`. The evidence is one table in two copies of one
document: the four non-empty lists have different lengths (66, 22, 4
and 3), and each matches the IDML attribute of that length. The layout
parses in all 85 objects of class 0x4204 in the 250 distinct
little-endian files, and the third count is 0 in all of them.

Built-in tables have only `Self` and `Name` in IDML. Mojikumi chunk
0x421E (a u16 from 1 to 16) is not used.

**Custom mojikumi tables (class 0x4203).** Chunk 0x100B holds a flag
byte (0 in all of them) and the name, as for the other tables. Chunk
0x420A holds the settings:

| Field | Contents |
|---|---|
| u32 | 26 in all 835 objects of the 129 little-endian files that have the class |
| u32 | 0 in all |
| u32 *n* | entry count |
| *n* × 34 bytes | entries, below |
| u32, u32 | not identified |
| u16 | `BasedOnMojikumiSet`: 0 `Nothing`; *n* > 0 the built-in table `kMojikumiDefaultName<n>` (attributes.md): 1 `LineEndAllOneHalfEmEnum`, 10 `LineEndAllOneEmEnum`, 16 `SimpChineseDefault` |

Each entry is one IDML `OverrideMojikumiAkiType`:

| Offset | Type | IDML |
|---|---|---|
| 0 | u16 | `TargetMojikumiClass` |
| 2 | u16 | `SideMojikumiClass` |
| 4, 12, 20 | f64 | `Minimum`, `Desired`, `Maximum` |
| 28 | u16 | `CompressionPriority` |
| 30 | u16 | `AkiDoesNotFloat` (0 `false`, 1 `true`) |
| 32 | u16 | `SideIsAfterTarget` (0 `false`, 1 `true`) |

IDML writes the table as `<MojikumiTable Self="MojikumiTable/<name>"
Name="<name>" BasedOnMojikumiSet="…">` with `Properties`,
`OverrideMojikumiAkiList` and one `OverrideMojikumiAkiType` per entry, in
file order, with the attributes in the order `TargetMojikumiClass`,
`SideMojikumiClass`, `SideIsAfterTarget`, `Minimum`, `Desired`,
`Maximum`, `CompressionPriority`, `AkiDoesNotFloat`.

Evidence, in the corpus of 2026-10: 185 tables in 66 pairs. The entry
count matches in 185 of 185 tables, all eight fields of the entries in
file order in 62,439 of 62,439 entries, and `BasedOnMojikumiSet` in 185
of 185 (code 1: 151 tables, 0: 33, 16: 1). Seven more trustworthy pairs
(three of version 10.0, four of 10.0 and 10.1 whose IDML is from 10.2) have one table
with code 10 each, and IDML `LineEndAllOneEmEnum` in 7 of 7. `Self` is
`MojikumiTable/` and the name in all 187 custom tables of the corpus
IDML files. The layout parses in all 835 objects of the corpus; codes
3, 6, 9 and 11 also occur (232 objects, none with an IDML), and code 5
in a sample without an IDML. The built-in tables of these codes occur
in no IDML, so the converter leaves `BasedOnMojikumiSet` out for them.
The code is not the position of the value in the schema's
`MojikumiTableDefaults` list by any rule the corpus proves: the proven
codes 0, 1, 2, 10, 14, 15 and 16 are at their positions, but codes of
other enumerations are not (12 of the 50 text attribute enumerations
the converter maps differ from the schema order). A chunk whose length is not 22 + 34
*n*, or a flag other than 0 or 1, leaves the table out with a warning.
In the 66 pairs, the tables of classes 0x4206 and 0x4203 are listed
together in UID order, after all kinsoku tables.

## Colours (0x1F05)

| Chunk | Contents |
|---|---|
| 0x1F10 | u8 1 if the name is a built-in key; name; u32 flags: bit 0 removable, bit 1 visible, bit 2 editable |
| 0x1F01 | u32 space (5 RGB, 6 CMYK, 7 LAB, 14 HSB, below), u16 count, f64 components: fractions for RGB, CMYK and HSB; for LAB the L, a and b values as IDML writes them |
| 0x1F09 | u32 model: 0 Process, 1 Spot, 2 Registration (below) |
| 0x1F24 | f64 tint value (−1 for a colour, see tints below), then u32 `ColorOverride`: 0 Normal, 1 Specialpaper, 2 Specialblack, 3 Specialregistration, 4 Hiddenreserved |
| 0x1F0A | Alternate colour, as 0x1F01: space 3 none, 6 CMYK, 7 LAB |

After the flags, chunk 0x1F10 has two u32 and the `SwatchCreatorID`
(7937 for colours made in the document, other numbers for colours from a
swatch library, such as 31527). `AlternateSpace` is `NoAlternateColor`
with `AlternateColorValue=""` without chunk 0x1F0A or with space 3;
otherwise the space and the values, CMYK as percentages. Evidence over
the 12,197 colours of the trustworthy pairs whose IDML colour has the
same name: `SwatchCreatorID` 12,197 of 12,197; alternate space and
values 12,197 of 12,197 (7,527 without the chunk, 4,624 with space 3,
33 LAB and 13 CMYK alternates, all library colours).

Space 7 is `Space="LAB"`, with the three stored values as `ColorValue`
(for example `79.2156862745098 38 53`). The corpus IDML files have 92
LAB colours in 40 distinct files: 61 spot colours from swatch libraries
(41 with a LAB alternate) and 31 process colours made in the document.
Over all 803 pairs, `Space` is reproduced
for 18,935 of 18,936 colours and `ColorValue` for 18,926.

Space 14 holds hue, saturation and brightness as fractions. IDML writes
such a colour as `RGB` with `ConvertToHsb="true"`; the 9 such colours in
the pairs (all hue 0, saturation 1, brightness 1) are `255 0 0`. The
converter converts with the usual hexagon formula. Every other colour
has `ConvertToHsb="false"` (4,695 of 4,695 colours of the IDML files
from DOM 16 on, where the attribute exists).

**Colour groups.** From DOM 12 on, every swatch (colour, tint, gradient,
`None`) has `SwatchColorGroupReference`: the `ColorGroupSwatch` of the
colour group that lists it, or `n`. Over the trustworthy pairs from DOM
12 on: colours 9,135 of 9,135, gradients 450 of 450, `None` 353 of 353,
tints 24 of 24. DOM 11 files have the attribute on some swatches only
(639 of 1,584 colours), and the converter writes it from DOM 12 on.

Unnamed colours are referenced by UID (`Color/u93`). All 1,296 colours in
the pairs match on `Model`, `Space`, `ColorValue`, `ColorOverride`,
`Name` and the three flags.

**Which unnamed colours IDML writes.** A colour without a name is in the
IDML only if a value written in the package refers to it (an attribute
or element text `Color/u…`; a tint counts), if a stop of any gradient
refers to it, even of an unnamed gradient that IDML leaves out (below),
or if an entry of class 0x1F05 in one of the two tables of the
page item defaults (`preferences.md`) names it with either UID. Over the
489 trustworthy pairs, of the unnamed colours the converter wrote:

| | In the IDML | Not in the IDML |
|---|---:|---:|
| Referenced by the output | 2,309 | 0 |
| Not referenced, named in a page item defaults table | 564 | 0 |
| Neither | 10 | 8,684 |

All colours, written or not, are in the swatch list of the preferences
object (class 0x2202, chunk 0x1F02), and the colour objects of the two
groups have the same chunks and flags, so neither decides it. Named
colours are always written. Unnamed gradients follow the same rule with
class 0x5503: 457 unnamed gradients are referenced nowhere and named in
no table, and none is in the IDML; 526 of the 548 unnamed gradients
IDML writes meet the rule. Their stops go with them.

The other 22 are named by chunk 0x6E06 of the page item defaults object
(class 0x6E07). The chunk has 34 bytes in all 489 trustworthy documents
before 2026-10: u32 5, u32 0, u32 0, u32 14, then three entries of u16 0
and a u32 UID. Entry 0 names an object of class 0x5533, entry 1 a
gradient and entry 2 a colour (489 of 489 each). IDML writes the
gradient of entry 1 in every document: 480 are unnamed, and all 480 are
in the IDML; none of the 162 unnamed gradients IDML leaves out (in the
documents checked) is in the chunk. The colour of entry 2 is in the
IDML wherever the converter writes it (82 of 82). The converter treats
the swatches of chunk 0x6E06 as named by the page item defaults. With
it, every unnamed gradient of the trustworthy pairs of 2026-10 that IDML
writes is written (783 of 783 `Gradient` elements).

**Model codes.** The 250 distinct little-endian files hold 13,067
colours with chunk 0x1F09: 12,814 with code 0, 250 with code 2 (one
`Registration` colour per file) and 3 with code 1. Two of the three are
copies of one colour in two pairs, and their IDML has `Model="Spot"`;
the third is in a file without an IDML. The converter leaves `Model`
out, with a warning, for any other code.

**Code 3: mixed inks.** The corpus after 2026-10 has 47 colours with
code 3 in 27 files, 16 of them pairs (InDesign 12.1 to 17.0, typeset in
Korean). Their IDML has no `Color` element for them; it lists `MixedInk`
and `MixedInkGroup` elements in `Resources/Graphic.xml`. A colour object
with model code 3 is a mixed ink:

| Chunk | Layout | IDML |
|---|---|---|
| 0x1F09 | u32 3, u32 *n*, *n* ink UIDs (class 0x1F07) | `InkList` (`Ink/` and each ink's `Self` name), `InkNameList` (the ink names, `$ID/` for built-in ones) |
| 0x1F01 | u32 9 (colour space), u16 *n*, *n* f64 fractions | `InkPercentages`: each fraction × 100 in the shortest form that reads back (`30.000000000000004` where 0.3 × 100 gives it) |
| 0x102D | u32 *m*, *m* colour UIDs (the spot colours) | `MixedInkSpotColorList` (`Color/` and the name), `MixedInkSpotColorNameList` (the names) |
| 0x1F10 | as for colours | `Name`, `ColorEditable`, `ColorRemovable`, `Visible`, `SwatchCreatorID` |

In these lists a space of a name is written `%20`. A **mixed ink
group** is a code 3 colour that also has chunk 0x1F24 (f64 −1, u32 5);
its percentages are 0. IDML writes it as `MixedInkGroup` with `Self`,
`Model="Mixedinkmodel"`, the four lists, `Name`, the three flags,
`SwatchCreatorID` and `SwatchColorGroupReference`. The **members** of a
group are colour objects with colour space 9 in chunk 0x1F01, their own
percentages and name, chunk 0x117 the group's UID, and no chunk 0x1F09 or
0x102D: they take the ink and spot lists from the group and have
`BaseColor="MixedInkGroup/<group name>"`. Other mixed inks have
`BaseColor="n"`.

`MixedInk` writes `Self`, `Model="Mixedinkmodel"`, `Space="MixedInk"`,
`InkList`, `InkPercentages`, `BaseColor`, `InkNameList`,
`MixedInkSpotColorNameList`, `MixedInkSpotColorList`, `Name`,
`ColorEditable`, `ColorRemovable`, `Visible`, `SwatchCreatorID` and
`SwatchColorGroupReference`, in this order. `Self` is `MixedInk/` or
`MixedInkGroup/` and the name, escaped as colour names. In `Graphic.xml`
the groups follow the inks, then the mixed inks sorted by `Name` in code
point order (`… 1`, `… 10`, `… 11`, `… 2`; 16 of 16 files, UID order
fails in 3). Fill colours and colour group swatches refer to them by
`Self`.

Evidence: the 16 trustworthy pairs (DOM 12.1 to 17.0): 30 mixed inks
without a group, 48 group members and 3 groups; every attribute above
matches 81 of 81. No tint has a mixed ink as its base colour.

**Tints** are objects of the same class without chunks 0x1F10 and
0x1F01. Chunk 0x117 is the UID of the base colour, and chunk 0x1F24 holds
the tint value in percent (IDML `TintValue`) where a colour has −1,
followed by the colour override as for colours. IDML names a tint after
its base colour and value: `Name="Gold 80%"` and `Self="Tint/Gold 80%25"`
for 80 % of a colour named `Gold`. The black swatch (override
Specialblack) is written in brackets: `[Black] 40%`.

Evidence: all 2,107 colours with a name in the distinct little-endian
files have −1 at the start of chunk 0x1F24. The same files have 26 tints
in 24 files, all with this layout and a named base colour. The pairs have
3 IDML `Tint` elements (2 files, one of them on black), and all 3 match on
`TintValue`, `BaseColor`, `Name` and `ColorOverride`. Their 19 references
(`FillColor` of 15 page items, `StrokeColor` of 3, one gradient stop)
match too.

A tint's `AlternateSpace` and `AlternateColorValue` are those of its
base colour (`NoAlternateColor` and an empty list where the colour has
none): 260 of 260 IDML tints of the corpus of 2026-10 (204 in
trustworthy pairs; 9 with `LAB`).

Tints have no flags chunk, so `ColorEditable`, `ColorRemovable` and
`Visible` (true in all 3 IDML tints) are not written. Brackets are known
only for black; other reserved colours as a tint base do not occur in the
pairs.

The `None` swatch is class 0x6E0B (name in chunk 0x1F30).

**Gradients (0x5503).** Chunk 0x5503: u16 stop count *n*, *n* u32 stop
colour UIDs, *n* f64 locations (0–1), *n* f64 midpoints, u32 type (1
linear). Chunk 0x5505: flag byte, name, u32 flags as for colours. All 99
gradients and 198 stops in the pairs match.

The midpoint stored with stop *i* is the position of the midpoint between
stops *i* and *i*+1, measured from the start of the gradient (0–1), as
for opacity gradient stops (`transparency.md`). IDML writes it on stop
*i*+1 as a percentage of the distance between the two stops:
`Midpoint` = (midpoint *i* − location *i*) / (location *i*+1 − location
*i*) × 100. Evidence:

- Most pairs have two stops at locations 0 and 1, where both readings
  give the same value. Two gradients in one pair have their first stop at
  0.0037; stored midpoints 0.50184 and 0.60147 give IDML `Midpoint` 50
  and 60 with this formula (2 of 2), not 50.18 and 60.15.
- Gradients with more than two stops, or with stops not at 0 and 1,
  occur in 26 files, 392 gradients. Only the two above are in a
  reference IDML. In all 426 stop gaps of non-zero width, the stored midpoint lies
  between the two stops' locations, as a position from the start of the
  gradient must (for example stops at 0, 0.5 and 1 with stored midpoints
  0.25 and 0.75). Written to IDML unconverted, 13 of them were outside
  the 13–87 that the IDML schema allows for `Midpoint`; converted, all
  426 are inside it.
- 8 gaps, all in one file, have width 0 (two stops at the same
  location), so the formula gives no value.

When the computed value is outside 13–87 or there is none, the converter
leaves the `Midpoint` out and warns.

## Inks (0x1F07)

Each ink object with chunk 0x1F0D is one IDML `Ink` in
`Resources/Graphic.xml`, in UID order (314 of 314 inks, 78 of 78 pairs;
the four process inks are UIDs 7 to 10). `Self` is `Ink/<Name>` (973 of
973 inks in the corpus IDML files). Chunk 0x1F0D is a flag byte (1 =
built-in key, `$ID/`) and the name, then 86 bytes. Offsets from the end
of the name:

| Offset | Contents | IDML | Evidence |
|---|---|---|---|
| 14 | f64 | `NeutralDensity` | 314 of 314 (2,786 of 2,786 over the 654 pairs of the later corpus) |
| 26 | u32, one less than the IDML value | `TrapOrder` | 314 of 314 |
| 32 | f64 | `Frequency` | 314 of 314 |
| 40 | f64 | `Angle` | 314 of 314 (0, 15, 27, 45, 63 and 75) |
| 56 | u8 | `ConvertToProcess` (1 `true`) | 2,065 of 2,065 inks of the trustworthy pairs (3 `true`) |

Byte 2 is 1 for the four process inks and 0 for spot inks; its meaning
is not known. The u8 at 56 is `ConvertToProcess` (1 `true`, 0 `false`):
it is 1 for the 3 inks of the trustworthy pairs whose IDML has `true`
(one spot ink, in three copies of one document) and 0 for the other
2,062; no other byte separates them. `InkType="Normal"` and
`PrintInk="true"` are in every IDML ink and are written from that
observation (`idml-values.md`). The schema puts inks after the
colours and before the tints.

In 41 files without an IDML (InDesign 6.0, 13.x and 14.x, from two
font projects), the neutral density of all four process inks, their
only inks, is −1. The IDML schema allows 0.001 to 10 and no corpus IDML
shows what InDesign writes for such an ink, so the converter leaves
`NeutralDensity` out (with a warning) when the value is outside that
range.

## Colour groups (0x1F39)

Chunk 0x13C is a flag byte and the group name, chunk 0x1F60 a UID list
of the group's swatches. The preferences object (class 0x2202) lists the
groups in chunk 0x1F61 (u32 count, UIDs). IDML writes a `ColorGroup` in
`designmap.xml` for each listed group, in that order, with
`Self="ColorGroup/<Name>"`; the first has `IsRootColorGroup="true"`, the
others `false` (77 of 77 pairs; the DOM 7 pair has no chunk 0x1F61 and
no groups). The root group is named `[Root Color Group]` with no `$ID/`,
though its flag byte is 0.

Before DOM 11.3, `Self` is the group's UID (`u<hex>`) instead: in 58 of
the 59 trustworthy pairs of versions 10.0 to 11.2 that have groups (one
11.0 file uses names), and names in 358 of 358 pairs from 11.3 on. The
DOM version decides, not the header: header 11.4 files whose last
session was 11.0 (DOM 11.0) use the UID. With the DOM version the
converter writes (`idml-values.md`, DOM version), the extra `ColorGroup`
elements of the trustworthy pairs fall from 15 values in 5 documents to
6 in 2 (not examined), and 3 more groups are reproduced.

Each swatch of the list is a `ColorGroupSwatch` with
`Self="u<group UID>ColorGroupSwatch<index in hex>"` and `SwatchItemRef`
the swatch's reference (`Swatch/None`, `Color/…`, `Tint/…` or
`Gradient/…`). In 99 of 101 groups the list gives exactly the IDML
swatches, in order; the other two are in the pairs whose IDML was
exported from another save. The converter writes 907 of the 942 IDML
swatches, all with the IDML reference. A swatch without a reference is
left out, and the indices of the others are kept.

## Bullet characters

The preferences object (class 0x2202) lists the bullet characters
offered for lists in chunk 0x1A488: u16 1, u32 count, then for each
bullet u32 character type (0 `UnicodeOnly`, 1 `UnicodeWithFont`, 2
`GlyphWithFont`, as in `attributes.md`), u32 character value, u32 font
family UID (0 = none), a flag byte (1 = built-in key, `$ID/`) and the
font style as an in-object string, then a byte: 0, or 1 followed by four
more bytes. IDML writes one `ABullet` per entry in `designmap.xml`, with
`Self="dABullet<index>"` (the index in hexadecimal: `dABullet9`,
`dABulleta`, `dABulletb` in the 2 documents with more than ten bullets),
`CharacterType`, `CharacterValue` and the
`BulletsFont` (the family name, `$ID/` for none) and `BulletsFontStyle`
properties.

Evidence: all 78 pairs have the chunk; the count equals the number of
IDML `ABullet` elements in 78 of 78 and the records end the chunk. All
396 bullets match on type, value and font style, and 395 on the font;
the other is in the pair whose IDML names the family `Minion Pro (OTF)`
(`fonts.md`).

The byte after the font style is 0 in 7,443 of the 7,447 bullets in the
1,428 distinct little-endian files that have the chunk. In one InDesign
20.0 file (with IDML) it is 1 in four bullets, each with flag byte 2, and
four bytes follow: `00 00 90 01` after `Regular` and `00 00 BC 02` after
`Bold` (read as two u16: 0 and 400, 0 and 700). Their meaning is not
known, and IDML writes nothing for them. With this layout the records end
the chunk in all 1,428 files. In the same file, the same five bytes also
follow `Regular` in `FontStyle` attribute values (0x1B02,
`attributes.md`), whose length prefix includes them. Flag byte 2 occurs in
46 bullets; in that file's IDML its style names have no `$ID/` prefix, as
with flag 0.

## XML tags (0xBF19)

Chunk 0xBF2F is a u32 length and the tag name as text segments (in files
from InDesign 2.0 to 5.0, a flag byte and an in-object string;
`big-endian.md`); chunk
0x117 is the UID of the tag's colour, an object of class 0x1F11 whose
chunk 0x1F01 holds u32 colour space 5 (RGB), u16 3 and three f64
fractions, as for swatches. IDML writes each tag as an `XMLTag` in
`XML/Tags.xml`, with `Self="XMLTag/<Name>"` and the colour as the
`TagColor` property. In all 78 pairs the number of tag objects equals the
number of `XMLTag` elements and the names match (87 tags). IDML lists
them by name, ignoring case (the one pair with more than one tag, 10
tags).

| Red, green, blue | `TagColor` | Evidence |
|---|---|---|
| 0.31, 0.6, 1 | `LightBlue` | 78 tags (`Root`) |
| 1, 0, 0 | `Red` | 1 |
| 0.31, 1, 0.31 | `Green` | 1 |
| 0, 0, 1 | `Blue` | 1 |
| 1, 1, 0.31 | `Yellow` | 1 |
| 1, 0.31, 1 | `Magenta` | 1 |
| 0, 1, 1 | `Cyan` | 1 |
| 0.5, 0.5, 0.5 | `Gray` | 1 |
| 0, 0, 0 | `Black` | 1 |
| 0.6, 0, 0 | `BrickRed` | 1 |

Each colour other than light blue occurs once, all in one file. The
converter leaves out `TagColor` for other colours.

The XML structure (the backing story and the elements) is described in
`xml.md`.