feat(xls-codec): read and write a sheet's real print settings

README.md

@@ -41,7 +41,7 @@ Each converts one document format to and from the shared schema, built on `docum
 | [`rtf-codec`](packages/rtf-codec/README.md)           | Rich Text Format to and from the shared content schema; hand-written tokenizer, destination state machine, and header-table parsers, since RTF is tokenised text rather than XML.                                                                                                                                                                                                            |
 | [`wpd-codec`](packages/wpd-codec/README.md)           | WordPerfect 6.x-X6 (`.wpd`) to the shared content schema; read-only, and under active development.                                                                                                                                                                                                                                                                                           |
 | [`doc-codec`](packages/doc-codec/README.md)           | The pre-2007 Word Binary File Format (`.doc`, [MS-DOC]) to and from the shared content schema, also depending on `archive-codec` for its [MS-CFB] container; write support covers character/paragraph formatting, tables over a single section, cell decoration, and metadata, with images, style-inherited formatting, and numbering still read-only gaps — see the package's own README for its exact scope. |
-| [`xls-codec`](packages/xls-codec/README.md)           | Legacy Excel Binary File Format (`.xls`, BIFF8) to and from the shared content schema, also depending on `archive-codec` for its [MS-CFB] container; write support covers cell values, merges, row/column sizing, number formats, and cell background/border decoration, with formulas and print settings still read-only gaps — see the package's own README for its exact scope.           |
+| [`xls-codec`](packages/xls-codec/README.md)           | Legacy Excel Binary File Format (`.xls`, BIFF8) to and from the shared content schema, also depending on `archive-codec` for its [MS-CFB] container; write support covers cell values, merges, row/column sizing, number formats, cell background/border decoration, and print settings, with formulas still a read-only gap — see the package's own README for its exact scope.             |
 | [`ppt-codec`](packages/ppt-codec/README.md)           | PowerPoint 97-2003 binary presentations (`.ppt`, [MS-PPT]) to and from the shared content schema, also depending on `archive-codec` for its [MS-CFB] container; the write side covers plain text-box slides only, and both directions remain under active development.                                                                                                                       |
 
 ### Conversion engine

packages/documents.js/README.md

@@ -969,7 +969,7 @@ Read as **row → column**. `✓` lossless, `~` bounded, `✗` lossy, `✗✗` s
 
 **`doc`'s own bridges lose far more than `rtf`'s did, and its writer refuses rather than approximates a genuine construct kind.** doc-codec's reader (see that package's own [Status](../doc-codec/README.md#status)) reads real tables (row/column/cell structure, horizontal and vertical merge) but still drops images, style-inherited formatting, subdocuments, every section beyond the first, numbering definitions, metadata, and hyperlinks/fields — a much narrower read than docx/odt offer, so every `doc → X` cell in this table stays `✗` regardless of `X`'s own richness: that content is already gone before any target is reached, tables now surviving the crossing notwithstanding. Going the other way, `writeDocContent` writes a `ContentTable` (a table nested inside a table cell is the one genuine table-shaped refusal, alongside cell shading/borders it silently does not carry — see doc-codec's own [Tables](../doc-codec/README.md#tables) section) but still does not approximate an image or a section beyond the first — it throws `DocUnsupportedError` rather than dropping or flattening either. Every `X → doc` cell where `X`'s own content can genuinely carry an image (`docx`, `odt`, `markdown`, `rtf`, and anything reconstructed with one via a PDF pivot) stays rated `✗` on the same basis as every other `doc` cell, and for those sources that direction can still mean the conversion fails outright for a real document rather than merely losing formatting — there is no partial write for a document containing an image, though a table alone no longer forces that failure.
 
-**`xls`'s writer never touches formulas, cell decoration, images, or anything print/metadata-related**, so `xls⇄xlsx`/`xls⇄ods` are rated `✗` rather than the `~` their full-featured `xlsx⇄ods` counterpart earns: a real workbook's formulas and fill/border/font decoration are silently dropped in both directions (neither is ever read by xls-codec, so neither can be written back either — see that package's own [Writer scope](../xls-codec/README.md#writer-scope) and [Read-side gaps](../xls-codec/README.md#read-side-gaps)), a materially bigger gap than `xlsx⇄ods`'s own "small format-boundary limits" (time cells, formula dialects). `csv⇄xls` is the one `xls` pair that escapes this downgrade: csv can carry neither formulas nor decoration to begin with, so it loses nothing crossing into `xls` that it would not also lose crossing into `xlsx`/`ods` — `csv → xls` is `✓`, matching `csv → xlsx`/`csv → ods`, and `xls → csv` is `~`, matching `xlsx → csv`, since csv always collapses a cell to its `displayText` regardless of how rich the source was. `xls⇄markdown` needs the identical extra `ods`-bridge hop before the same PDF pivot that already earns `xlsx⇄markdown`/`csv⇄markdown` their `✗✗` — so `xls⇄markdown` is `✗✗` too, for the same reason. A `.xls` cell grid outside BIFF8's own 65536-row/256-column limit is refused outright, the one write-side hard stop `xls-codec` shares with `doc-codec`'s own refusals.
+**`xls`'s writer never touches formulas, per-cell fonts, cell alignment, or images**, so `xls⇄xlsx`/`xls⇄ods` are rated `✗` rather than the `~` their full-featured `xlsx⇄ods` counterpart earns: a real workbook's formulas and per-cell font are silently dropped in both directions (neither is ever read by xls-codec, so neither can be written back either — see that package's own [Writer scope](../xls-codec/README.md#writer-scope) and [Read-side gaps](../xls-codec/README.md#read-side-gaps)), a materially bigger gap than `xlsx⇄ods`'s own "small format-boundary limits" (time cells, formula dialects). A cell's background fill and per-side borders, a sheet's print settings, and the workbook's own metadata do all survive the crossing — each is read and written for real by xls-codec — so the downgrade rests on formulas and font alone. `csv⇄xls` is the one `xls` pair that escapes this downgrade: csv can carry neither formulas nor per-cell fonts to begin with, so it loses nothing crossing into `xls` that it would not also lose crossing into `xlsx`/`ods` — `csv → xls` is `✓`, matching `csv → xlsx`/`csv → ods`, and `xls → csv` is `~`, matching `xlsx → csv`, since csv always collapses a cell to its `displayText` regardless of how rich the source was. `xls⇄markdown` needs the identical extra `ods`-bridge hop before the same PDF pivot that already earns `xlsx⇄markdown`/`csv⇄markdown` their `✗✗` — so `xls⇄markdown` is `✗✗` too, for the same reason. A `.xls` cell grid outside BIFF8's own 65536-row/256-column limit is refused outright, the one write-side hard stop `xls-codec` shares with `doc-codec`'s own refusals.
 
 **`ppt`'s writer drops what it can't express instead of throwing**, unlike `doc`'s: an image, table, or OLE-embedded shape is silently excluded from the written text body rather than refusing the whole conversion (see that package's own [Writing a document](../ppt-codec/README.md#writing-a-document)) — genuinely gentler failure behaviour than `doc`'s hard stop, but the loss itself is just as real, so `ppt` cells are rated `✗` on the same basis as `doc`'s rather than upgraded for failing more softly. `ppt`'s reader is narrower again than `pptx`'s own: only plain text-box shapes with basic character formatting come back at all — no images, tables, OLE objects, masters, layouts, scheme colours, or per-shape insets (see that package's own [What it does not read yet](../ppt-codec/README.md#what-it-does-not-read-yet)) — so every `ppt → X` cell already reflects that ceiling before `X`'s own capacity ever matters.