Add .doc (Word Binary File Format) read+write support

[Mearman]

Add read+write support for .doc, the Word Binary File Format, as defined by [MS-DOC]. The document's FIB (File Information Block), piece table, and associated streams live inside an [MS-CFB] compound file — archive-codec's existing CFB reader already gets a codec to the raw stream bytes; parsing the binary structure itself (and mapping it to/from the shared document-schema.js content schema, matching how ooxml.js's docx support and odf.js's odt support both target the same schema) is the actual work.

Part of #85. [MS-DOC] is one of the two largest specs in this family (~1,200 pages) and was the primary reason the original assessment called the whole group out of scope.

[Mearman]

Opened #845 with a read path for this. Leaving the issue open — it's read-only, and it doesn't read everything.

Rough map of the format for whoever picks up the rest, since the ~1,200 pages hide where the actual difficulty is. It isn't spread evenly: three structures carry nearly all of it, and once those are right the rest is mostly a long list of opcodes.

The FIB is easier than it looks. FibBase is a fixed 32 bytes at offset 0 of the WordDocument stream, then csw+FibRgW97 (28 bytes), cslw+FibRgLw97 (88 bytes), then cbRgFcLcb and the FibRgFcLcb97 blob at absolute offset 154. That blob is a flat array of 4-byte values, so a pair's offset is just its ordinal times 4 — fcClx is value index 66, i.e. blob offset 264, absolute 418. csw and cslw are fixed by the spec for every nFib, which is what makes those constants safe to precompute. Two flags in the FibBase bit field at offset 10 matter more than the rest: fEncrypted (0x0100) and fWhichTblStm (0x0200), which says whether every fc offset is into 1Table or 0Table.

The piece table is where a wrong reader stops failing and starts corrupting. fcClx/lcbClx point at a Clx in the Table stream: zero or more Prcs (each 0x01, a signed 2-byte cbGrpprl, then that many bytes) followed by a Pcdt (0x02, a 4-byte lcb, then a PlcPcd of that size). The PlcPcd is a standard PLC — n+1 four-byte CPs then n 8-byte Pcds, with n derived from the size by (cbPlc - 4) / 12.

Each Pcd's 4-byte FcCompressed is the thing to get right. Low 30 bits are a byte offset, bit 30 is fCompressed. Clear: 16-bit characters starting at fc, two bytes each. Set: 8-bit characters starting at fc / 2, one byte each, with ~24 byte values remapped by a table in the FcCompressed section (it is not Windows-1252 — it omits 0x80, 0x8E, 0x9D, 0x9E). Miss the halving and you get real text from the wrong place in the stream, which no assertion catches.

Sections worth reading in full rather than skimming: Retrieving Text (2.4.1) gives the CP→byte algorithm step by step, and Example of a Clx (2.9.6) gives a complete worked example with real hex — a 0x2D-byte Clx, CPs 0/6/13/14, three pieces, one uncompressed at 0x0C22 and two compressed, assembling to "Hello World." plus two paragraph marks. Reproducing that example verbatim is the single best check available without a corpus, and #845 uses it as a test.

CHPX/PAPX is mechanical but full of traps. fcPlcfBteChpx/fcPlcfBtePapx point at PLCs whose keys are byte offsets (not CPs) and whose 4-byte elements are page numbers — low 22 bits, multiplied by 512 to get the FKP page's offset in WordDocument. In each 512-byte page: the element count is the last byte (offset 511), the rgfc array of count+1 offsets is at the front, and the per-element offsets to the actual records are stored halved, with zero meaning "no exception, use defaults" rather than "offset zero".

PapxFkp adds one more. Its rgbx entries are 13-byte BxPaps (a bOffset byte plus a 12-byte PHE you can ignore), and the PapxInFkp at bOffset * 2 has two length spellings: cb != 0 means the payload is 2*cb - 1 bytes, cb == 0 means the next byte cb' gives 2*cb' bytes. Two things about that caught me out — the payload is the GrpPrlAndIstd, i.e. the 2-byte style index and the grpprl, so treating it as the grpprl's length makes you parse the istd as the first sprm of every paragraph; and which spelling is used is decided by parity, not by size (one form is always odd, the other always even), which the worked example in the PapxInFkp section demonstrates.

Then Sprm: ispmd bits 0-8, fSpec 9, sgc 10-12, spra 13-15, and spra alone sizes the operand (0/1 → 1 byte, 2/4/5 → 2, 3 → 4, 7 → 3, 6 → variable). Nothing marks where one Prl ends, so a single wrong size desynchronises the whole grpprl. spra 6's "first byte is the length" rule has two named exceptions: sprmTDefTable (0xD608) has a 2-byte cb counting the remainder incremented by 1, and sprmPChgTabs (0xC615) uses 255 as a sentinel meaning "compute the length from the tab-stop counts inside". #845 refuses the sentinel rather than guess.

One useful shortcut for headings: sprmPIstd's own text says an istd of 1 through 9 is the outline level (minus one), so you get heading levels without touching style names, which may be renamed or localised.

Where I'd start next, roughly in value order:

1. A real-world corpus. Everything in feat(doc-codec): add a hand-written [MS-DOC] reader #845 is tested against the spec's field tables, which proves conformance to the document, not to what Word actually wrote. This is the biggest gap and it blocks confidence in everything else.
2. Tables (2.4.3 Overview of Tables). The mechanism is already half-exposed — sprmPFInTable (0x2416) and sprmPFTtp (0x2417) are parsed, cell marks (0x07) are recognised — it just needs the row/cell grouping and sprmTDefTable decoding to build a real ContentTable.
3. Style-inherited formatting. Style names are read; the property sets in the STD's grLPUpxSw are not, so a Heading 1 paragraph reports its style but not the formatting the style supplies. Needs the UpxPapx/UpxChpx shapes plus walking the istdBase chain.
4. Section properties (PlcfSed/Sepx) for real page geometry — currently a US Letter placeholder.
5. Subdocuments. Cheap, given the above: they're just further CP ranges after ccpText, laid out in FibRgLw97's own field order.
6. Writing. Genuinely a separate project, and I'd want 1-5 plus a corpus first.

Sources, all Microsoft Open Specifications:

• [MS-DOC] index
• Fib / FibBase / FibRgLw97 / FibRgFcLcb97
• Retrieving Text / Determining Paragraph Boundaries
• Clx / PlcPcd / Pcd / FcCompressed / Example of a Clx
• PLC / PlcBteChpx / PlcBtePapx / ChpxFkp / PapxFkp / BxPap / PapxInFkp
• Sprm / Single Property Modifiers / Character Properties / Paragraph Properties / Table Properties
• STSH / Stshif / StdfBase
• [MS-CFB] for the container, which archive-codec already handles.

[Mearman]

Partial write support landed in #876: a genuine [MS-DOC] structure writer (piece table, sprm-encoded formatting exceptions, style sheet, font table), producing real Word Binary File bytes via archive-codec's CFB writer. Character formatting (bold/italic/strike/underline/size/colour/font family) and paragraph formatting (alignment/indent/spacing/line-spacing/page-break-before) round-trip, verified both against this package's own reader and independently against LibreOffice.

Still open: tables, images, paragraph styles, numbering/lists, hyperlinks/fields, footnotes/headers/comments, section geometry beyond one section, and metadata -- each refused by name (DocUnsupportedError) rather than silently dropped or approximated. Full scope and rationale are in packages/doc-codec/README.md's "Writing" section.

[Mearman]

doc-codec is now reachable through documents.js's own conversion engine: convertDocument("doc", "pdf", ...)/pdfToDoc/docToPdf and every same-variant wordprocessing bridge documents.js already supports (PR #881). document-cli/the web UI gained read-only PDF-preview support for the same reason. Still open: the codec's own scope gaps listed above (tables, images, styles, numbering, metadata), and no live TUI editor.

[Mearman]

doc-codec now reads and writes real document metadata via the same shared [MS-OLEPS] SummaryInformation support (PR #887).