js.documents 7.1.6 → 7.1.8

package/README.md

@@ -2,7 +2,7 @@
 
 [![GitHub](https://img.shields.io/badge/GitHub-181717?logo=github&logoColor=white)](https://github.com/ExaDev/documents.js/tree/main/packages/documents.js) [![npm](https://img.shields.io/badge/npm-CB3837?logo=npm&logoColor=white)](https://www.npmjs.com/package/documents.js) [![npm version](https://img.shields.io/npm/v/documents.js)](https://www.npmjs.com/package/documents.js) [![CI](https://img.shields.io/github/actions/workflow/status/ExaDev/documents.js/ci.yml?branch=main)](https://github.com/ExaDev/documents.js/actions)
 
-> Converts between any two compatible document formats through a shared content/layout pivot. docx, pptx, odt, odp, ods, odg, xlsx, csv (TSV is the same format with a tab delimiter), svg, markdown, rtf, and the three legacy binary formats doc/xls/ppt ([MS-DOC], BIFF8, [MS-PPT], each wrapped in an [MS-CFB] compound file) all read into and build from the same shared `ContentDocument` model (reported to callers as the tree-form `DocumentTree`), with PDF — reached through pdf-codec's own `LayoutDocument` view — as the one format every variant can reach; wpd (WordPerfect 6.x-X6) reads into the same wordprocessing variant as a read-only source, routable everywhere the others are but never buildable as a target, since wpd-codec ships no writer. A composition engine (`convertDocument`) routes 208 (source, target) pairs across the fifteen content formats and PDF, including twenty-eight PDF-pivot round trips (the eight layout-engine formats, plus xlsx/csv/xls composing through ods, and rtf/doc composing through docx/odt/markdown and ppt composing through pptx/odp), twenty-four cross-format bridge functions (same-variant direct copies, cross-variant semantic transforms, and PDF-composed), fifteen one-way wpd-sourced routes, plus special-case conversions for `.odm` master documents, `.odb` database front-ends (HSQLDB and Firebird, four storage tiers), standalone `.odf` formula documents, and a bounded SQL/rpt-formula engine for `.odb` reports. Also includes: read-and-write live-view editors for all six editable formats, docx comment/footnote/header-footer exposure via `readDocxExtras`, real font resolution (source-embedded faces ahead of caller-supplied, vendored substitutes, and the standard 14), a hand-written MathML typesetting engine with embedded-font PDF rendering and a matching MathML ⇄ OMML translator, LaTeX lowering into the schema's two-layer semantic math core (pinned temml parser, symbol tables from prose, a coherence lint), and a fully hand-written PDF codec. Built on [ooxml.js](../ooxml.js/README.md), [odf.js](../odf.js/README.md), [pdf-codec](../pdf-codec/README.md), [markdown-codec](../markdown-codec/README.md), [rtf-codec](../rtf-codec/README.md), [wpd-codec](../wpd-codec/README.md), [doc-codec](../doc-codec/README.md), [xls-codec](../xls-codec/README.md), [ppt-codec](../ppt-codec/README.md), [archive-codec](../archive-codec/README.md), and [document-schema.js](../document-schema.js/README.md).
+> Converts between any two compatible document formats through a shared content/layout pivot. docx, pptx, odt, odp, ods, odg, xlsx, csv (TSV is the same format with a tab delimiter), svg, markdown, rtf, and the three legacy binary formats doc/xls/ppt ([MS-DOC], BIFF8, [MS-PPT], each wrapped in an [MS-CFB] compound file) all read into and build from the same shared `ContentDocument` model (reported to callers as the tree-form `DocumentTree`), with PDF — reached through pdf-codec's own `LayoutDocument` view — as the one format every variant can reach; wpd (WordPerfect 6.x-X6) reads into the same wordprocessing variant as a read-only source, routable everywhere the others are but never buildable as a target, since wpd-codec ships no writer. A composition engine (`convertDocument`) routes 217 (source, target) pairs across the fifteen content formats and PDF, including twenty-eight PDF-pivot round trips (the eight layout-engine formats, plus xlsx/csv/xls composing through ods, and rtf/doc composing through docx/odt/markdown and ppt composing through pptx/odp), twenty-four cross-format bridge functions (same-variant direct copies, cross-variant semantic transforms, and PDF-composed — two of which, `xlsxToMarkdown`/`csvToMarkdown`, became one-directional cross-variant transforms in their own right when [ExaDev/documents.js#1043](https://github.com/ExaDev/documents.js/issues/1043) registered `spreadsheetToWordprocessing`), fifteen one-way wpd-sourced routes, plus special-case conversions for `.odm` master documents, `.odb` database front-ends (HSQLDB and Firebird, four storage tiers), standalone `.odf` formula documents, and a bounded SQL/rpt-formula engine for `.odb` reports. Also includes: read-and-write live-view editors for all six editable formats, docx comment/footnote/header-footer exposure via `readDocxExtras`, real font resolution (source-embedded faces ahead of caller-supplied, vendored substitutes, and the standard 14), a hand-written MathML typesetting engine with embedded-font PDF rendering and a matching MathML ⇄ OMML translator, LaTeX lowering into the schema's two-layer semantic math core (pinned temml parser, symbol tables from prose, a coherence lint), and a fully hand-written PDF codec. Built on [ooxml.js](../ooxml.js/README.md), [odf.js](../odf.js/README.md), [pdf-codec](../pdf-codec/README.md), [markdown-codec](../markdown-codec/README.md), [rtf-codec](../rtf-codec/README.md), [wpd-codec](../wpd-codec/README.md), [doc-codec](../doc-codec/README.md), [xls-codec](../xls-codec/README.md), [ppt-codec](../ppt-codec/README.md), [archive-codec](../archive-codec/README.md), and [document-schema.js](../document-schema.js/README.md).
 
 `documents.js` extends `ooxml.js` in two directions `ooxml.js` deliberately does not cover: full PDF support (parsing and generating, via `pdf-codec`), and a read-**and-write** manipulation API for docx/pptx content — `ooxml.js`'s own typed readers are one-way. The PDF codec is hand-written against ISO 32000-1, with no external PDF library as a dependency — see [Fidelity](#fidelity) and pdf-codec's own README for the honest trade-off (not as robust against adversarial PDFs as a 15+-year-hardened library; fully auditable and dependency-free instead). `src/mathml/` (the MathML typesetting engine) stays in this package and is hand-written too, for the same supply-chain reason. The one deliberate exception on the math side is the LaTeX parser: `src/latex/` lowers LaTeX into the schema's semantic core over a pinned exact-version [temml](https://temml.org) dependency — see [LaTeX lowering into the semantic core](#latex-lowering-into-the-semantic-core) for why a LaTeX grammar is the one component not worth hand-writing and what the pin guarantees.
 
@@ -98,7 +98,7 @@ npm install documents.js document-schema.js
 
 ### The generic entry point: `convertDocument`
 
-A single function, `convertDocument`, sits behind every named conversion and reaches every pair the composition engine can route — all 208 supported (source, target) combinations. The named functions below are thin one-line forwarders to it; they remain the ergonomic layer for a caller who wants a fixed pair and autocomplete discovery, while `convertDocument` is the first-class entry point for a caller working from a runtime format pair (CLI, MCP tool, matrix enumeration).
+A single function, `convertDocument`, sits behind every named conversion and reaches every pair the composition engine can route — all 217 supported (source, target) combinations. The named functions below are thin one-line forwarders to it; they remain the ergonomic layer for a caller who wants a fixed pair and autocomplete discovery, while `convertDocument` is the first-class entry point for a caller working from a runtime format pair (CLI, MCP tool, matrix enumeration).
 
 ```ts
 import { convertDocument } from "documents.js";
@@ -200,7 +200,7 @@ Each accepts an optional `signal` (`AbortSignal`) and either `onSubstitution` (X
 
 ### Cross-format bridges
 
-Twenty-four bridge functions across twelve pairs bypass the PDF pivot where a direct path exists. Eight same-variant direct-copy pairs (`odtToDocx`/`docxToOdt`, `odpToPptx`/`pptxToOdp`, `odsToXlsx`/`xlsxToOds`, `csvToOds`/`odsToCsv`, `csvToXlsx`/`xlsxToCsv`, `svgToOdg`/`odgToSvg`, `markdownToDocx`/`docxToMarkdown`, `markdownToOdt`/`odtToMarkdown`) compose a direct `readXContent` → `buildYPackage` pivot copy — the csv pairs are one hop to its spreadsheet siblings, so csv never needs PDF to reach ods or xlsx, and `svgToOdg`/`odgToSvg` bridge svg to its drawing sibling odg the same way. Two cross-variant semantic-transform pairs (`docxToPptx`/`pptxToDocx`, `odtToOdp`/`odpToOdt`) go through `src/convert/variant-bridges.ts`. Two PDF-composed pairs (`xlsxToMarkdown`/`markdownToXlsx`, `csvToMarkdown`/`markdownToCsv`) route through PDF internally — the lossiest conversions in the package.
+Twenty-two bridge functions genuinely bypass the PDF pivot where a direct path exists. Eight same-variant direct-copy pairs (`odtToDocx`/`docxToOdt`, `odpToPptx`/`pptxToOdp`, `odsToXlsx`/`xlsxToOds`, `csvToOds`/`odsToCsv`, `csvToXlsx`/`xlsxToCsv`, `svgToOdg`/`odgToSvg`, `markdownToDocx`/`docxToMarkdown`, `markdownToOdt`/`odtToMarkdown`) compose a direct `readXContent` → `buildYPackage` pivot copy — the csv pairs are one hop to its spreadsheet siblings, so csv never needs PDF to reach ods or xlsx, and `svgToOdg`/`odgToSvg` bridge svg to its drawing sibling odg the same way. Two cross-variant semantic-transform pairs (`docxToPptx`/`pptxToDocx`, `odtToOdp`/`odpToOdt`) go through `src/convert/variant-bridges.ts`. `xlsxToMarkdown` and `csvToMarkdown` join them as two one-directional cross-variant transforms since [ExaDev/documents.js#1043](https://github.com/ExaDev/documents.js/issues/1043) registered `spreadsheetToWordprocessing` (also in `variant-bridges.ts`): their own reverse direction (`markdownToXlsx`/`markdownToCsv`) has no transform to take instead, so those two still route through PDF internally, since a markdown table has no cell types, formulas, or geometry of its own to recover — the lossiest conversions left in the package.
 
 ```ts
 import {
@@ -233,7 +233,7 @@ const { document, diagnostics } = await converter.convert(
 );
 ```
 
-`DocumentFormat` includes `docx`/`pptx`/`xlsx`/`odt`/`odp`/`ods`/`odg`/`svg`/`odf`/`csv`/`markdown`/`rtf`/`doc`/`xls`/`ppt`/`wpd`/`pdf` — seventeen members, `wpd` the one read-only member: it appears as a source in `conversions` but never as a target, since wpd-codec ships no writer. The port's `conversions` list is derived from `resolveCompositionPlan` plus the `odf`→`pdf` special case — 208 pairs total. `DocumentFormat` is inferred from `DocumentFormatSchema` (a real Zod schema); `DOCUMENT_FORMATS` is exported as a plain array derived from the same schema:
+`DocumentFormat` includes `docx`/`pptx`/`xlsx`/`odt`/`odp`/`ods`/`odg`/`svg`/`odf`/`csv`/`markdown`/`rtf`/`doc`/`xls`/`ppt`/`wpd`/`pdf` — seventeen members, `wpd` the one read-only member: it appears as a source in `conversions` but never as a target, since wpd-codec ships no writer. The port's `conversions` list is derived from `resolveCompositionPlan` plus the `odf`→`pdf` special case — 217 pairs total. `DocumentFormat` is inferred from `DocumentFormatSchema` (a real Zod schema); `DOCUMENT_FORMATS` is exported as a plain array derived from the same schema:
 
 The port also exposes `contractVersion: number`, bumped only when `DocumentConverter`'s own contract shape changes — a new field on `ConversionResult` a caller might need to branch on, or a new `ConversionOptions` field an implementation is now expected to honour — never when the `conversions` table simply grows with more supported source/target pairs (that's discoverable at runtime via `conversions` itself). It is currently `7`: the bump from `6` reflects `ConversionResult.package` changing type to the tree-form `DocumentTree` described below, which a caller reading that field must now flatten rather than read directly.
 
@@ -542,7 +542,7 @@ const layout = readPdf(pdfBytes); // -> LayoutDocument: pages of positioned text
 const bytes = writePdf(layout);
 ```
 
-The fifteen PDF round trips and sixteen PDF-bypassing bridge directions are also available as schema-validated [`z.codec()`](https://zod.dev) pairs (`pdfCodec`, `docxPdfCodec`, `pptxPdfCodec`, `odtPdfCodec`, `odpPdfCodec`, `odsPdfCodec`, `odgPdfCodec`, `svgPdfCodec`, `xlsxPdfCodec`, `csvPdfCodec`, `markdownPdfCodec`, `rtfPdfCodec`, `docPdfCodec`, `xlsPdfCodec`, `pptPdfCodec`, `odtDocxCodec`, `odpPptxCodec`, `odsXlsxCodec`, `odsCsvCodec`, `xlsxCsvCodec`, `odgSvgCodec`, `markdownDocxCodec`, `markdownOdtCodec`) — the no-options form, adding automatic two-way schema validation. The two PDF-composed pairs have codec forms too (`xlsxMarkdownCodec`, `csvMarkdownCodec`):
+The fifteen PDF round trips and sixteen PDF-bypassing bridge directions are also available as schema-validated [`z.codec()`](https://zod.dev) pairs (`pdfCodec`, `docxPdfCodec`, `pptxPdfCodec`, `odtPdfCodec`, `odpPdfCodec`, `odsPdfCodec`, `odgPdfCodec`, `svgPdfCodec`, `xlsxPdfCodec`, `csvPdfCodec`, `markdownPdfCodec`, `rtfPdfCodec`, `docPdfCodec`, `xlsPdfCodec`, `pptPdfCodec`, `odtDocxCodec`, `odpPptxCodec`, `odsXlsxCodec`, `odsCsvCodec`, `xlsxCsvCodec`, `odgSvgCodec`, `markdownDocxCodec`, `markdownOdtCodec`) — the no-options form, adding automatic two-way schema validation. The two asymmetric pairs above have codec forms too (`xlsxMarkdownCodec`, `csvMarkdownCodec`) — decode is now `spreadsheetToWordprocessing`'s direct cross-variant transform, encode still composes through PDF:
 
 ```ts
 import { z } from "zod";
@@ -930,29 +930,31 @@ To run a single test file: `pnpm vitest run src/path/to/file.test.ts`.
 
 ## Fidelity
 
-Read as **row → column**. `✓` lossless, `~` bounded, `✗` lossy, `✗✗` severe, `→` one-way, `–` no conversion. `.odm`/`.odb` sit outside this table. `rtf` is wired into the composition engine and bidirectionally routable to every other format here except `csv`/`xlsx` (one hop past the pathfinder's own 3-hop cap) and `odf` (excluded from routing entirely — see below). `wpd` is wired in as a read-only source (see composition.ts's own `ReadOnlyContentFormat`): routable to every other format here except `odf`, exactly like `rtf`'s reach, but every one of its cells is `→` rather than a fidelity grade, since a read-only format has no reverse direction to compare against and no column of its own — nothing ever routes to `wpd`, wpd-codec having no writer at all. Every cell below is derived from `resolveCompositionPlan`'s actual resolved route for that pair (hop count and hop kind — same-variant bridge, cross-variant transform, or PDF pivot), not hand-reasoned: the pathfinder generates the full cross-product of same-variant and cross-variant-transform edges, so a pair can be routable even with no named convenience function for it (e.g. `odp → docx`, `odt → pptx`). `doc`/`xls`/`ppt` (the three legacy binary formats — see doc-codec/xls-codec/ppt-codec's own READMEs for exactly what each reads/writes) are wired into the composition engine too, and bidirectionally routable to most of the formats here (`doc` reaches everything except `csv`/`xlsx`/`xls`; `xls` reaches everything except `doc`/`ppt`/`rtf`; `ppt` reaches everything except `csv`/`xlsx`/`xls`, each the identical one-hop-too-many gap `rtf`'s own `csv`/`xlsx` pair already has, for the same reason — none of the three has a toPdf/fromPdf edge of its own) — like the `rtf` extension before them (ExaDev/documents.js#853), all three now carry a real per-pair fidelity audit in the table below ([ExaDev/documents.js#880](https://github.com/ExaDev/documents.js/issues/880)), checked the same way: every `doc`/`xls`/`ppt` cell is verified against `resolveCompositionPlan`'s actual resolved route for that pair plus that codec's own documented read/write scope, not guessed from the hop shape alone.
+Read as **row → column**. `✓` lossless, `~` bounded, `✗` lossy, `✗✗` severe, `→` one-way, `–` no conversion. `.odm`/`.odb` sit outside this table. `rtf` is wired into the composition engine and bidirectionally routable to every other format here except as a source reaching `csv`/`xlsx` (`rtf → csv`/`rtf → xlsx`, one hop past the pathfinder's own 3-hop cap) and `odf` (excluded from routing entirely — see below); the reverse `csv → rtf`/`xlsx → rtf` routes since [ExaDev/documents.js#1043](https://github.com/ExaDev/documents.js/issues/1043) registered a one-way spreadsheet → wordprocessing transform (see below). `wpd` is wired in as a read-only source (see composition.ts's own `ReadOnlyContentFormat`): routable to every other format here except `odf`, exactly like `rtf`'s reach, but every one of its cells is `→` rather than a fidelity grade, since a read-only format has no reverse direction to compare against and no column of its own — nothing ever routes to `wpd`, wpd-codec having no writer at all. Every cell below is derived from `resolveCompositionPlan`'s actual resolved route for that pair (hop count and hop kind — same-variant bridge, cross-variant transform, or PDF pivot), not hand-reasoned: the pathfinder generates the full cross-product of same-variant and cross-variant-transform edges, so a pair can be routable even with no named convenience function for it (e.g. `odp → docx`, `odt → pptx`). `doc`/`xls`/`ppt` (the three legacy binary formats — see doc-codec/xls-codec/ppt-codec's own READMEs for exactly what each reads/writes) are wired into the composition engine too, and bidirectionally routable to most of the formats here — `doc` reaches everything except, as a source, `csv`/`xlsx`/`xls`; `xls` reaches everything except, as a source, `rtf`/`ppt` (the identical one-hop-too-many gap `rtf`'s own `csv`/`xlsx` pair has, for the same reason — none of the three has a toPdf/fromPdf edge of its own); `ppt` reaches everything except, as a source, `csv`/`xlsx`/`xls` — like the `rtf` extension before them (ExaDev/documents.js#853), all three now carry a real per-pair fidelity audit in the table below ([ExaDev/documents.js#880](https://github.com/ExaDev/documents.js/issues/880)), checked the same way: every `doc`/`xls`/`ppt` cell is verified against `resolveCompositionPlan`'s actual resolved route for that pair plus that codec's own documented read/write scope, not guessed from the hop shape alone.
+
+**Since [ExaDev/documents.js#1043](https://github.com/ExaDev/documents.js/issues/1043)**, `spreadsheetToWordprocessing` (`src/convert/variant-bridges.ts`) registers a one-way spreadsheet → wordprocessing content transform: `csv`/`ods`/`xls`/`xlsx` reach `docx`/`odt`/`markdown`/`rtf`/`doc` directly as a single cross-variant bridge hop (each sheet becomes an H2-headed section plus one table, hidden rows/columns excluded — formulas, print settings, comments, and anchored images/embedded objects have no wordprocessing counterpart and are silently out of scope), and reach `pptx`/`odp`/`ppt` through that same bridge plus the existing wordprocessing → presentation transform (two bridge hops). The reverse direction has no registered transform — a wordprocessing/presentation table has no cell types, formulas, or geometry of its own to recover into a spreadsheet — so every column-side cell for `xlsx`/`ods`/`csv`/`xls` (a wordprocessing/presentation format converting into a spreadsheet) is unaffected by this change.
 
 | ↓ from \ to → | docx | pptx | xlsx | odt | odp | ods | odg | svg | odf | markdown | csv | rtf | doc | xls | ppt | wpd | pdf |
 | ------------- | ---- | ---- | ---- | --- | --- | --- | --- | --- | --- | -------- | --- | --- | --- | --- | --- | --- | --- |
 | **docx**      | —    | ~    | ✗    | ✓   | ~   | ✗   | ✗   | ✗   | –   | ✗        | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ~   |
 | **pptx**      | ~    | —    | ✗    | ~   | ✓   | ✗   | ~   | ~   | –   | ~        | ✗   | ~   | ✗   | ✗   | ✗   | –   | ~   |
-| **xlsx**      | ✗    | ✗    | —    | ✗   | ✗   | ~   | ✗   | ✗   | –   | ✗✗       | ~   | –   | –   | ✗   | –   | –   | ~   |
+| **xlsx**      | ✗    | ✗    | —    | ✗   | ✗   | ~   | ✗   | ✗   | –   | ✗        | ~   | ✗   | ✗   | ✗   | ✗   | –   | ~   |
 | **odt**       | ✓    | ~    | ✗    | —   | ~   | ✗   | ✗   | ✗   | –   | ✗        | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ~   |
 | **odp**       | ~    | ✓    | ✗    | ~   | —   | ✗   | ~   | ~   | –   | ~        | ✗   | ~   | ✗   | ✗   | ✗   | –   | ~   |
-| **ods**       | ✗    | ✗    | ~    | ✗   | ✗   | —   | ✗   | ✗   | –   | ✗✗       | ~   | ✗   | ✗   | ✗   | ✗   | –   | ~   |
+| **ods**       | ✗    | ✗    | ~    | ✗   | ✗   | —   | ✗   | ✗   | –   | ✗        | ~   | ✗   | ✗   | ✗   | ✗   | –   | ~   |
 | **odg**       | ✗    | ~    | ✗    | ✗   | ~   | ✗   | —   | ✓   | –   | ✗        | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ~   |
 | **svg**       | ✗    | ~    | ✗    | ✗   | ~   | ✗   | ✓   | —   | –   | ✗✗       | ✗✗  | ✗   | ✗   | ✗   | ✗   | –   | ~   |
 | **odf**       | –    | –    | –    | –   | –   | –   | –   | –   | —   | –        | –   | –   | –   | –   | –   | –   | →   |
 | **markdown**  | ~    | ~    | ✗✗   | ~   | ~   | ✗   | ✗   | ✗✗  | –   | —        | ✗✗  | ~   | ✗   | ✗✗  | ✗   | –   | ~   |
-| **csv**       | ✗    | ✗    | ✓    | ✗   | ✗   | ✓   | ✗   | ✗   | –   | ✗✗       | —   | –   | –   | ✓   | –   | –   | ~   |
+| **csv**       | ✗    | ✗    | ✓    | ✗   | ✗   | ✓   | ✗   | ✗   | –   | ✗        | —   | ✗   | ✗   | ✓   | ✗   | –   | ~   |
 | **rtf**       | ~    | ~    | –    | ~   | ~   | ✗   | ✗   | ✗   | –   | ✗        | –   | —   | ✗   | –   | ✗   | –   | ~   |
 | **doc**       | ✗    | ✗    | –    | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ✗        | –   | ✗   | —   | –   | ✗   | –   | ~   |
-| **xls**       | ✗    | ✗    | ✗    | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ✗✗       | ~   | –   | –   | —   | –   | –   | ~   |
+| **xls**       | ✗    | ✗    | ✗    | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ✗        | ~   | ✗   | ✗   | —   | ✗   | –   | ~   |
 | **ppt**       | ✗    | ✗    | –    | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ✗        | –   | ✗   | ✗   | –   | —   | –   | ~   |
 | **wpd**       | →    | →    | →    | →   | →   | →   | →   | →   | –   | →        | →   | →   | →   | →   | →   | —   | →   |
 | **pdf**       | ✗    | ✗    | ✗    | ✗   | ✗   | ✗   | ✗   | ✗   | –   | ✗✗       | ✗   | ✗   | ✗   | ✗   | ✗   | –   | —   |
 
-208 of 272 directional pairs are routable. The shared `ContentDocument` model is the hub, not PDF — 112 of those 208 directional pairs (61 counted as an undirected format relationship, since most run both ways; ten don't, all of them `wpd`'s own outbound-only routes) resolve to a route whose every hop is a bridge, never touching PDF at all, confirmed by walking `resolveCompositionPlan` over every pair and checking no hop's executor is `toPdf`/`fromPdf`.
+217 of 272 directional pairs are routable. The shared `ContentDocument` model is the hub, not PDF — 150 of those 217 directional pairs (99 counted as an undirected format relationship: 51 run both ways; 38 are one-directional only — the one-way spreadsheet → wordprocessing/presentation reach `spreadsheetToWordprocessing` added ([ExaDev/documents.js#1043](https://github.com/ExaDev/documents.js/issues/1043)): `csv`/`ods`/`xls`/`xlsx` as source, reaching every wordprocessing member directly and every presentation member through one; the remaining ten don't run either way, all of them `wpd`'s own outbound-only routes) resolve to a route whose every hop is a bridge, never touching PDF at all, confirmed by walking `resolveCompositionPlan` over every pair and checking no hop's executor is `toPdf`/`fromPdf`.
 
 **X → PDF** is a genuine layout render: positioned text, images, tables, lists, vector primitives, styled through the full cascade. It is a faithful visual approximation, not pixel-identical — closeness depends on font availability.
 
@@ -966,7 +968,7 @@ Read as **row → column**. `✓` lossless, `~` bounded, `✗` lossy, `✗✗` s
 
 **PDF → ods** recovers what was printed, not what was entered. The printed string always survives in `displayText`; re-typed `value` is explicitly probabilistic inference.
 
-**`markdownToPdf`/`pdfToMarkdown`** is the lossiest round trip: `markdownToPdf` is faithful, but `pdfToMarkdown` stacks reconstruction lossiness PLUS markdown's coarser vocabulary (no colour, font, size, alignment). Two structure signals do survive it (ExaDev/documents.js#584): every page boundary arrives as an exact `<!-- page break -->` marker (one per boundary — the one fact a rendered PDF states precisely), and headings are inferred from font size — each distinct size at least 2pt above the document's modal body size is a heading, ranked largest-first into `Heading1..6`, which inverts this package's own heading render sizes exactly and is a heuristic (the well-worn "largest text is the title" reading) for any other producer. Tables reach markdown as GFM pipe tables wherever the gridline-lattice gate succeeds; a table rendered without drawn gridlines (which includes every `markdownToPdf`-authored one, markdown carrying no border concept) correctly comes back as tab-separated prose rather than invented structure. The PDF-composed markdown bridges (`xlsxToMarkdown`/`markdownToXlsx`, `csvToMarkdown`/`markdownToCsv`) stack the same two losses in both directions — hence their `✗✗` cells. `ods ⇄ markdown` stacks the identical pair of losses even without a named bridge function: the pathfinder's own bare toPdf-then-fromPdf route carries no extra hop, but the two legs are the same render-then-reconstruct-into-markdown pair, so both directions are `✗✗` too.
+**`markdownToPdf`/`pdfToMarkdown`** is the lossiest round trip: `markdownToPdf` is faithful, but `pdfToMarkdown` stacks reconstruction lossiness PLUS markdown's coarser vocabulary (no colour, font, size, alignment). Two structure signals do survive it (ExaDev/documents.js#584): every page boundary arrives as an exact `<!-- page break -->` marker (one per boundary — the one fact a rendered PDF states precisely), and headings are inferred from font size — each distinct size at least 2pt above the document's modal body size is a heading, ranked largest-first into `Heading1..6`, which inverts this package's own heading render sizes exactly and is a heuristic (the well-worn "largest text is the title" reading) for any other producer. Tables reach markdown as GFM pipe tables wherever the gridline-lattice gate succeeds; a table rendered without drawn gridlines (which includes every `markdownToPdf`-authored one, markdown carrying no border concept) correctly comes back as tab-separated prose rather than invented structure. `markdownToXlsx`/`markdownToCsv` still stack the same two losses on their own encode leg — hence their `✗` cells (`markdown` → `xlsx`/`csv`/`xls`, and the bare-route `markdown` → `ods` alongside them). The reverse direction (`xlsx`/`csv`/`xls`/`ods` → `markdown`) no longer touches PDF at all since [ExaDev/documents.js#1043](https://github.com/ExaDev/documents.js/issues/1043) registered `spreadsheetToWordprocessing`: a sheet becomes a heading plus one table directly, dropping only what a wordprocessing document genuinely has no field for (formulas, print settings, comments, anchored images/embedded objects) rather than stacking `pdfToMarkdown`'s reconstruction lossiness and coarser vocabulary on top — real content loss, but a single loss rather than two stacked ones, hence `✗` rather than `✗✗`.
 
 **The same-variant bridge pairs** (odt⇄docx, odp⇄pptx, ods⇄xlsx, csv⇄ods, csv⇄xlsx, csv⇄xls, svg⇄odg, plus rtf's own docx⇄rtf/odt⇄rtf) bypass PDF entirely — no layout engine, no reconstruction. Text, styling, tables, lists, rotated shapes survive completely wherever both formats' `ContentDocument` coverage matches. `ods⇄xlsx` has small format-boundary limits (time cells, formula dialects). Embedded formulas survive `odtToDocx` as real OOXML math. The csv pairs are bounded by what csv itself carries: toward ods/xlsx/xls nothing the csv had is lost, while writing to csv collapses each cell to its `displayText` — formulas become their rendered values, formatting disappears, and a multi-sheet source must name the sheet it wants. The svg pair carries the six vector primitives losslessly in both directions; its one asymmetry is paint defaults — SVG's absent-fill-is-black versus a drawing frame's no-fill. `docx⇄rtf`/`odt⇄rtf` are asymmetric the other way round: rtf-codec's own [Scope](../rtf-codec/README.md#scope) carries colour, font family/size, alignment, multiple sections, cell borders/shading/both merge directions, bookmarks, and tracked changes, so nothing docx/odt already lost crossing to rtf and back is lost a second time going rtf → docx/odt. What going docx/odt → rtf still drops is superscript/subscript and right-to-left text — and neither is an RTF gap: `ContentRun` carries no vertical-alignment or direction field at all, so the same content is lost crossing to _any_ format in this family, exactly as `epub-codec` reports for its own `<sub>`/`<sup>`.
 
@@ -978,7 +980,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, per-cell fonts, 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, its own alignment, 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.
+**`xls`'s writer never touches formulas, per-cell fonts, 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, its own alignment, 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` routes through the identical `spreadsheetToWordprocessing` transform `xlsx → markdown`/`csv → markdown` do (ExaDev/documents.js#1043) — dropping the same formulas/print-settings/comments/anchored-content, plus `xls`'s own already-dropped per-cell fonts, but nothing extra — so it earns the same `✗` those two do rather than a worse grade. `markdown → xls` has no reverse transform to take and still composes through `ods` and PDF, exactly as `markdown → xlsx`/`markdown → csv` do. 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.
 

package/dist/convert/composition.cjs

@@ -281,6 +281,10 @@ const TRANSFORMS = {
 	"presentation->drawing": (doc) => {
 		if (doc.kind !== "presentation") throw new Error("presentationToDrawing: expected a presentation ContentDocument");
 		return require_convert_variant_bridges.presentationToDrawing(doc);
+	},
+	"spreadsheet->wordprocessing": (doc) => {
+		if (doc.kind !== "spreadsheet") throw new Error("spreadsheetToWordprocessing: expected a spreadsheet ContentDocument");
+		return require_convert_variant_bridges.spreadsheetToWordprocessing(doc);
 	}
 };
 const RECONSTRUCTORS = {
@@ -370,7 +374,7 @@ function buildCompositionGraph() {
 			if (FORMAT_NODES[a].variant !== fromVariant) continue;
 			for (const b of CONTENT_FORMATS) {
 				if (FORMAT_NODES[b].variant !== toVariant) continue;
-				addEdge(a, b, 2);
+				addDirected(a, b, 2);
 			}
 		}
 	}

package/dist/convert/composition.js

@@ -25,7 +25,7 @@ import { writePptContent } from "../ppt/write.js";
 import { throwIfAborted } from "../ports/abort.js";
 import { reconstructDrawing, reconstructPresentation, reconstructSpreadsheet, reconstructWordprocessing } from "../layout/reconstruct.js";
 import { stampPdfPackageTables } from "./pdf-package-tables.js";
-import { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, wordprocessingToPresentation } from "./variant-bridges.js";
+import { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, spreadsheetToWordprocessing, wordprocessingToPresentation } from "./variant-bridges.js";
 import { UnsupportedConversionError } from "./capability.js";
 import { buildXlsxPackageFromContent, decodePackage, encodePackage, readXlsxContent } from "ooxml.js";
 import { assembleTree } from "document-schema.js";
@@ -280,6 +280,10 @@ const TRANSFORMS = {
 	"presentation->drawing": (doc) => {
 		if (doc.kind !== "presentation") throw new Error("presentationToDrawing: expected a presentation ContentDocument");
 		return presentationToDrawing(doc);
+	},
+	"spreadsheet->wordprocessing": (doc) => {
+		if (doc.kind !== "spreadsheet") throw new Error("spreadsheetToWordprocessing: expected a spreadsheet ContentDocument");
+		return spreadsheetToWordprocessing(doc);
 	}
 };
 const RECONSTRUCTORS = {
@@ -369,7 +373,7 @@ function buildCompositionGraph() {
 			if (FORMAT_NODES[a].variant !== fromVariant) continue;
 			for (const b of CONTENT_FORMATS) {
 				if (FORMAT_NODES[b].variant !== toVariant) continue;
-				addEdge(a, b, 2);
+				addDirected(a, b, 2);
 			}
 		}
 	}

package/dist/convert/convert.cjs

@@ -173,12 +173,12 @@ function pptToPdf(bytes, options) {
 function xlsxToMarkdown(bytes, options) {
 	return require_convert_composition_to_pdf.convertDocument("xlsx", "markdown", bytes, options);
 }
-function markdownToXlsx(bytes, options) {
-	return require_convert_composition_to_pdf.convertDocument("markdown", "xlsx", bytes, options);
-}
 function csvToMarkdown(bytes, options) {
 	return require_convert_composition_to_pdf.convertDocument("csv", "markdown", bytes, options);
 }
+function markdownToXlsx(bytes, options) {
+	return require_convert_composition_to_pdf.convertDocument("markdown", "xlsx", bytes, options);
+}
 function markdownToCsv(bytes, options) {
 	return require_convert_composition_to_pdf.convertDocument("markdown", "csv", bytes, options);
 }

package/dist/convert/convert.d.cts

@@ -89,9 +89,9 @@ declare function rtfToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPd
 declare function docToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPdfOptions): Uint8Array<ArrayBuffer>;
 declare function xlsToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPdfOptions): Uint8Array<ArrayBuffer>;
 declare function pptToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPdfOptions): Uint8Array<ArrayBuffer>;
-declare function xlsxToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions): Uint8Array<ArrayBuffer>;
+declare function xlsxToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: DocumentBridgeOptions): Uint8Array<ArrayBuffer>;
+declare function csvToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: DocumentBridgeOptions & CsvReadOptions): Uint8Array<ArrayBuffer>;
 declare function markdownToXlsx(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions): Uint8Array<ArrayBuffer>;
-declare function csvToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions & CsvReadOptions): Uint8Array<ArrayBuffer>;
 declare function markdownToCsv(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions & CsvWriteOptions): Uint8Array<ArrayBuffer>;
 interface OdmToPdfOptions extends DocumentToPdfOptions {
   readonly resolveSubDocument?: (href: string) => Uint8Array<ArrayBuffer> | undefined;

package/dist/convert/convert.d.ts

@@ -89,9 +89,9 @@ declare function rtfToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPd
 declare function docToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPdfOptions): Uint8Array<ArrayBuffer>;
 declare function xlsToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPdfOptions): Uint8Array<ArrayBuffer>;
 declare function pptToPdf(bytes: Uint8Array<ArrayBuffer>, options?: DocumentToPdfOptions): Uint8Array<ArrayBuffer>;
-declare function xlsxToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions): Uint8Array<ArrayBuffer>;
+declare function xlsxToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: DocumentBridgeOptions): Uint8Array<ArrayBuffer>;
+declare function csvToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: DocumentBridgeOptions & CsvReadOptions): Uint8Array<ArrayBuffer>;
 declare function markdownToXlsx(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions): Uint8Array<ArrayBuffer>;
-declare function csvToMarkdown(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions & CsvReadOptions): Uint8Array<ArrayBuffer>;
 declare function markdownToCsv(bytes: Uint8Array<ArrayBuffer>, options?: ComposedDocumentOptions & CsvWriteOptions): Uint8Array<ArrayBuffer>;
 interface OdmToPdfOptions extends DocumentToPdfOptions {
   readonly resolveSubDocument?: (href: string) => Uint8Array<ArrayBuffer> | undefined;

package/dist/convert/convert.js

@@ -172,12 +172,12 @@ function pptToPdf(bytes, options) {
 function xlsxToMarkdown(bytes, options) {
 	return convertDocument("xlsx", "markdown", bytes, options);
 }
-function markdownToXlsx(bytes, options) {
-	return convertDocument("markdown", "xlsx", bytes, options);
-}
 function csvToMarkdown(bytes, options) {
 	return convertDocument("csv", "markdown", bytes, options);
 }
+function markdownToXlsx(bytes, options) {
+	return convertDocument("markdown", "xlsx", bytes, options);
+}
 function markdownToCsv(bytes, options) {
 	return convertDocument("markdown", "csv", bytes, options);
 }

package/dist/convert/variant-bridges.cjs

@@ -91,8 +91,75 @@ function presentationToDrawing(doc) {
 		pages
 	};
 }
+function spreadsheetCellToTableCell(cell) {
+	if (cell === void 0) return { blocks: [{
+		kind: "paragraph",
+		runs: [{ text: "" }]
+	}] };
+	return { blocks: [{
+		kind: "paragraph",
+		runs: cell.runs ?? [{ text: cell.displayText }],
+		alignment: cell.alignment
+	}] };
+}
+function sheetToTableBlock(sheet) {
+	const hiddenRows = new Set(sheet.rows.filter((row) => row.hidden === true).map((row) => row.index));
+	const hiddenColumns = new Set(sheet.columns.filter((column) => column.hidden === true).map((column) => column.index));
+	const cellByPosition = /* @__PURE__ */ new Map();
+	let maxRow = -1;
+	let maxColumn = -1;
+	for (const cell of sheet.cells) {
+		if (hiddenRows.has(cell.row) || hiddenColumns.has(cell.column)) continue;
+		cellByPosition.set(`${String(cell.row)}:${String(cell.column)}`, cell);
+		maxRow = Math.max(maxRow, cell.row);
+		maxColumn = Math.max(maxColumn, cell.column);
+	}
+	if (cellByPosition.size === 0) return;
+	const visibleRows = [];
+	for (let row = 0; row <= maxRow; row += 1) if (!hiddenRows.has(row)) visibleRows.push(row);
+	const visibleColumns = [];
+	for (let column = 0; column <= maxColumn; column += 1) if (!hiddenColumns.has(column)) visibleColumns.push(column);
+	const columnWidthByIndex = new Map(sheet.columns.map((column) => [column.index, column.widthPt]));
+	const columnWidthsPt = visibleColumns.map((column) => columnWidthByIndex.get(column) ?? 72);
+	return {
+		kind: "table",
+		rows: visibleRows.map((row) => ({ cells: visibleColumns.map((column) => spreadsheetCellToTableCell(cellByPosition.get(`${String(row)}:${String(column)}`))) })),
+		columnWidthsPt
+	};
+}
+function spreadsheetToWordprocessing(doc) {
+	const blocks = [];
+	for (const sheet of doc.sheets) {
+		blocks.push({
+			kind: "paragraph",
+			headingLevel: 2,
+			runs: [{ text: sheet.name }]
+		});
+		const table = sheetToTableBlock(sheet);
+		blocks.push(table ?? {
+			kind: "paragraph",
+			runs: [{ text: "(empty sheet)" }]
+		});
+	}
+	const section = {
+		pageSize: document_schema_js.PAGE_SIZE_A4,
+		margins: {
+			topPt: 72,
+			rightPt: 72,
+			bottomPt: 72,
+			leftPt: 72
+		},
+		blocks
+	};
+	return {
+		kind: "wordprocessing",
+		metadata: doc.metadata,
+		sections: [section]
+	};
+}
 //#endregion
 exports.drawingToPresentation = drawingToPresentation;
 exports.presentationToDrawing = presentationToDrawing;
 exports.presentationToWordprocessing = presentationToWordprocessing;
+exports.spreadsheetToWordprocessing = spreadsheetToWordprocessing;
 exports.wordprocessingToPresentation = wordprocessingToPresentation;

package/dist/convert/variant-bridges.d.cts

@@ -9,9 +9,13 @@ type PresentationContentDocument = Extract<ContentDocument, {
 type DrawingContentDocument = Extract<ContentDocument, {
   kind: "drawing";
 }>;
+type SpreadsheetContentDocument = Extract<ContentDocument, {
+  kind: "spreadsheet";
+}>;
 declare function wordprocessingToPresentation(doc: WordprocessingContentDocument): PresentationContentDocument;
 declare function presentationToWordprocessing(doc: PresentationContentDocument): WordprocessingContentDocument;
 declare function drawingToPresentation(doc: DrawingContentDocument): PresentationContentDocument;
 declare function presentationToDrawing(doc: PresentationContentDocument): DrawingContentDocument;
+declare function spreadsheetToWordprocessing(doc: SpreadsheetContentDocument): WordprocessingContentDocument;
 //#endregion
-export { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, wordprocessingToPresentation };
+export { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, spreadsheetToWordprocessing, wordprocessingToPresentation };

package/dist/convert/variant-bridges.d.ts

@@ -9,9 +9,13 @@ type PresentationContentDocument = Extract<ContentDocument, {
 type DrawingContentDocument = Extract<ContentDocument, {
   kind: "drawing";
 }>;
+type SpreadsheetContentDocument = Extract<ContentDocument, {
+  kind: "spreadsheet";
+}>;
 declare function wordprocessingToPresentation(doc: WordprocessingContentDocument): PresentationContentDocument;
 declare function presentationToWordprocessing(doc: PresentationContentDocument): WordprocessingContentDocument;
 declare function drawingToPresentation(doc: DrawingContentDocument): PresentationContentDocument;
 declare function presentationToDrawing(doc: PresentationContentDocument): DrawingContentDocument;
+declare function spreadsheetToWordprocessing(doc: SpreadsheetContentDocument): WordprocessingContentDocument;
 //#endregion
-export { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, wordprocessingToPresentation };
+export { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, spreadsheetToWordprocessing, wordprocessingToPresentation };

package/dist/convert/variant-bridges.js

@@ -90,5 +90,71 @@ function presentationToDrawing(doc) {
 		pages
 	};
 }
+function spreadsheetCellToTableCell(cell) {
+	if (cell === void 0) return { blocks: [{
+		kind: "paragraph",
+		runs: [{ text: "" }]
+	}] };
+	return { blocks: [{
+		kind: "paragraph",
+		runs: cell.runs ?? [{ text: cell.displayText }],
+		alignment: cell.alignment
+	}] };
+}
+function sheetToTableBlock(sheet) {
+	const hiddenRows = new Set(sheet.rows.filter((row) => row.hidden === true).map((row) => row.index));
+	const hiddenColumns = new Set(sheet.columns.filter((column) => column.hidden === true).map((column) => column.index));
+	const cellByPosition = /* @__PURE__ */ new Map();
+	let maxRow = -1;
+	let maxColumn = -1;
+	for (const cell of sheet.cells) {
+		if (hiddenRows.has(cell.row) || hiddenColumns.has(cell.column)) continue;
+		cellByPosition.set(`${String(cell.row)}:${String(cell.column)}`, cell);
+		maxRow = Math.max(maxRow, cell.row);
+		maxColumn = Math.max(maxColumn, cell.column);
+	}
+	if (cellByPosition.size === 0) return;
+	const visibleRows = [];
+	for (let row = 0; row <= maxRow; row += 1) if (!hiddenRows.has(row)) visibleRows.push(row);
+	const visibleColumns = [];
+	for (let column = 0; column <= maxColumn; column += 1) if (!hiddenColumns.has(column)) visibleColumns.push(column);
+	const columnWidthByIndex = new Map(sheet.columns.map((column) => [column.index, column.widthPt]));
+	const columnWidthsPt = visibleColumns.map((column) => columnWidthByIndex.get(column) ?? 72);
+	return {
+		kind: "table",
+		rows: visibleRows.map((row) => ({ cells: visibleColumns.map((column) => spreadsheetCellToTableCell(cellByPosition.get(`${String(row)}:${String(column)}`))) })),
+		columnWidthsPt
+	};
+}
+function spreadsheetToWordprocessing(doc) {
+	const blocks = [];
+	for (const sheet of doc.sheets) {
+		blocks.push({
+			kind: "paragraph",
+			headingLevel: 2,
+			runs: [{ text: sheet.name }]
+		});
+		const table = sheetToTableBlock(sheet);
+		blocks.push(table ?? {
+			kind: "paragraph",
+			runs: [{ text: "(empty sheet)" }]
+		});
+	}
+	const section = {
+		pageSize: PAGE_SIZE_A4,
+		margins: {
+			topPt: 72,
+			rightPt: 72,
+			bottomPt: 72,
+			leftPt: 72
+		},
+		blocks
+	};
+	return {
+		kind: "wordprocessing",
+		metadata: doc.metadata,
+		sections: [section]
+	};
+}
 //#endregion
-export { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, wordprocessingToPresentation };
+export { drawingToPresentation, presentationToDrawing, presentationToWordprocessing, spreadsheetToWordprocessing, wordprocessingToPresentation };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "js.documents",
-  "version": "7.1.6",
+  "version": "7.1.8",
   "description": "Bidirectional docx/pptx <-> PDF conversion and a read+write editable OOXML document model, built on ooxml.js and Zod 4 codecs.",
   "type": "module",
   "repository": {
@@ -77,20 +77,20 @@
   ],
   "license": "MIT",
   "dependencies": {
-    "archive-codec": "^1.6.3",
+    "archive-codec": "^1.6.4",
     "byte-codec": "^1.4.0",
-    "doc-codec": "^2.2.3",
-    "document-schema.js": "^6.2.2",
+    "doc-codec": "^2.2.4",
+    "document-schema.js": "^6.2.3",
     "fflate": "^0.8.3",
-    "markdown-codec": "^6.3.3",
-    "odf.js": "^7.1.4",
-    "ooxml.js": "^7.1.5",
-    "pdf-codec": "^4.0.3",
-    "ppt-codec": "^1.2.4",
-    "rtf-codec": "^3.0.3",
+    "markdown-codec": "^6.3.4",
+    "odf.js": "^7.1.5",
+    "ooxml.js": "^7.1.6",
+    "pdf-codec": "^4.0.4",
+    "ppt-codec": "^1.2.5",
+    "rtf-codec": "^3.0.4",
     "temml": "0.13.4",
-    "wpd-codec": "^2.1.4",
-    "xls-codec": "^4.1.4",
+    "wpd-codec": "^2.1.5",
+    "xls-codec": "^4.1.5",
     "zod": "^4.4.3"
   },
   "devDependencies": {