doc-codec 2.4.3 → 2.5.0

package/README.md

@@ -17,14 +17,17 @@ Built and shipped, on the read side:
 - **Text reconstruction** — `readTextRange` turns a range of character positions into real characters through [MS-DOC] 2.4.1's own Retrieving Text algorithm, applying the specification's byte-to-code-point mapping for compressed pieces, and returns each character's byte offset alongside it.
 - **Character and paragraph formatting** — the `PlcBteChpx`/`PlcBtePapx` bin tables and the `ChpxFkp`/`PapxFkp` pages behind them, the `Sprm`/`Prl` operand-sizing rules, and the subset of the character- and paragraph-property tables listed under [What is converted](#what-is-converted), now including `sprmCRgFtc0`'s font-table lookup (see [The font table](#the-font-table)).
 - **The style sheet** — `parseStsh` reads each style's index, name, kind, parent, and (for a paragraph or character style) its own `grLPUpxSw` formatting sets; `resolveStyleFormatting` walks the `istdBase` inheritance chain and folds each style's own paragraph/character properties, most-specific style winning, beneath a paragraph's or run's own direct exceptions ([ExaDev/documents.js#1005](https://github.com/ExaDev/documents.js/issues/1005)). `headingLevelFromIstd` applies `sprmPIstd`'s own rule that an `istd` of 1 through 9 states an outline level.
-- **Tables** — `table/read.ts`'s `assembleBlocks` folds a contiguous run of table-depth-1 paragraphs into a real `ContentTable`: cell boundaries at each cell-mark (`0x07`) character, a cell holding more than one paragraph where only its last ends in a cell mark, and each row's own trailing mark (`sprmPFTtp`) resolved through `table/tap.ts`'s `applyTableSprms` for its TAP — column boundaries and every physical cell's own horizontal/vertical merge state, from `sprmTDefTable`'s `TDefTableOperand` (and a `sprmTMerge` range or `sprmTVertMerge` per-cell flag where a real producer states a merge that way instead — see [Tables](#tables) below for why both are read). A table nested inside a table cell (table depth greater than 1, detected via `sprmPItap`/`sprmPFInnerTableCell`/`sprmPFInnerTtp`) is refused with `DocUnsupportedError` rather than mis-read; a row whose own TAP this reader cannot resolve at all — no direct `sprmTDefTable` anywhere in its grpprl, or a cell-mark count that disagrees with it — degrades the whole run back to flat paragraphs instead, since that is a legal producer choice this reader does not yet follow rather than corruption (see [Tables](#tables)).
+- **Tables, including nested tables** — `table/read.ts`'s `walkBlocksAtDepth`/`assembleBlocks` fold a contiguous run of table-depth paragraphs into a real `ContentTable`, at whatever nesting depth the file states: cell boundaries at each cell-mark (`0x07`) character at depth 1, or a paragraph mark (`0x000D`) carrying `sprmPFInnerTableCell` one level deeper ([MS-DOC] 2.4.3's own depth-1-vs-deeper distinction), a cell holding more than one paragraph where only its last ends in a cell mark, and each row's own trailing mark (`sprmPFTtp`/`sprmPFInnerTtp`) resolved through `table/tap.ts`'s `applyTableSprms` for its TAP — column boundaries and every physical cell's own horizontal/vertical merge state, from `sprmTDefTable`'s `TDefTableOperand` (and a `sprmTMerge` range or `sprmTVertMerge` per-cell flag where a real producer states a merge that way instead — see [Tables](#tables) below for why both are read). A table nested inside a table cell (detected via `sprmPItap`/`sprmPFInnerTableCell`/`sprmPFInnerTtp`) resolves to a real nested `ContentTable`, to whatever depth the file actually states, rather than being refused. A row whose own TAP this reader cannot resolve at all — no direct `sprmTDefTable` anywhere in its grpprl, or a cell-mark count that disagrees with it — degrades the whole run back to flat paragraphs instead, since that is a legal producer choice this reader does not yet follow rather than corruption (see [Tables](#tables)).
 - **Table cell decoration** — `ContentTableCell.background` and `.borders`, from every encoding [MS-DOC] states them in: each cell's own four `Brc80` borders inside `TC80`, the exact-colour `sprmTSetBrc` layer a real producer writes beside them, the row-level shading arrays (`sprmTDefTableShd`/`2nd`/`3rd`, their `Raw` counterparts, the Word 97-era `sprmTDefTableShd80`, and `sprmTSetShd`/`sprmTSetShdOdd`), and, cascaded onto whichever cells and sides those leave unstated, the row/table-level `sprmTTableBorders`/`sprmTTableBorders80` border set and `sprmTSetShdTable`'s own per-row background. See [Cell decoration](#cell-decoration).
 - **`readDocContent`** — the whole chain, producing a `'wordprocessing'` `ContentDocument` of paragraphs, runs and tables.
 - **`isDocBytes`** — distinguishes a `.doc` from the `.xls`, `.ppt` and OLE embeddings that share its container, by looking for a `WordDocument` stream carrying `FibBase.wIdent`.
 - **Document metadata** — `title`/`subject`/`author`/`keywords`/`createdIso`/`modifiedIso` read from a `"\x05SummaryInformation"` stream when one is present (see [Metadata](#metadata)); `comments` and `lastPrintedIso` remain unread, since `LayoutMetadata` has no field for either.
 - **RC4-encrypted documents, decrypted for real (ExaDev/documents.js#1113)** — `readDocContent`/`readDocStreams` take an optional `password`, verified against the Table stream's own `EncryptionHeader` before anything is trusted (see [Encryption](#encryption)). XOR obfuscation and RC4 CryptoAPI stay refused, tracked on [ExaDev/documents.js#922](https://github.com/ExaDev/documents.js/issues/922).
 - **Numbering definitions** — `readDocContent`'s own `numbering` field: every list's glyph/format, level-text template, and start-at value, resolved from `PlfLst`/`PlfLfo` and keyed by the same `listId` a paragraph's `ContentParagraph.list.numId` already carries. See [Numbering definitions](#numbering-definitions), which also covers `writeDocContent`'s own inverse.
-- **The one section's own page size and margins** — `prop/sep.ts`'s `readSectionProperties` resolves `PlcfSed`/`Sepx` (`sprmSXaPage`/`sprmSYaPage`/`sprmSDxaLeft`/`sprmSDxaRight`/`sprmSDyaTop`/`sprmSDyaBottom`) into `ContentSection.pageSize`/`.margins`, falling back field by field to Word's own new-document default (US Letter, one-inch margins) for a document carrying no `PlcfSed` at all, or for any one sprm it leaves unstated. This reader only ever resolves the section spanning the whole main document — the "Section boundaries" row below states what "one section" still means.
+- **Every section's own page size and margins** — `prop/sep.ts`'s `readAllSectionProperties` resolves every `Sed` `PlcfSed` carries, each into its own `ContentSection.pageSize`/`.margins` (`sprmSXaPage`/`sprmSYaPage`/`sprmSDxaLeft`/`sprmSDxaRight`/`sprmSDyaTop`/`sprmSDyaBottom`), falling back field by field to Word's own new-document default (US Letter, one-inch margins) for a document carrying no `PlcfSed` at all, or for any one sprm a section leaves unstated. `read.ts`'s `splitIntoSections` groups the main document's own paragraphs by which section each falls in, per [MS-DOC] 2.8.26's own "each CP specifies the beginning of a range of text ... that constitutes a section" — a genuinely multi-section `.doc` now reads as multiple `ContentSection`s, each with its own real page geometry, rather than the whole document collapsing onto the first section's.
+- **Footnotes, endnotes, and comments, as plain text** — `notes.ts`'s `readNoteBodies` resolves `PlcffndTxt`/`PlcfendTxt`/`PlcfandTxt` (each a CP-only plex dividing its own subdocument into stories, [MS-DOC]'s own "each CP ... specifies the beginning of a story ... the story ends immediately prior to the next CP") into `DocContent.footnotes`/`.endnotes`/`.comments`: one `{id, text}`/`{id, text}` entry per story, `id` a synthetic one-based ordinal, matching the same simplification `ooxml.js`'s own `DocxDocument.footnotes`/`.endnotes`/`.comments` already make for the identical constructs (plain text, no paragraph/run structure). A story's own trailing guard paragraph mark ("not considered part of the story contents", [MS-DOC]'s own words) is excluded from its text; a genuinely empty story reads as `""`.
+- **Headers and footers, as real block flow** — `headers-footers.ts`'s `readHeaderFooterStories` resolves `Plcfhdd` (the identical CP-only-plex shape as the note-text plexes above) into `DocContent.headerFooterStories`: one entry per non-empty story, each carrying which section it belongs to, which of the six fixed slots it is (`evenHeader`/`oddHeader`/`evenFooter`/`oddFooter`/`firstHeader`/`firstFooter`, [MS-DOC]'s own fixed per-section story order), and a real `ContentBlock[]` — paragraphs and tables, read through the identical pipeline the main document uses, rather than plain text. An empty story ([MS-DOC]'s own "the beginning CP has the same value as the next CP") is left out of the array entirely, since it means "reuse the previous section's header/footer of this kind" rather than a genuinely blank one. The six footnote/endnote-separator stories Plcfhdd carries ahead of every section's own six are not read: neither this package's schema nor `ooxml.js`'s `DocxDocument` has anywhere to put a separator story.
+- **Inline pictures** — `pictures.ts`'s `readInlinePicture` resolves a picture character (`U+0001`, `sprmCFSpec` applied) through its own Chpx's `sprmCPicLocation` operand: an offset into the container's `"Data"` stream where a `PICF` ([MS-DOC] 68-byte type/size/border header) is followed, for every producer this reader has seen, by a real `OfficeArtInlineSpContainer` ([MS-ODRAW] 2.2.15) regardless of `PICF.mfpf.mm`'s own value. The container's own `shape` (an `OfficeArtSpContainer`) is skipped whole by its own record header's `recLen`, and the first blip record in `rgfb` immediately after it is decoded when it is `OfficeArtBlipJPEG`/`OfficeArtBlipPNG` — the two raster formats `document-schema.js`'s `ContentImageBlock` can hold losslessly — into a real inline image, sized from `PICMID`'s own `dxaGoal`/`dyaGoal` scaled by `mx`/`my`. A paragraph containing a picture anchor is split around it into a real `ContentBlock[]` (`text/paragraphs.ts`'s `buildParagraphBlocks`), since an inline image is block-level in `document-schema.js`'s own model rather than a run property — mirroring how `ooxml.js`'s own docx reader splits a paragraph around a mid-run page break, paragraph-level formatting carried unchanged onto every split piece. See [Images](#images) for what this does not read.
 
 Built and shipped, on the write side — see [Writing](#writing) for the full scope statement:
 
@@ -33,19 +36,19 @@ Built and shipped, on the write side — see [Writing](#writing) for the full sc
 
 **Not built, and not approximated, on either side.** Each of these is a genuine layer of [MS-DOC] that this package does not implement; none is silently faked, and a document using one reads (or fails to write) as though it did not:
 
-| Absent                                                          | Consequence                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
-| --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| **Nested tables**                                               | A table inside a table cell (table depth greater than 1) is a genuinely different [MS-DOC] structure — `sprmPFInnerTableCell`/`sprmPFInnerTtp` mark its cell/row ends rather than `sprmPFInTable`/`sprmPFTtp`, and `sprmPItap`/`sprmPDtap` state the depth. Neither side of this package descends into one: `readDocContent` refuses with `DocUnsupportedError` the moment it detects a table depth greater than 1, and `writeDocContent` refuses a `ContentTable` block found inside a table cell's own blocks the same way. See [Tables](#tables) for the full scope of what a depth-1 table does resolve.                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
-| **Images and drawn objects**                                    | The anchor characters (`U+0001`, `U+0008`) are dropped rather than emitted as control characters. No picture data is read. `writeDocContent` refuses an image block.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| **A style's own formatting on write**                           | A style's own property sets (`STD.grLPUpxSw`) are resolved and folded on read ([ExaDev/documents.js#1005](https://github.com/ExaDev/documents.js/issues/1005)): a paragraph's formatting is its style's own grpprlPapx/grpprlChpx (walked up the full `istdBase` inheritance chain, most-specific style winning) plus its own direct exceptions on top, and a run's own referenced character style (`sprmCIstd`) folds in the same way. `writeDocContent` mints a real STSH entry for every distinct `styleId`/`headingLevel` a document's paragraphs use ([ExaDev/documents.js#1059](https://github.com/ExaDev/documents.js/issues/1059)), so style IDENTITY round-trips -- but every minted entry carries an empty `grLPUpxSw` (no formatting of its own), since doc-codec's flat `ContentDocument` has no style-vs-direct-formatting split to draw a real one from: every property this writer emits is already, unconditionally, a direct exception. A style's own inherited formatting therefore never round-trips through a write -- only its name and istd position do. |
-| **Table and numbering style formatting**                        | `STD.grLPUpxSw` is resolved only for paragraph and character styles (`stk` 1/2, see the row above) -- a table style's `StkTableGRLPUPX` (its own `TAPX` plus `CNFC`-conditional per-region formatting, [MS-DOC] 2.4.6.6's own table-specific steps 6-9) and a numbering style's `StkListGRLPUPX` are neither read nor written. A table applying a named table style, or a paragraph using a numbering style rather than direct list formatting, reports none of the formatting either would supply.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| **Subdocuments**                                                | Only the main document (character positions 0 to `ccpText`) is converted. Footnotes, endnotes, headers, footers, comments and text boxes are not, in either direction.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
-| **Section boundaries**                                          | Section boundaries themselves are not read — the whole document is always treated as one section, spanning the entire main document — so a multi-section `.doc`'s later sections' own page size and margins are never consulted, only the first's (see the read-side page-size/margins bullet above for what is now read of that one section). `writeDocContent` refuses a `ContentDocument` with more than one section, rather than silently merging their content into what would read back as one.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
-| **Extended and user-defined document properties**               | `title`/`subject`/`author`/`keywords`/`createdIso`/`modifiedIso` are read from and written to a `"\x05SummaryInformation"` stream when present (see [Metadata](#metadata)); the sibling `"\x05DocumentSummaryInformation"` stream (company, manager, and custom user-defined properties) is not read or written at all.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| **Encryption**                                                  | RC4-encrypted documents ([MS-DOC] 2.2.6.2, ExaDev/documents.js#1113) are decrypted given a password -- `readDocContent`/`readDocStreams` take an optional `password`, verified against the Table stream's own EncryptionHeader before anything is trusted (see [Encryption](#encryption) below). XOR obfuscation and RC4 CryptoAPI (a different, newer EncryptionHeader shape) still refuse with a `DocUnsupportedError` rather than being read as plaintext or misread as the wrong scheme. `writeDocContent` never encrypts.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| **`sprmPHugePapx` / `sprmPTableProps`**                         | Paragraph properties stored indirectly in the Data stream are not followed, so such a paragraph reads with fewer properties than it states. [MS-DOC] 2.4.3's own Overview of Tables text names `sprmPTableProps` as a real, legal alternative to `sprmTDefTable` some applications process — but a real producer's row mark is not shown to prefer it: a genuine LibreOffice-authored `.doc` table's own row mark states its TAP through the identical direct `sprmTDefTable` this package's reader and writer already use (confirmed by parsing a LibreOffice 26.2.5.2-authored table's raw `PapxFkp` bytes; see [ExaDev/documents.js#892](https://github.com/ExaDev/documents.js/issues/892)), matching 2.4.3's own compatibility guidance ("An application SHOULD use sprmTDefTable to define table cells for applications that do not process sprmPTableProps"). `writeDocContent` never writes an indirect Papx.                                                                                                                                                          |
-| **Hyperlinks and fields**                                       | `ContentRun.hyperlink`, footnote/comment/annotation references, and every other field or anchor character are read as plain text or dropped (see [What is converted](#what-is-converted)) and are not written.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| **Every FIB field beyond what this package's own reader needs** | `writeDocContent` populates only the fc/lcb pairs its own reader consults (the style sheet, the two property bin tables, the Clx, the font table). Roughly 140 other `FibRgFcLcb97` pairs — `SttbfAssoc`, `Dop`, the printer-driver structures among them — are left zero, which is the format's own "undefined, MUST be ignored" contract for most of them, but not a certification that every third-party [MS-DOC] reader accepts the result; see `fib/write.ts`'s own note.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| Absent                                                                                    | Consequence                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Nested tables, on write**                                                               | `readDocContent` recurses into a table nested inside a table cell to whatever depth the file states (see the read-side Tables bullet above and [Tables](#tables)). `writeDocContent` still refuses a `ContentTable` block found inside a table cell's own blocks: it has no depth-aware sgc-1/sgc-5 grpprl encoding for anything past depth 1, and writing one incorrectly would silently corrupt the nested table's own structure rather than fail loudly.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| **Floating/anchored drawn objects, text boxes, and every picture format beyond JPEG/PNG** | An inline picture (`U+0001`) resolves to a real image when its own blip is `OfficeArtBlipJPEG`/`OfficeArtBlipPNG` (see the read-side Inline pictures bullet above and [Images](#images)). A floating or anchored drawn object (`U+0008`, `PlcfSpa`) is a genuinely different structure — an arbitrary `OfficeArtSpContainer` shape (which may or may not be a picture at all), reached through a document-level drawing tree (`OfficeArtDgContainer`) rather than a single inline blip — and is not resolved at all; its anchor character is dropped. A text box rides the identical drawing layer (`PlcfTxbxTxt`, itself anchored via a drawn object), so it is likewise not read. A blip format other than JPEG/PNG (a WMF/EMF/PICT metafile, a raw DIB, TIFF) is a structure this package's own image schema (`png`/`jpeg`/`svg`/`gif` only) has nowhere to hold without re-encoding pixels this package has no image codec to perform, so `readInlinePicture` returns undefined for one rather than mis-decoding it, and the anchor drops exactly as an unresolved floating object's does. `writeDocContent` refuses an image block outright, on either side of this line. |
+| **A style's own formatting on write**                                                     | A style's own property sets (`STD.grLPUpxSw`) are resolved and folded on read ([ExaDev/documents.js#1005](https://github.com/ExaDev/documents.js/issues/1005)): a paragraph's formatting is its style's own grpprlPapx/grpprlChpx (walked up the full `istdBase` inheritance chain, most-specific style winning) plus its own direct exceptions on top, and a run's own referenced character style (`sprmCIstd`) folds in the same way. `writeDocContent` mints a real STSH entry for every distinct `styleId`/`headingLevel` a document's paragraphs use ([ExaDev/documents.js#1059](https://github.com/ExaDev/documents.js/issues/1059)), so style IDENTITY round-trips -- but every minted entry carries an empty `grLPUpxSw` (no formatting of its own), since doc-codec's flat `ContentDocument` has no style-vs-direct-formatting split to draw a real one from: every property this writer emits is already, unconditionally, a direct exception. A style's own inherited formatting therefore never round-trips through a write -- only its name and istd position do.                                                                                                 |
+| **Table and numbering style formatting**                                                  | `STD.grLPUpxSw` is resolved only for paragraph and character styles (`stk` 1/2, see the row above) -- a table style's `StkTableGRLPUPX` (its own `TAPX` plus `CNFC`-conditional per-region formatting, [MS-DOC] 2.4.6.6's own table-specific steps 6-9) and a numbering style's `StkListGRLPUPX` are neither read nor written. A table applying a named table style, or a paragraph using a numbering style rather than direct list formatting, reports none of the formatting either would supply.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
+| **Subdocuments, on write; text boxes, on either side**                                    | Footnotes, endnotes, comments, and headers/footers are now read (see the three read-side bullets above); none is written — `writeDocContent` still only ever produces a main document with `ccpFtn`/`ccpHdd`/`ccpAtn`/`ccpEdn` all zero, and a `ContentDocument` carries nowhere on its own `ContentSection.blocks` to state a header/footer's own content distinctly from the body's, which a real inverse would need. Text boxes are not read or written in either direction: `PlcfTxbxTxt` divides its own subdocument into stories the identical way the note-text plexes above do, but a text box's own anchor rides the drawn-object mechanism ([Images](#images)'s own scope note), which this package does not resolve.                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| **Multiple sections, on write**                                                           | `readDocContent` resolves every section `PlcfSed` states, each with its own page size and margins (see the read-side bullet above). `writeDocContent` still refuses a `ContentDocument` with more than one section, rather than silently merging their content into what would read back as one — writing a real multi-section `PlcfSed`/`Sepx` array is unimplemented on the write side.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| **Extended and user-defined document properties**                                         | `title`/`subject`/`author`/`keywords`/`createdIso`/`modifiedIso` are read from and written to a `"\x05SummaryInformation"` stream when present (see [Metadata](#metadata)); the sibling `"\x05DocumentSummaryInformation"` stream (company, manager, and custom user-defined properties) is not read or written at all.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| **Encryption**                                                                            | RC4-encrypted documents ([MS-DOC] 2.2.6.2, ExaDev/documents.js#1113) are decrypted given a password -- `readDocContent`/`readDocStreams` take an optional `password`, verified against the Table stream's own EncryptionHeader before anything is trusted (see [Encryption](#encryption) below). XOR obfuscation and RC4 CryptoAPI (a different, newer EncryptionHeader shape) still refuse with a `DocUnsupportedError` rather than being read as plaintext or misread as the wrong scheme. `writeDocContent` never encrypts.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| **`sprmPHugePapx` / `sprmPTableProps`**                                                   | Paragraph properties stored indirectly in the Data stream are not followed, so such a paragraph reads with fewer properties than it states. [MS-DOC] 2.4.3's own Overview of Tables text names `sprmPTableProps` as a real, legal alternative to `sprmTDefTable` some applications process — but a real producer's row mark is not shown to prefer it: a genuine LibreOffice-authored `.doc` table's own row mark states its TAP through the identical direct `sprmTDefTable` this package's reader and writer already use (confirmed by parsing a LibreOffice 26.2.5.2-authored table's raw `PapxFkp` bytes; see [ExaDev/documents.js#892](https://github.com/ExaDev/documents.js/issues/892)), matching 2.4.3's own compatibility guidance ("An application SHOULD use sprmTDefTable to define table cells for applications that do not process sprmPTableProps"). `writeDocContent` never writes an indirect Papx.                                                                                                                                                                                                                                                          |
+| **Hyperlinks and fields**                                                                 | `ContentRun.hyperlink`, footnote/comment/annotation references, and every other field or anchor character are read as plain text or dropped (see [What is converted](#what-is-converted)) and are not written.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| **Every FIB field beyond what this package's own reader needs**                           | `writeDocContent` populates only the fc/lcb pairs its own reader consults (the style sheet, the two property bin tables, the Clx, the font table). Roughly 140 other `FibRgFcLcb97` pairs — `SttbfAssoc`, `Dop`, the printer-driver structures among them — are left zero, which is the format's own "undefined, MUST be ignored" contract for most of them, but not a certification that every third-party [MS-DOC] reader accepts the result; see `fib/write.ts`'s own note.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 
 One construct is refused rather than mis-read: a `sprmPChgTabs` whose `cb` is the `255` sentinel encodes its own length as a formula over tab-stop counts this package does not parse, and its length is needed to find the next `Prl`. Rather than guess and silently mis-read every property after it, `operandSize` throws.
 
@@ -86,7 +89,7 @@ Fields are handled structurally: everything between a field-begin (`U+0013`) and
 
 ## Tables
 
-A table in [MS-DOC] is not a separate container: it is a run of ordinary paragraphs marked `sprmPFInTable`, with cell boundaries at literal `0x07` cell-mark characters in the text stream and each row closed by its own row-ending mark — a cell mark additionally carrying `sprmPFTtp` — per [MS-DOC] 2.4.3's own Overview of Tables. `src/table/` implements exactly this model, at table depth 1 only; a table nested inside a table cell is refused rather than mis-read (see the "Nested tables" row in the scope table above).
+A table in [MS-DOC] is not a separate container: it is a run of ordinary paragraphs marked `sprmPFInTable`, with cell boundaries at literal `0x07` cell-mark characters in the text stream and each row closed by its own row-ending mark — a cell mark additionally carrying `sprmPFTtp` — per [MS-DOC] 2.4.3's own Overview of Tables. `src/table/` implements exactly this model on the read side at every depth a document states: a table nested inside a table cell (table depth greater than 1) uses a genuinely different pair of marks — a paragraph mark (`0x000D`) carrying `sprmPFInnerTableCell` for a cell boundary, `sprmPFInnerTtp` for a row's own terminating mark, in place of the cell-mark character depth 1 uses — and `table/read.ts`'s `walkBlocksAtDepth`/`tryAssembleTable` are mutually recursive over that depth, so a cell's own content resolves to a nested `ContentTable` wherever the file states one, to whatever depth it actually nests. The write side stays depth-1 only: `writeDocContent` still refuses a `ContentTable` block found inside a table cell's own blocks (see the "Nested tables, on write" row in the scope table above).
 
 **Reading** (`table/read.ts`'s `assembleBlocks`, called from `read.ts`). It walks the flat paragraph sequence `read.ts` already produces, grouping every contiguous run of `inTable` paragraphs into a `ContentTable`: consecutive paragraphs up to and including the one terminated by an ordinary cell mark become one cell's own `blocks` (a cell may hold more than one paragraph — only its last ends in a cell mark, per 2.4.3's own "the last paragraph in a table cell is terminated by a cell mark"), and the row's own trailing mark resolves the row's whole TAP through `table/tap.ts`'s `applyTableSprms`: column boundaries and every physical cell's own merge state, read directly from `sprmTDefTable`'s `TDefTableOperand` — its `rgdxaCenter` array and its `rgTc80` array of per-column `TC80` records ([MS-DOC] 2.9.313, whose own `tcgrf` field is 2.9.317) — folded with a `sprmTMerge` range or `sprmTVertMerge` per-cell flag on top where a real producer states a merge incrementally instead, genuinely regardless of which order the two appear in within the grpprl (`table/tap.ts`'s own note). Column layout is never assumed shared across a table's own rows: [MS-DOC] 2.6.3 permits each row to declare its own independent `rgdxaCenter` ("There is no requirement that each row of a table have the same number of cells"), and a real, independent [MS-DOC] implementation (LibreOffice 26.2.5.2) was confirmed to rely on exactly this for a horizontal merge — its own merged row simply has fewer, wider physical cells, with no `TCGRF.horzMerge`/`sprmTMerge` signal at all (see the third-party verification paragraph below). `table/read.ts` reconstructs the table's shared column grid as the union of every row's own `rgdxaCenter` boundary values, then expresses each physical cell's own `colSpan` as however many of that shared grid's segments its own boundaries cover. That union is taken within one point rather than by exact integer equality, because [MS-DOC] states those boundaries per row and defines no quantum coarser than the twip itself for them, so two rows meaning the identical grid may legally disagree by a twip or two — and an exact union turns that drift into a phantom hairline column plus a spurious `colSpan` on the cells of every row either side of it (two rows one twip apart across a 2338-twip boundary read back as `columnWidthsPt` `[116.9, 0.05, 144.95, 220]` instead of `[116.9, 145, 220]`; [ExaDev/documents.js#898](https://github.com/ExaDev/documents.js/issues/898)). The default tolerance is `TWIPS_PER_POINT` itself, not a picked number: `columnWidthsPt` states the reconstructed grid in points, so a segment narrower than one point sits below the smallest unit that grid can distinguish at all. It is also the fuzz a real, independent implementation applies to an analogous reconstruct-one-shared-grid-from-N-per-row-arrays problem — LibreOffice's table model is per-row too (`SwTableLine` → `SwTableBox`, each box carrying its own width), and `sw/source/filter/inc/wrtswtbl.hxx` answers it, on its own ODF export (the point at which it projects that per-row model onto one shared grid, `sw/source/filter/xml/xmltble.cxx`'s `SwXMLTableColumn_Impl`), with `#define COLFUZZY 20` twips, `SwWriteTableCol::operator==` treating two column positions as equal when they differ by at most that. Its changeover was confirmed empirically and exactly, not assumed: patching a single `int16` inside a real LibreOffice-authored table's second row and round-tripping it through that implementation's own `.doc` import followed by its ODF export gives three columns and no covered cell for a drift of 1 through 20 twips, and four columns with a real `table:covered-table-cell` from 21 (the `.doc` import side alone preserves the drifted boundary byte-for-byte — the fuzz is applied on export, not import). Per-row drift is not hypothetical even without Word or LibreOffice's own export step in the picture: `WW8TabDesc::CalcDefaults` widens any imported cell narrower than that same implementation's own minimum cell width (`MINLAY`, 23 twips in `sw/inc/swtypes.hxx`) by mutating boundaries per row during `.doc` import itself, so a document that has been through that import is one real mechanism by which per-row drift reaches a `.doc` at all.
 
@@ -158,6 +161,34 @@ A paragraph's own `list.numId`/`list.level` (`sprmPIlfo`/`sprmPIlvl`, unchanged
 
 **The write side is verified by this package's own round trip, not yet against a third-party implementation.** `write.test.ts`'s own `describe("writeDocContent numbering")` block covers a multi-level list (`format`/`text` per level surviving through `readDocContent`), a bulleted list (its glyph, not a numbered placeholder), separate `ilfo` minting for separate `numId`s, a document with no lists at all (no `PlfLst`/`PlfLfo` written), and a list membership inside a table cell -- every case reading back through this package's own reader exactly as written. `list/numbering-write.test.ts` covers `buildNumberingTables` one layer down, independently of `gatherListUsage`: the `LSTF`/`LFO` byte shape a hand-built `NumberingDefinitions` produces, the empty-definitions-map case returning `undefined`, the numerically-colliding-key rejection described above, and that `gatherListUsage`'s own output can never trigger that rejection. Unlike the read side's LibreOffice cross-check above, no independent [MS-DOC] implementation has yet opened a `writeDocContent` numbering sample: that verification is the next thing worth doing here, mirroring how [Tables](#tables) and [Cell decoration](#cell-decoration) were each verified once a real producer's own file was available to compare against.
 
+## Sections
+
+[MS-DOC] 2.8.26's `PlcfSed` divides the main document's own text into sections the identical way `Plcfhdd`/`PlcffndTxt`/`PlcfandTxt`/`PlcfendTxt` (below) divide their own subdocuments into stories: an array of CPs, each naming where the next section's text begins, "the range of text ends immediately prior to the next CP." `prop/sep.ts`'s `readAllSectionProperties` resolves every `Sed` this way, in document order, each into its own page width/height and four margins via `applySectionSprms` (`sprmSXaPage`/`sprmSYaPage`/`sprmSDxaLeft`/`sprmSDxaRight`/`sprmSDyaTop`/`sprmSDyaBottom`); `read.ts`'s `splitIntoSections` then walks the main document's own flat paragraph sequence once, advancing to the next section exactly when a paragraph's own end CP matches the next section's start CP — the paragraph carrying the end-of-section character (`0x000C`) itself, per [MS-DOC]'s own "there MUST also be an end-of-section character... as the final character in the text range of all but the last section." A file with no `PlcfSed` at all (`lcbPlcfSed` 0) reads as a single section falling back, field by field, to Word's own new-document default (US Letter, one-inch margins) — the identical fallback a `PlcfSed` that leaves one sprm unstated already used before multi-section support existed.
+
+Only page size and the four margins are resolved, matching what `document-schema.js`'s own `ContentSection` (`pageSize` + `margins`) has anywhere to hold; every other section sprm (columns, headers/footers distance, vertical justification, page borders, line numbering, and the rest of the roughly seventy [MS-DOC] 2.6.4 names) is absent rather than present-and-ignored, the identical documented-gap convention the paragraph- and character-property tables already use. `writeDocContent` still only ever writes one section (see [Writing](#writing)); a real multi-section write is unimplemented.
+
+## Subdocuments
+
+The main document is only the first of several logical text ranges [MS-DOC] 2.4.1 concatenates into one CP space, in this fixed order: the main document (`0` to `ccpText`), the footnote document (`ccpFtn` characters), the header document (`ccpHdd`), the comment/annotation document (`ccpAtn`), the endnote document (`ccpEdn`), and the textbox documents (`ccpTxbx`/`ccpHdrTxbx`, not read at all — see below). `subdocument.ts`'s `readSubdocumentStories` is the one function every subdocument this package reads goes through: it reads a subdocument's own CP range via the identical `readTextRange`/`readParagraphs` pipeline the main document uses, then splits the resulting flat paragraph sequence by a boundary plex's own CPs (`text/paragraphs.ts`'s `splitEntriesByBoundaries`) into one group per story. `PlcffndTxt`/`PlcfandTxt`/`PlcfendTxt`/`Plcfhdd` all share the identical shape and the identical two conventions this one function handles once: "the story is considered empty" when two consecutive CPs are equal (skipped past, never assigned any entry — a run of several empty stories in a row is handled correctly, not just a single one), and a trailing CP the structure's own page states is "undefined and MUST be ignored" (the last group `readSubdocumentStories` produces is always dropped). A non-empty story's own final paragraph — a bare paragraph mark with no content of its own, the guard "not considered part of the story contents" — is likewise dropped from what a caller actually sees.
+
+**Footnotes, endnotes, and comments** (`notes.ts`) resolve to `DocContent.footnotes`/`.endnotes`/`.comments`: one `{id, text}` entry per story, `id` a synthetic one-based ordinal in document order (this reader does not resolve `PlcffndRef`/`PlcfandRef`/`PlcfendRef`'s own reference data — the auto-numbering/custom-symbol state a real footnote mark carries — only the order its own text plex already states), `text` the story's own paragraphs joined by `\n`. This is a deliberate simplification matching `ooxml.js`'s own `DocxDocument.footnotes`/`.endnotes`/`.comments`, which carry the identical flat-text shape for the identical constructs rather than real block flow.
+
+**Headers and footers** (`headers-footers.ts`) resolve to `DocContent.headerFooterStories`, real block flow instead: `Plcfhdd`'s own fixed layout is six footnote/endnote-separator stories (not read — neither this package's schema nor `ooxml.js`'s `DocxDocument` has anywhere to put one), then six per section in a fixed order (`evenHeader`, `oddHeader`, `evenFooter`, `oddFooter`, `firstHeader`, `firstFooter`), so each resolved story carries its own `section` index, `slot`, and a genuine `ContentBlock[]` read through the same `assembleBlocks` pipeline the main document uses — paragraphs and tables both. An empty story means "the header/footer of this kind from the previous section is reused" ([MS-DOC]'s own words) rather than a deliberately blank one, so it is left out of the array entirely instead of appearing as a hollow `{blocks: []}` entry.
+
+**Not read at all: text boxes.** `PlcfTxbxTxt`/`PlcfHdrtxbxTxt` divide their own subdocument into stories the identical way, but a text box's own anchor is a drawn object (`U+0008`, `PlcfSpa`) — the same drawing-layer mechanism [Images](#images) below does not resolve — so there is no way to reach a text box's own story from the main document's text at all without that layer, and this package does not attempt it.
+
+Nothing on this subdocument side is written: `writeDocContent` produces a main document only, with `ccpFtn`/`ccpHdd`/`ccpAtn`/`ccpEdn` all zero (`fib/write.ts`'s own note).
+
+## Images
+
+An inline picture is a character with Unicode value `U+0001` ("A picture location that is used in conjunction with sprmCPicLocation") carrying `sprmCFSpec` and `sprmCPicLocation` — a signed 32-bit offset into the container's own `"Data"` stream, a stream with "no predefined structure... referenced from the FIB or from other parts of the file," genuinely optional like `"\x05SummaryInformation"`. `pictures.ts`'s `readInlinePicture` reads what sits at that offset: a 68-byte `PICF` (type/size/border information — `cbHeader`, `mfpf.mm`, `PICF_Shape`, `PICMID`'s own `dxaGoal`/`dyaGoal`/`mx`/`my` and four `Brc80` borders this package does not read), an optional `cchPicName`/`stPicName` pair when `mfpf.mm` is `MM_SHAPEFILE`, then `picture`: a real `OfficeArtInlineSpContainer` ([MS-ODRAW] 2.2.15) — every producer this reader has seen writes this container regardless of `mfpf.mm`'s own value, so there is no simpler, non-OfficeArt path even for the plainest bitmap. The container's own `shape` (an `OfficeArtSpContainer`, [MS-ODRAW] 2.2.14) is skipped whole by its own 8-byte record header's `recLen` — this reader has no need for a shape's own fill/line/position properties — and the first entry of `rgfb` immediately after it, an `OfficeArtBlip` record, is read directly: its own `recInstance` states how many 16-byte MD4 `rgbUid` fields precede the one-byte internal-resource `tag` and the raw file bytes (one for `OfficeArtBlipJPEG`'s RGB/CMYK-1-UID instances and `OfficeArtBlipPNG`'s 1-UID instance, two for each format's own 2-UID sibling), so `blipDataStart`/`blipDataLength` fall out directly from the header once the format is known. `widthPt`/`heightPt` come from `PICMID`'s own `dxaGoal`/`dyaGoal` (the picture's initial size in twips) scaled by `mx`/`my` (each "the ratio, measured in tenths of a percent, between the final display width/height and the initial picture width/height") and converted to points.
+
+**Only `OfficeArtBlipJPEG` (`0xF01D`) and `OfficeArtBlipPNG` (`0xF01E`) are decoded** — the two raster formats `document-schema.js`'s `ContentImageBlockSchema` can hold losslessly (`format: "png" | "jpeg" | "svg" | "gif"`). Every other blip kind `readInlinePicture` returns `undefined` for rather than mis-decoding: a metafile (`OfficeArtBlipEMF`/`WMF`/`PICT`) carries a further `OfficeArtMetafileHeader` and, for EMF/WMF, DEFLATE-compressed payload bytes this package has no decompressor for; a raw DIB (`OfficeArtBlipDIB`) has no `ContentImageBlock` format token to hold it under at all without an image codec to re-encode its pixels as PNG, which this package does not have; `OfficeArtBlipTIFF` is likewise a format this schema names no token for. A paragraph whose only content is such an anchor still reads as a genuine, empty `ContentParagraph` — the identical degrade an unresolved anchor already produced before this feature existed — rather than losing the paragraph entirely.
+
+**A paragraph is split around a resolved (or attempted) picture, never left as a run.** An inline image is block-level in `document-schema.js`'s own model, so `text/paragraphs.ts`'s `buildParagraphBlocks` splits the paragraph's own text at each `U+0001` anchor into however many `ContentBlock`s the anchors demand — a leading paragraph, the image, a trailing paragraph, and so on for a paragraph carrying more than one — every split paragraph piece keeping the whole paragraph's own alignment/spacing/list attributes unchanged, mirroring how `ooxml.js`'s own docx reader already splits a paragraph around a mid-run page break. A paragraph containing nothing but one unresolved picture anchor (an unsupported blip format, or no `"Data"` stream at all) collapses to the identical single empty `ContentParagraph` a plain anchor-only paragraph always produced; a paragraph that resolves to at least one real block (text, an image) never gains a synthetic empty wrapper alongside it.
+
+**Not read: floating/anchored drawn objects and text boxes.** A floating picture is a different anchor entirely — `U+0008` ("A drawn object. See plcfSpa"), referenced by a `PlcfSpa` (`SPA` records, 26 bytes each, one `spid` per anchor) that names a shape inside a document-level `OfficeArtDgContainer` drawing tree rather than a single inline blip a `Chpx` sprm points at directly. That shape need not even be a picture — an arbitrary `OfficeArtSpContainer` (autoshape, connector, text box) — so resolving one properly means walking the whole drawing tree, not decoding one more blip kind; this package does not attempt it, and the anchor character drops exactly as any other unresolved anchor does. `writeDocContent` refuses an image block outright, on either side of this line.
+
 ## Metadata
 
 A `.doc`'s title, author, and dates do not live in any [MS-DOC] structure at all — they live in a `"\x05SummaryInformation"` stream, a genuinely different format ([MS-OLEPS] Property Set Streams) that happens to sit beside `WordDocument`/`1Table` in the same [MS-CFB] compound file. `readDocContent` reads that stream when present (`archive-codec`'s `readSummaryInformation`, since the property-set format itself is zero document-format knowledge, exactly as the [MS-CFB] container it sits inside is) and maps it onto `document-schema.js`'s `LayoutMetadata` (`archive-codec`'s own `summaryInformationToLayoutMetadata` — the mapping is format-agnostic, so it lives there rather than being copied in this package, alongside `xls-codec`'s and `ppt-codec`'s identical need for it); `writeDocContent` does the inverse (`src/metadata.ts`'s `layoutMetadataToSummaryInformation`, which validates `createdIso`/`modifiedIso` as real dates and throws a `DocFormatError` naming the offending field before delegating to `archive-codec`'s own mapping — see [Writing](#writing)), including a `"\x05SummaryInformation"` stream in its `writeCompoundFile` call only when the input's metadata actually carries something that stream can hold — an input whose metadata is `{}`, or carries only fields the mapping below has no destination for, produces no stream at all, matching what an absent-metadata read already returns.

package/dist/chp-B6AOh85P.d.ts

@@ -0,0 +1,18 @@
+import { t as Prl } from "./sprm-DEyvdOo0.js";
+import { Color } from "document-schema.js";
+//#region src/prop/chp.d.ts
+interface CharacterProperties {
+  bold?: boolean;
+  italic?: boolean;
+  underline?: boolean;
+  strike?: boolean;
+  sizePt?: number;
+  color?: Color;
+  fontFamily?: string;
+  /** The istd of a character style applied by sprmCIstd, carried so a caller can resolve the style's own name. */
+  istd?: number;
+}
+declare function applyCharacterSprms(prls: readonly Prl[], into: CharacterProperties, fonts?: readonly string[]): CharacterProperties;
+declare function characterIstdFromGrpprl(prls: readonly Prl[]): number | undefined;
+//#endregion
+export { applyCharacterSprms as n, characterIstdFromGrpprl as r, CharacterProperties as t };

package/dist/chp-BpCqpb7V.d.cts

@@ -0,0 +1,18 @@
+import { t as Prl } from "./sprm-DEyvdOo0.cjs";
+import { Color } from "document-schema.js";
+//#region src/prop/chp.d.ts
+interface CharacterProperties {
+  bold?: boolean;
+  italic?: boolean;
+  underline?: boolean;
+  strike?: boolean;
+  sizePt?: number;
+  color?: Color;
+  fontFamily?: string;
+  /** The istd of a character style applied by sprmCIstd, carried so a caller can resolve the style's own name. */
+  istd?: number;
+}
+declare function applyCharacterSprms(prls: readonly Prl[], into: CharacterProperties, fonts?: readonly string[]): CharacterProperties;
+declare function characterIstdFromGrpprl(prls: readonly Prl[]): number | undefined;
+//#endregion
+export { applyCharacterSprms as n, characterIstdFromGrpprl as r, CharacterProperties as t };

package/dist/detect.cjs

@@ -7,6 +7,8 @@ let archive_codec = require("archive-codec");
 const WORD_DOCUMENT_STREAM = "WordDocument";
 /** The [MS-OLEPS] Property Set Stream a .doc's title/author/dates live in when present -- a genuinely optional stream, unlike WordDocument, since a valid Word Binary File need not carry document properties at all. */
 const SUMMARY_INFORMATION_STREAM = "SummaryInformation";
+/** The stream sprmCPicLocation's operand addresses, [MS-DOC] "Data Stream": "has no predefined structure. It contains data that is referenced from the FIB or from other parts of the file. This stream need not be present if there are no references to it." -- genuinely optional, like SUMMARY_INFORMATION_STREAM, since a document with no pictures need not carry one. */
+const DATA_STREAM = "Data";
 function isDocBytes(bytes) {
 	if (!(0, archive_codec.isCompoundFile)(bytes)) return false;
 	let streams;
@@ -20,6 +22,7 @@ function isDocBytes(bytes) {
 	return require_bytes.readUint16LE(wordDocument.bytes, 0) === require_fib_offsets.FIB_W_IDENT;
 }
 //#endregion
+exports.DATA_STREAM = DATA_STREAM;
 exports.SUMMARY_INFORMATION_STREAM = SUMMARY_INFORMATION_STREAM;
 exports.WORD_DOCUMENT_STREAM = WORD_DOCUMENT_STREAM;
 exports.isDocBytes = isDocBytes;

package/dist/detect.d.cts

@@ -3,6 +3,8 @@
 declare const WORD_DOCUMENT_STREAM = "WordDocument";
 /** The [MS-OLEPS] Property Set Stream a .doc's title/author/dates live in when present -- a genuinely optional stream, unlike WordDocument, since a valid Word Binary File need not carry document properties at all. */
 declare const SUMMARY_INFORMATION_STREAM = "SummaryInformation";
+/** The stream sprmCPicLocation's operand addresses, [MS-DOC] "Data Stream": "has no predefined structure. It contains data that is referenced from the FIB or from other parts of the file. This stream need not be present if there are no references to it." -- genuinely optional, like SUMMARY_INFORMATION_STREAM, since a document with no pictures need not carry one. */
+declare const DATA_STREAM = "Data";
 declare function isDocBytes(bytes: Uint8Array<ArrayBuffer>): boolean;
 //#endregion
-export { SUMMARY_INFORMATION_STREAM, WORD_DOCUMENT_STREAM, isDocBytes };
+export { DATA_STREAM, SUMMARY_INFORMATION_STREAM, WORD_DOCUMENT_STREAM, isDocBytes };

package/dist/detect.d.ts

@@ -3,6 +3,8 @@
 declare const WORD_DOCUMENT_STREAM = "WordDocument";
 /** The [MS-OLEPS] Property Set Stream a .doc's title/author/dates live in when present -- a genuinely optional stream, unlike WordDocument, since a valid Word Binary File need not carry document properties at all. */
 declare const SUMMARY_INFORMATION_STREAM = "SummaryInformation";
+/** The stream sprmCPicLocation's operand addresses, [MS-DOC] "Data Stream": "has no predefined structure. It contains data that is referenced from the FIB or from other parts of the file. This stream need not be present if there are no references to it." -- genuinely optional, like SUMMARY_INFORMATION_STREAM, since a document with no pictures need not carry one. */
+declare const DATA_STREAM = "Data";
 declare function isDocBytes(bytes: Uint8Array<ArrayBuffer>): boolean;
 //#endregion
-export { SUMMARY_INFORMATION_STREAM, WORD_DOCUMENT_STREAM, isDocBytes };
+export { DATA_STREAM, SUMMARY_INFORMATION_STREAM, WORD_DOCUMENT_STREAM, isDocBytes };

package/dist/detect.js

@@ -6,6 +6,8 @@ import { isCompoundFile, readCompoundFile } from "archive-codec";
 const WORD_DOCUMENT_STREAM = "WordDocument";
 /** The [MS-OLEPS] Property Set Stream a .doc's title/author/dates live in when present -- a genuinely optional stream, unlike WordDocument, since a valid Word Binary File need not carry document properties at all. */
 const SUMMARY_INFORMATION_STREAM = "SummaryInformation";
+/** The stream sprmCPicLocation's operand addresses, [MS-DOC] "Data Stream": "has no predefined structure. It contains data that is referenced from the FIB or from other parts of the file. This stream need not be present if there are no references to it." -- genuinely optional, like SUMMARY_INFORMATION_STREAM, since a document with no pictures need not carry one. */
+const DATA_STREAM = "Data";
 function isDocBytes(bytes) {
 	if (!isCompoundFile(bytes)) return false;
 	let streams;
@@ -19,4 +21,4 @@ function isDocBytes(bytes) {
 	return readUint16LE(wordDocument.bytes, 0) === FIB_W_IDENT;
 }
 //#endregion
-export { SUMMARY_INFORMATION_STREAM, WORD_DOCUMENT_STREAM, isDocBytes };
+export { DATA_STREAM, SUMMARY_INFORMATION_STREAM, WORD_DOCUMENT_STREAM, isDocBytes };

package/dist/fib/fib.cjs

@@ -49,6 +49,20 @@ function parseFib(wordDocument) {
 		lcbClx: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbClx),
 		fcPlcfSed: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcfSed),
 		lcbPlcfSed: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcfSed),
+		fcPlcffndRef: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcffndRef),
+		lcbPlcffndRef: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcffndRef),
+		fcPlcffndTxt: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcffndTxt),
+		lcbPlcffndTxt: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcffndTxt),
+		fcPlcfandRef: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcfandRef),
+		lcbPlcfandRef: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcfandRef),
+		fcPlcfandTxt: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcfandTxt),
+		lcbPlcfandTxt: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcfandTxt),
+		fcPlcfendRef: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcfendRef),
+		lcbPlcfendRef: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcfendRef),
+		fcPlcfendTxt: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcfendTxt),
+		lcbPlcfendTxt: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcfendTxt),
+		fcPlcfHdd: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlcfHdd),
+		lcbPlcfHdd: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbPlcfHdd),
 		fcSttbfFfn: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcSttbfFfn),
 		lcbSttbfFfn: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.lcbSttbfFfn),
 		fcPlfLst: fcLcb(require_fib_offsets.FC_LCB_VALUE_INDEX.fcPlfLst),

package/dist/fib/fib.d.cts

@@ -1,2 +1,2 @@
-import { i as tableStreamName, n as parseFib, r as peekFibBaseFlags, t as Fib } from "../fib-DWFta19r.cjs";
+import { i as tableStreamName, n as parseFib, r as peekFibBaseFlags, t as Fib } from "../fib-6BFIx153.cjs";
 export { Fib, parseFib, peekFibBaseFlags, tableStreamName };

package/dist/fib/fib.d.ts

@@ -1,2 +1,2 @@
-import { i as tableStreamName, n as parseFib, r as peekFibBaseFlags, t as Fib } from "../fib-DWFta19r.js";
+import { i as tableStreamName, n as parseFib, r as peekFibBaseFlags, t as Fib } from "../fib-6BFIx153.js";
 export { Fib, parseFib, peekFibBaseFlags, tableStreamName };

package/dist/fib/fib.js

@@ -48,6 +48,20 @@ function parseFib(wordDocument) {
 		lcbClx: fcLcb(FC_LCB_VALUE_INDEX.lcbClx),
 		fcPlcfSed: fcLcb(FC_LCB_VALUE_INDEX.fcPlcfSed),
 		lcbPlcfSed: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcfSed),
+		fcPlcffndRef: fcLcb(FC_LCB_VALUE_INDEX.fcPlcffndRef),
+		lcbPlcffndRef: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcffndRef),
+		fcPlcffndTxt: fcLcb(FC_LCB_VALUE_INDEX.fcPlcffndTxt),
+		lcbPlcffndTxt: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcffndTxt),
+		fcPlcfandRef: fcLcb(FC_LCB_VALUE_INDEX.fcPlcfandRef),
+		lcbPlcfandRef: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcfandRef),
+		fcPlcfandTxt: fcLcb(FC_LCB_VALUE_INDEX.fcPlcfandTxt),
+		lcbPlcfandTxt: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcfandTxt),
+		fcPlcfendRef: fcLcb(FC_LCB_VALUE_INDEX.fcPlcfendRef),
+		lcbPlcfendRef: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcfendRef),
+		fcPlcfendTxt: fcLcb(FC_LCB_VALUE_INDEX.fcPlcfendTxt),
+		lcbPlcfendTxt: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcfendTxt),
+		fcPlcfHdd: fcLcb(FC_LCB_VALUE_INDEX.fcPlcfHdd),
+		lcbPlcfHdd: fcLcb(FC_LCB_VALUE_INDEX.lcbPlcfHdd),
 		fcSttbfFfn: fcLcb(FC_LCB_VALUE_INDEX.fcSttbfFfn),
 		lcbSttbfFfn: fcLcb(FC_LCB_VALUE_INDEX.lcbSttbfFfn),
 		fcPlfLst: fcLcb(FC_LCB_VALUE_INDEX.fcPlfLst),

package/dist/fib/offsets.cjs

@@ -32,8 +32,18 @@ const LW_OFFSET = {
 const FC_LCB_VALUE_INDEX = {
 	fcStshf: 2,
 	lcbStshf: 3,
+	fcPlcffndRef: 4,
+	lcbPlcffndRef: 5,
+	fcPlcffndTxt: 6,
+	lcbPlcffndTxt: 7,
+	fcPlcfandRef: 8,
+	lcbPlcfandRef: 9,
+	fcPlcfandTxt: 10,
+	lcbPlcfandTxt: 11,
 	fcPlcfSed: 12,
 	lcbPlcfSed: 13,
+	fcPlcfHdd: 22,
+	lcbPlcfHdd: 23,
 	fcPlcfBteChpx: 24,
 	lcbPlcfBteChpx: 25,
 	fcPlcfBtePapx: 26,
@@ -42,6 +52,10 @@ const FC_LCB_VALUE_INDEX = {
 	lcbSttbfFfn: 31,
 	fcClx: 66,
 	lcbClx: 67,
+	fcPlcfendRef: 92,
+	lcbPlcfendRef: 93,
+	fcPlcfendTxt: 94,
+	lcbPlcfendTxt: 95,
 	fcPlfLst: 146,
 	lcbPlfLst: 147,
 	fcPlfLfo: 148,

package/dist/fib/offsets.d.cts

@@ -31,8 +31,18 @@ declare const LW_OFFSET: {
 declare const FC_LCB_VALUE_INDEX: {
   readonly fcStshf: 2;
   readonly lcbStshf: 3;
+  readonly fcPlcffndRef: 4;
+  readonly lcbPlcffndRef: 5;
+  readonly fcPlcffndTxt: 6;
+  readonly lcbPlcffndTxt: 7;
+  readonly fcPlcfandRef: 8;
+  readonly lcbPlcfandRef: 9;
+  readonly fcPlcfandTxt: 10;
+  readonly lcbPlcfandTxt: 11;
   readonly fcPlcfSed: 12;
   readonly lcbPlcfSed: 13;
+  readonly fcPlcfHdd: 22;
+  readonly lcbPlcfHdd: 23;
   readonly fcPlcfBteChpx: 24;
   readonly lcbPlcfBteChpx: 25;
   readonly fcPlcfBtePapx: 26;
@@ -41,6 +51,10 @@ declare const FC_LCB_VALUE_INDEX: {
   readonly lcbSttbfFfn: 31;
   readonly fcClx: 66;
   readonly lcbClx: 67;
+  readonly fcPlcfendRef: 92;
+  readonly lcbPlcfendRef: 93;
+  readonly fcPlcfendTxt: 94;
+  readonly lcbPlcfendTxt: 95;
   readonly fcPlfLst: 146;
   readonly lcbPlfLst: 147;
   readonly fcPlfLfo: 148;

package/dist/fib/offsets.d.ts

@@ -31,8 +31,18 @@ declare const LW_OFFSET: {
 declare const FC_LCB_VALUE_INDEX: {
   readonly fcStshf: 2;
   readonly lcbStshf: 3;
+  readonly fcPlcffndRef: 4;
+  readonly lcbPlcffndRef: 5;
+  readonly fcPlcffndTxt: 6;
+  readonly lcbPlcffndTxt: 7;
+  readonly fcPlcfandRef: 8;
+  readonly lcbPlcfandRef: 9;
+  readonly fcPlcfandTxt: 10;
+  readonly lcbPlcfandTxt: 11;
   readonly fcPlcfSed: 12;
   readonly lcbPlcfSed: 13;
+  readonly fcPlcfHdd: 22;
+  readonly lcbPlcfHdd: 23;
   readonly fcPlcfBteChpx: 24;
   readonly lcbPlcfBteChpx: 25;
   readonly fcPlcfBtePapx: 26;
@@ -41,6 +51,10 @@ declare const FC_LCB_VALUE_INDEX: {
   readonly lcbSttbfFfn: 31;
   readonly fcClx: 66;
   readonly lcbClx: 67;
+  readonly fcPlcfendRef: 92;
+  readonly lcbPlcfendRef: 93;
+  readonly fcPlcfendTxt: 94;
+  readonly lcbPlcfendTxt: 95;
   readonly fcPlfLst: 146;
   readonly lcbPlfLst: 147;
   readonly fcPlfLfo: 148;

package/dist/fib/offsets.js

@@ -31,8 +31,18 @@ const LW_OFFSET = {
 const FC_LCB_VALUE_INDEX = {
 	fcStshf: 2,
 	lcbStshf: 3,
+	fcPlcffndRef: 4,
+	lcbPlcffndRef: 5,
+	fcPlcffndTxt: 6,
+	lcbPlcffndTxt: 7,
+	fcPlcfandRef: 8,
+	lcbPlcfandRef: 9,
+	fcPlcfandTxt: 10,
+	lcbPlcfandTxt: 11,
 	fcPlcfSed: 12,
 	lcbPlcfSed: 13,
+	fcPlcfHdd: 22,
+	lcbPlcfHdd: 23,
 	fcPlcfBteChpx: 24,
 	lcbPlcfBteChpx: 25,
 	fcPlcfBtePapx: 26,
@@ -41,6 +51,10 @@ const FC_LCB_VALUE_INDEX = {
 	lcbSttbfFfn: 31,
 	fcClx: 66,
 	lcbClx: 67,
+	fcPlcfendRef: 92,
+	lcbPlcfendRef: 93,
+	fcPlcfendTxt: 94,
+	lcbPlcfendTxt: 95,
 	fcPlfLst: 146,
 	lcbPlfLst: 147,
 	fcPlfLfo: 148,

package/dist/{fib-DWFta19r.d.cts → fib-6BFIx153.d.cts}

@@ -23,6 +23,20 @@ interface Fib {
   readonly lcbClx: number;
   readonly fcPlcfSed: number;
   readonly lcbPlcfSed: number;
+  readonly fcPlcffndRef: number;
+  readonly lcbPlcffndRef: number;
+  readonly fcPlcffndTxt: number;
+  readonly lcbPlcffndTxt: number;
+  readonly fcPlcfandRef: number;
+  readonly lcbPlcfandRef: number;
+  readonly fcPlcfandTxt: number;
+  readonly lcbPlcfandTxt: number;
+  readonly fcPlcfendRef: number;
+  readonly lcbPlcfendRef: number;
+  readonly fcPlcfendTxt: number;
+  readonly lcbPlcfendTxt: number;
+  readonly fcPlcfHdd: number;
+  readonly lcbPlcfHdd: number;
   readonly fcSttbfFfn: number;
   readonly lcbSttbfFfn: number;
   readonly fcPlfLst: number;

package/dist/{fib-DWFta19r.d.ts → fib-6BFIx153.d.ts}

@@ -23,6 +23,20 @@ interface Fib {
   readonly lcbClx: number;
   readonly fcPlcfSed: number;
   readonly lcbPlcfSed: number;
+  readonly fcPlcffndRef: number;
+  readonly lcbPlcffndRef: number;
+  readonly fcPlcffndTxt: number;
+  readonly lcbPlcffndTxt: number;
+  readonly fcPlcfandRef: number;
+  readonly lcbPlcfandRef: number;
+  readonly fcPlcfandTxt: number;
+  readonly lcbPlcfandTxt: number;
+  readonly fcPlcfendRef: number;
+  readonly lcbPlcfendRef: number;
+  readonly fcPlcfendTxt: number;
+  readonly lcbPlcfendTxt: number;
+  readonly fcPlcfHdd: number;
+  readonly lcbPlcfHdd: number;
   readonly fcSttbfFfn: number;
   readonly lcbSttbfFfn: number;
   readonly fcPlfLst: number;

package/dist/fkp-I-laf-8y.d.cts

@@ -0,0 +1,33 @@
+//#region src/prop/fkp.d.ts
+/** Every FKP is exactly one 512-byte page, whatever the compound file's own sector size. */
+declare const FKP_PAGE_SIZE = 512;
+interface ChpxFkp {
+  readonly rgfc: readonly number[];
+  /** The Chpx's grpprl for run `index`, or undefined when the run's rgb entry is zero and it carries no exception. */
+  grpprl(index: number): Uint8Array | undefined;
+}
+interface PapxRecord {
+  readonly istd: number;
+  readonly grpprl: Uint8Array;
+}
+interface PapxFkp {
+  readonly rgfc: readonly number[];
+  /** The PapxInFkp for paragraph `index`, or undefined when its BxPap.bOffset is zero and the paragraph takes the defaults. */
+  papx(index: number): PapxRecord | undefined;
+}
+declare function parseChpxFkp(page: Uint8Array): ChpxFkp;
+declare function parsePapxFkp(page: Uint8Array): PapxFkp;
+interface PapxLookup extends PapxRecord {
+  /** The byte offset one past the end of the paragraph this record covers -- PapxFkp.rgfc[k + 1], the paragraph boundary [MS-DOC] 2.4.2 derives its own from. */
+  readonly fcLim: number;
+}
+declare class PropertyBinTable {
+  #private;
+  constructor(wordDocument: Uint8Array, plc: Uint8Array, what: string);
+  /** The direct character-formatting grpprl covering `fc`, or undefined when the offset is outside the table or its run carries no exception. */
+  chpxGrpprl(fc: number): Uint8Array | undefined;
+  /** The direct paragraph-formatting record covering `fc`, or undefined when the offset is outside the table or its paragraph carries no exception. */
+  papx(fc: number): PapxLookup | undefined;
+}
+//#endregion
+export { PapxRecord as a, parsePapxFkp as c, PapxLookup as i, FKP_PAGE_SIZE as n, PropertyBinTable as o, PapxFkp as r, parseChpxFkp as s, ChpxFkp as t };

package/dist/fkp-I-laf-8y.d.ts

@@ -0,0 +1,33 @@
+//#region src/prop/fkp.d.ts
+/** Every FKP is exactly one 512-byte page, whatever the compound file's own sector size. */
+declare const FKP_PAGE_SIZE = 512;
+interface ChpxFkp {
+  readonly rgfc: readonly number[];
+  /** The Chpx's grpprl for run `index`, or undefined when the run's rgb entry is zero and it carries no exception. */
+  grpprl(index: number): Uint8Array | undefined;
+}
+interface PapxRecord {
+  readonly istd: number;
+  readonly grpprl: Uint8Array;
+}
+interface PapxFkp {
+  readonly rgfc: readonly number[];
+  /** The PapxInFkp for paragraph `index`, or undefined when its BxPap.bOffset is zero and the paragraph takes the defaults. */
+  papx(index: number): PapxRecord | undefined;
+}
+declare function parseChpxFkp(page: Uint8Array): ChpxFkp;
+declare function parsePapxFkp(page: Uint8Array): PapxFkp;
+interface PapxLookup extends PapxRecord {
+  /** The byte offset one past the end of the paragraph this record covers -- PapxFkp.rgfc[k + 1], the paragraph boundary [MS-DOC] 2.4.2 derives its own from. */
+  readonly fcLim: number;
+}
+declare class PropertyBinTable {
+  #private;
+  constructor(wordDocument: Uint8Array, plc: Uint8Array, what: string);
+  /** The direct character-formatting grpprl covering `fc`, or undefined when the offset is outside the table or its run carries no exception. */
+  chpxGrpprl(fc: number): Uint8Array | undefined;
+  /** The direct paragraph-formatting record covering `fc`, or undefined when the offset is outside the table or its paragraph carries no exception. */
+  papx(fc: number): PapxLookup | undefined;
+}
+//#endregion
+export { PapxRecord as a, parsePapxFkp as c, PapxLookup as i, FKP_PAGE_SIZE as n, PropertyBinTable as o, PapxFkp as r, parseChpxFkp as s, ChpxFkp as t };