js.documents 1.58.0 → 1.59.0

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) [![npm](https://img.shields.io/badge/npm-CB3837?logo=npm&logoColor=white)](https://www.npmjs.com/package/documents.js) [![Release](https://img.shields.io/github/v/release/ExaDev/documents.js)](https://github.com/ExaDev/documents.js/releases/latest) [![CI](https://img.shields.io/github/actions/workflow/status/ExaDev/documents.js/ci.yml?branch=main)](https://github.com/ExaDev/documents.js/actions)
 
-> Bidirectional docx/pptx/odt/odp/ods/odg ⇄ PDF conversion, a resolver-driven odm (ODF master document) → PDF conversion for multi-chapter documents, six further cross-format bridges (odt⇄docx, odp⇄pptx, ods⇄xlsx) that bypass PDF entirely, `.odb` (ODF database front-end) table extraction to xlsx/CSV from an embedded HSQLDB TEXT script (Tier 1), HSQLDB's own binary CACHED-table row-store format (Tier 2), and an embedded Firebird database's own gbak logical-backup format (Tier 3), a read-and-write live-view editor for docx/pptx/odt/odp/ods/odg content, a hand-written MathML presentation-layer typesetting engine with embedded-font PDF rendering (odf → PDF, plus formulas embedded inside odt/odp), and a fully hand-written PDF codec, built on [ooxml.js](https://github.com/ExaDev/ooxml.js) and [odf.js](https://github.com/ExaDev/odf.js).
+> Converts between any two compatible document formats through a shared content/layout pivot — docx, pptx, odt, odp, ods, odg, and xlsx all read into and build from the same `ContentDocument`/`LayoutDocument` model, with PDF simply the one format every variant can reach (docx/pptx/odt/odp/ods/odg/xlsx ⇄ PDF, thirteen pairs, all round-tripping both ways), plus six further cross-format bridges (odt⇄docx, odp⇄pptx, ods⇄xlsx) that bypass PDF entirely for pairs already sharing a pivot variant directly. Also included: a resolver-driven odm (ODF master document) → PDF conversion for multi-chapter documents, `.odb` (ODF database front-end) table extraction to xlsx/CSV from an embedded HSQLDB TEXT script (Tier 1), HSQLDB's own binary CACHED-table row-store format (Tier 2), and an embedded Firebird database's own gbak logical-backup format (Tier 3), a read-and-write live-view editor for docx/pptx/odt/odp/ods/odg content, a hand-written MathML presentation-layer typesetting engine with embedded-font PDF rendering (odf → PDF, plus formulas embedded inside odt/odp), and a fully hand-written PDF codec, built on [ooxml.js](https://github.com/ExaDev/ooxml.js) and [odf.js](https://github.com/ExaDev/odf.js).
 
 `documents.js` depends on `ooxml.js` for lossless docx/pptx/xlsx ⇄ JSON handling and extends it in two directions `ooxml.js` deliberately does not cover: full PDF support (parsing arbitrary real-world PDFs and generating new ones), and a read-**and-write** manipulation API for docx/pptx content — `ooxml.js`'s own typed readers (`readDocx`/`readPptx`) are one-way and explicitly forbid write-back. PDF reading, writing, and the docx⇄PDF/pptx⇄PDF conversion pipeline are provided by [`pdf-codec`](https://github.com/ExaDev/pdf-codec), a sibling package extracted from this one: a hand-written, dependency-minimal PDF codec with no external PDF library (`pdf-lib`, `pdfjs-dist`, `mupdf`, or any other) as a dependency — see pdf-codec's own README for how it's built and what it embeds (including the vendored STIX Two Math font this package renders formulas through). `src/mathml/` (the MathML typesetting engine) stays in this package and is hand-written too, for the same "no supply-chain surface beyond what's already declared" reason, but consumes pdf-codec's embedded math font through a structurally-typed port rather than any font-parsing code of its own — see [Architecture](#architecture).
 
@@ -59,10 +59,10 @@ npm install documents.js
 
 ## Usage
 
-The twelve round-trip ergonomic conversions (docx/pptx/odt/odp/ods/odg ⇄ PDF, all now round-trip both ways):
+The twelve round-trip ergonomic conversions between the six formats with their own layout engine and PDF (docx/pptx/odt/odp/ods/odg ⇄ PDF, all round-trip both ways), plus a thirteenth pair with the identical ergonomic shape and options — `xlsxToPdf`/`pdfToXlsx`, which composes the ods⇄xlsx bridge with the ods⇄pdf layout pair internally, since xlsx has no layout engine of its own:
 
 ```ts
-import { docxToPdf, odgToPdf, odpToPdf, odsToPdf, odtToPdf, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOds, pdfToOdt, pptxToPdf, pdfToPptx } from 'documents.js';
+import { docxToPdf, odgToPdf, odpToPdf, odsToPdf, odtToPdf, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOds, pdfToOdt, pdfToPptx, pdfToXlsx, pptxToPdf, xlsxToPdf } from 'documents.js';
 
 const pdfBytes = docxToPdf(docxBytes);
 const docxBytes2 = pdfToDocx(pdfBytes);
@@ -81,9 +81,12 @@ const odgBytes2 = pdfToOdg(pdfFromOdg);
 
 const pdfFromOds = odsToPdf(odsBytes);
 const odsBytes2 = pdfToOds(pdfFromOds); // recovers what was printed, not what was entered -- see Fidelity
+
+const pdfFromXlsx = xlsxToPdf(xlsxBytes); // composes xlsxToOds -> odsToPdf internally -- still a real, direct, single-call conversion
+const xlsxBytes2 = pdfToXlsx(pdfFromXlsx); // composes pdfToOds -> odsToXlsx internally
 ```
 
-Each accepts an optional `signal` (`AbortSignal`) and either a `onSubstitution` callback (docx/pptx/odt/odp/ods/odg → PDF, called once per character not representable in a standard-14 font) or a `sink` (PDF → docx/pptx/odt/odp/ods/odg, called once per recoverable parse diagnostic).
+Each accepts an optional `signal` (`AbortSignal`) and either a `onSubstitution` callback (docx/pptx/odt/odp/ods/odg/xlsx → PDF, called once per character not representable in a standard-14 font) or a `sink` (PDF → docx/pptx/odt/odp/ods/odg/xlsx, called once per recoverable parse diagnostic).
 
 Six further conversions bypass PDF entirely: `odtToDocx`/`docxToOdt`, `odpToPptx`/`pptxToOdp`, and `odsToXlsx`/`xlsxToOds` each compose a direct `readXContent` → `buildYPackage` pivot copy, since both sides of each pair already read into and build from the identical `ContentDocument` variant — no layout engine, no font measurement, and no geometry-based reconstruction in between. See [Fidelity](#fidelity) for what that means in practice.
 
@@ -262,7 +265,7 @@ try {
 }
 ```
 
-`odmToPdf` is not one of the twelve round-trip conversions or the six bridges above, has no `z.codec()` pair, and is not wired into the `DocumentConverter` port below — see Gotchas for why.
+`odmToPdf` is not one of the thirteen round-trip conversions or the six bridges above, has no `z.codec()` pair, and is not wired into the `DocumentConverter` port below — see Gotchas for why.
 
 `.odb` (ODF database front-end) support: `readOdbTables` extracts every table an embedded database declares, and `odbToXlsx`/`odbToCsv` turn that straight into xlsx or CSV bytes. Three embedded storage shapes are supported, dispatched automatically from the package's own connection URL and, for HSQLDB, its own per-table storage shape: a MEMORY/TEXT table's rows inline in `database/script` as ordinary TEXT-format SQL (Tier 1, `src/hsqldb/script.ts`), a CACHED table's rows in a separate binary page-cache file, `database/data` (Tier 2, `src/hsqldb/cache.ts`/`rowformat.ts` — LibreOffice's own embedded-HSQLDB default, see Architecture/Gotchas for the exact scope and version pinning), and a Firebird database's own `database/firebird.fbk` part — LibreOffice's modern default embedded engine since 4.1, a genuine gbak logical-backup stream rather than a raw on-disk database file (Tier 3; see the Gotchas entry below for the empirical finding this rests on). A caller never needs to know which shape or engine a given `.odb` used. HSQLDB's own whole-script BINARY/COMPRESSED serialisation is the one embedded shape still out of scope (see Gotchas/Fidelity):
 
@@ -294,7 +297,7 @@ import { odfToPdf } from 'documents.js';
 const pdfBytes = odfToPdf(odfBytes); // a single formula (or small formula document), faithfully typeset -- see Fidelity
 ```
 
-`odfToPdf` is not one of the twelve round-trip conversions above either: there is no `pdfToOdf` (recovering structured MathML from rendered glyphs is a categorically different, OCR-adjacent problem, not a geometry-reconstruction one — see [Fidelity](#fidelity)), no `z.codec()` pair, and — unlike `odmToPdf` — it *is* wired into the `DocumentConverter` port below, as a `DocumentFormat: 'odf'` source with only a `'pdf'` target.
+`odfToPdf` is not one of the thirteen round-trip conversions above either: there is no `pdfToOdf` (recovering structured MathML from rendered glyphs is a categorically different, OCR-adjacent problem, not a geometry-reconstruction one — see [Fidelity](#fidelity)), no `z.codec()` pair, and — unlike `odmToPdf` — it *is* wired into the `DocumentConverter` port below, as a `DocumentFormat: 'odf'` source with only a `'pdf'` target.
 
 Standalone `.odf` files are rare in practice; a formula embedded inside an odt paragraph or an odp slide is the far more common real-world case, and `odtToPdf`/`odpToPdf` already render one automatically wherever `readOdtContent`/`readOdpContent` find a `draw:frame` referencing an embedded formula sub-object — no extra code needed at the call site:
 
@@ -396,7 +399,7 @@ To run a single test file: `pnpm vitest run src/path/to/file.test.ts`.
 - **`readPdf` tracks general vector paths, not just axis-aligned rectangles — pdf-codec's own capability, with a direct consequence for this package's `pdfToOds`/`reconstructDrawing`.** A stroked-and-filled rect, any ellipse, and any plain line each come back from a real PDF round trip as a generic `LayoutPath` rather than their original kind (see pdf-codec's own `interpret.ts` gotcha for the exact fast-path boundary and the ISO 32000-1 operators involved). This is the shared infrastructure both `pdfToOds` and `reconstructDrawing` need; both now use it. A direct, practical consequence for `pdfToOds`: `readPdf` never reconstructs a `'line'` kind item at all, so a gridline written by `sheets.ts`'s own `renderGridlines` always comes back from a real PDF round trip as a generic, single-subpath, single-line-segment, stroke-only `LayoutPath` — `reconstructSpreadsheet`'s own gridline-lattice detection accepts both shapes (a genuine `LayoutLine` item and this stroked-single-segment `LayoutPath` shape) for exactly this reason.
 - **`pdfToOds` recovers what was printed, not what was entered.** `reconstructSpreadsheet` (`src/layout/reconstruct.ts`) tries a real gridline lattice first: it scans the page's `LayoutLine`/stroked-single-segment-`LayoutPath` items (see the `interpret.ts` gotcha above) for enough parallel horizontal and vertical lines at consistent positions to call it a printed grid (`MIN_GRIDLINE_COUNT_PER_AXIS = 3` per axis, i.e. at least a 2×2 grid, and a span-consistency check that rejects a scatter of unrelated short strokes — a page border or a couple of decorative rules — as not a genuine lattice), and uses those line positions DIRECTLY as cell boundaries when found. Absent a lattice, it clusters text into a grid from geometry alone instead: rows reuse `clusterIntoLines` verbatim (a spreadsheet cell's own text is never wrapped across lines, so a text line already IS a row), and columns generalise `clusterIntoParagraphs`'s own single `dominantLeftX` to several recurring x-position anchors, first merging directly-adjacent same-line fragments (`splitLineByLargeGaps`, the same >2em-gap signal `reconstructPresentation`'s own block clustering uses) so a cell whose text arrived as several run-level-split `LayoutText` items isn't scattered across spurious columns. Column widths and row heights are genuinely measured from whichever geometry was used (drawn gridline gaps, or measured text/anchor extents), never invented. Every recovered cell is a bare string carrying only its own extracted `displayText` — **never** re-parsed into a number/date/boolean, and never claimed as a formula, even when the text looks numeric or date-shaped; see [Fidelity](#fidelity) for the full framing. `buildOdsPackage` (`src/edit/ods/content.ts`) is `pdfToOds`'s own package-building half, mirroring `buildOdtPackage`/`buildOdpPackage`/`buildOdgPackage`'s role for `pdfToOdt`/`pdfToOdp`/`pdfToOdg`.
 - **`buildOdsPackage` now writes `printSettings` for real, via a new `OdsSheet.printSettings` getter/setter (`src/edit/ods/print-settings.ts`) — discovered as a genuine blocker while building `pdfToOds`'s own round-trip verification, not a pre-planned feature.** `OdsEditor`/`OdsSheet` previously had no width/height/print-settings API at all, so `buildOdsPackage` silently dropped `ContentSheetPrintSettings` entirely; that made a reconstructed sheet's own recovered `gridlines`/`headers`/`pageSize` unverifiable by any real write-then-reread round trip, which is exactly what `pdfToOds`'s own test needed to prove. The setter mints a fresh `style:page-layout` (`styles.xml`/`office:automatic-styles`) + `style:master-page` (`styles.xml`/`office:master-styles`) + `style:style[family="table"]` (`content.xml`/`office:automatic-styles`) triple and repoints the sheet's own `table:style-name` to it on every call, rather than mutating whatever it was pointing at before — the same append-only style-editing convention `src/edit/odg/style.ts` already documents. Scoped to the five fields `ContentSheetPrintSettingsSchema` always carries (`pageSize`/`margins`/`gridlines`/`headers`/`pageOrder`); `printRange`/`scale`/`fitToPages`/`repeatRows`/`repeatColumns`/`manualBreaks` (all optional, and never set by `reconstructSpreadsheet`) are still not read or written — resolving them needs the same table-wide repeated-column/row cursor tracking `odf.js`'s own `readTable` does before ever calling its own `readPrintSettings`, a genuinely separate, larger undertaking than this getter/setter's own scope.
-- **`OdsSheet`/`OdsEditor` still have no column-width or row-height setter at all — discovered the same way as the `printSettings` gap above, while building `pdfToOds`'s own smoke-test coverage.** `OdsSheet.cell()`'s own column/row-materialisation (`address.ts`) creates a real, explicit `table:table-column`/`table:table-row` element for any position a caller ever addresses, but never gives it a width/height style. This is a genuinely different failure shape from a column/row with NO element at all: `sheets.ts`'s own `resolveAxis` only falls back to `DEFAULT_COLUMN_WIDTH_PT`/`DEFAULT_ROW_HEIGHT_PT` for an index with no `ContentSheetColumn`/`ContentSheetRow` entry whatsoever — an explicit-but-unstyled element reads back at `widthPt`/`heightPt` 0 (`odf.js`'s own `resolveColumnWidthPt`/`readRowLayout`), and that explicit zero wins over the fallback. A sheet built purely through `createOds()`/`OdsSheet.cell()` therefore renders with a zero-size grid — real content needs an explicit column-width/row-height style, exactly as a real LibreOffice-authored file always has one (see `src/test-support/ods.ts`'s own fixtures, which set one deliberately). `buildOdsPackage` (`src/edit/ods/content.ts`) documents this as a tracked, bounded gap alongside `ContentSheetImage`/`embeddedObjects`, mirroring `buildOdtPackage`'s own identical image/colSpan-write gaps.
+- **`OdsSheet` now has a real column-width/row-height setter (`setColumnWidth`/`setRowHeight`, `src/edit/ods/column-row.ts`), closing a gap that escalated from cosmetic to a genuine correctness bug once `xlsxToPdf`/`pdfToXlsx` started composing through `buildOdsPackage` internally.** `OdsSheet.cell()`'s own column/row-materialisation (`address.ts`) creates a real, explicit `table:table-column`/`table:table-row` element for any position a caller ever addresses, but previously never gave it a width/height style. This is a genuinely different failure shape from a column/row with NO element at all: `sheets.ts`'s own `resolveAxis` only falls back to `DEFAULT_COLUMN_WIDTH_PT`/`DEFAULT_ROW_HEIGHT_PT` for an index with no `ContentSheetColumn`/`ContentSheetRow` entry whatsoever — an explicit-but-unstyled element reads back at `widthPt`/`heightPt` 0 (`odf.js`'s own `resolveColumnWidthPt`/`readRowLayout`), and that explicit zero wins over the fallback. While `buildOdsPackage`'s own output was only ever a terminal deliverable (`pdfToOds`, or a caller's own `readOdsContent` round trip), this was cosmetic: a real app reopening it would use its own defaults instead of the source's. `xlsxToPdf` (`xlsxToOds` then `odsToPdf`) made it a real bug instead — the intermediate ods bytes get laid out again by `convertSpreadsheetToLayout`, and a zero-size grid collapses every cell onto the same physical position rather than merely losing precision. `setColumnWidth`/`setRowHeight` mint a fresh `style:style[family="table-column"|"table-row"]` per column/row and repoint its own `table:style-name`, the same append-only style-minting convention `writeSheetPrintSettings`/`src/edit/odg/style.ts` already establish; `buildOdsPackage` now calls both for every `ContentSheetColumn`/`ContentSheetRow` a source sheet carries. Column/row HIDDEN state (`table:visibility`, a plain attribute rather than a style property) remains a separate, still-untracked write-side gap, alongside `ContentSheetImage`/`embeddedObjects` — mirroring `buildOdtPackage`'s own identical image/colSpan-write gaps.
 - **`reconstructDrawing` maps recovered geometry back onto ODF shapes near-1:1, with no clustering — but PDF's own content-stream operators still force several `ContentVector` kinds to collapse to a generic `path` on the way through.** Every painted `LayoutItem` maps onto a `ContentVector`/`ContentShape` directly, in the exact z-order it was recovered — `LayoutRect` → `rect`, `LayoutEllipse` → `ellipse`, `LayoutLine` → `line`, `LayoutPath` → `path`, `LayoutText`/`LayoutImage` → `ContentShape` — a fundamentally more tractable problem than `reconstructWordprocessing`/`reconstructPresentation`'s own paragraph/shape geometry clustering, since a drawing has no semantic structure to infer at all. The catch is upstream of `reconstructDrawing` itself, in what `readPdf` can even hand it: pdf-codec's own `LayoutRect` fast path only fires for a fill-only rectangle under a non-rotated CTM (see the general-vector-path-tracking gotcha above), `writeEllipse` always emits an ellipse as four cubic Beziers with no PDF-level marker that it started life as an ellipse, and `readPdf` never reconstructs a `'line'` kind item at all — so a stroked-and-filled rect, any ellipse, and any line each come back from a PDF as a generic `LayoutPath`, and `reconstructDrawing` correctly maps that to a `ContentVector` `'path'`, not the shape's original kind. Position, size, and fill/stroke colour still survive (within ordinary floating-point/string-formatting tolerance); only the vector's own discriminant kind narrows to whatever PDF's content-stream operators actually distinguish. A `path` vector's own reconstructed `frame` is a further, separate approximation: it is the *tight* bounding box of every recovered point, cubic control points included (a cubic curve is guaranteed to lie within their convex hull, so this never clips the curve) — which can legitimately be *larger* than whatever frame the original path's own author declared, if that frame didn't tightly bound its own control points to begin with (a real, valid ODF/SVG authoring pattern: a `viewBox`/frame is a declared coordinate window, not a guaranteed tight bounding box). A single original drawing text box that PDF's own greedy line-wrapper split across several lines does **not** reconstruct as one multi-line shape: `reconstructDrawing` maps each recovered `LayoutText` item to its own separate `ContentShape` (the same one-`LayoutItem`-to-one-shape rule every other kind follows), so a wrapped multi-line text box comes back as several small, independently-positioned text boxes, one per original line — confirmed visually against real LibreOffice (see the real-file verification note below); the full text content still survives, just redistributed. `buildOdgPackage` (`src/edit/odg/content.ts`) is `pdfToOdg`'s own package-building half, mirroring `buildOdtPackage`/`buildOdpPackage`'s role for `pdfToOdt`/`pdfToOdp`.
 - **Two real, confirmed-against-actual-LibreOffice-rendering fill bugs were fixed as part of building `reconstructDrawing`/`pdfToOdg`, not by it.** Both are pre-existing gaps in code that `reconstructDrawing`'s own real-file verification exposed, not something the reconstruction algorithm itself introduced, and both apply to every `.odg` this package writes, not only a reconstructed one: (1) `src/edit/odg/style.ts`'s `graphicPropertyAttrs` wrote `draw:fill-color` alone, with no accompanying `draw:fill="solid"` — real LibreOffice 26.2 fills a `draw:rect`/`draw:ellipse` that way fine, but silently renders a `draw:path` with the identical omission as unfilled, even with a fill colour declared. `draw:fill="solid"` is now written explicitly whenever a fill is set, for every vector kind. (2) `writeEllipse` (pdf-codec's own `content-write.ts`) never emitted a PDF closepath (`h`) operator, even though its four Bezier arcs already return exactly to their own starting point — PDF fill operators close every subpath implicitly regardless (ISO 32000-1 8.5.3.1), but `readPdf`'s own general path tracking only marks a subpath `closed: true` when it actually sees an explicit `h`, so a PDF-round-tripped ellipse came back with `closed: false`, which correctly-behaving ODF/SVG consumers then refuse to fill even with `draw:fill="solid"` set. `writeEllipse` now emits `h` before its paint operator, drawing no additional ink (the path was already geometrically closed) but recording that closure explicitly.
 - **A vector primitive's own fill/stroke needed a self-contained graphic-family style writer, not `odf.js`'s own `StyleRegistry`.** `'graphic'` is a recognised `StyleFamily` member (`odf.js`'s `src/styles/registry.ts`), but `StylePropertiesSchema`/`buildStylePropertyElements` (`properties.ts`/`serialize.ts`) only ever model text/paragraph formatting and never emit a `style:graphic-properties` element for any family — extending that shared package for one narrow, documents.js-local need (`draw:fill(-color)`/`draw:stroke` + `svg:stroke-color`/`svg:stroke-width`) would be scope creep into a foreign package for a two-attribute-group writer this package can express directly. `src/edit/odg/style.ts` is that writer: it still reuses `odf.js`'s general append-only style-editing invariant (a setter always mints a fresh `style:style` and repoints `draw:style-name`, never mutates an existing entry — verified by the same `assertAutomaticStylesOnlyAppended` helper `OdpEditor`'s own live-view fidelity test uses) and `src/edit/odt/automatic-styles.ts`'s `ensureAutomaticStyles`/`nextStyleName` (the "find-or-create `office:automatic-styles`, mint the next unused name" logic every other hand-rolled style helper in this package already shares), rather than a third reimplementation of either.

package/dist/convert/capability.cjs

@@ -0,0 +1,198 @@
+Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
+const require_convert_convert = require("./convert.cjs");
+//#region src/convert/capability.ts
+const FORMAT_CAPABILITIES = {
+	docx: {
+		format: "docx",
+		variant: "wordprocessing",
+		hasLayoutPath: true
+	},
+	odt: {
+		format: "odt",
+		variant: "wordprocessing",
+		hasLayoutPath: true
+	},
+	pptx: {
+		format: "pptx",
+		variant: "presentation",
+		hasLayoutPath: true
+	},
+	odp: {
+		format: "odp",
+		variant: "presentation",
+		hasLayoutPath: true
+	},
+	ods: {
+		format: "ods",
+		variant: "spreadsheet",
+		hasLayoutPath: true
+	},
+	xlsx: {
+		format: "xlsx",
+		variant: "spreadsheet",
+		hasLayoutPath: false
+	},
+	odg: {
+		format: "odg",
+		variant: "drawing",
+		hasLayoutPath: true
+	},
+	odf: {
+		format: "odf",
+		hasLayoutPath: false
+	},
+	pdf: {
+		format: "pdf",
+		hasLayoutPath: false
+	}
+};
+const DIRECT_EDGES = [
+	{
+		kind: "toPdf",
+		source: "docx",
+		target: "pdf",
+		convert: require_convert_convert.docxToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "pptx",
+		target: "pdf",
+		convert: require_convert_convert.pptxToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odt",
+		target: "pdf",
+		convert: require_convert_convert.odtToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odp",
+		target: "pdf",
+		convert: require_convert_convert.odpToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "ods",
+		target: "pdf",
+		convert: require_convert_convert.odsToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odg",
+		target: "pdf",
+		convert: require_convert_convert.odgToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odf",
+		target: "pdf",
+		convert: require_convert_convert.odfToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "xlsx",
+		target: "pdf",
+		convert: require_convert_convert.xlsxToPdf
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "docx",
+		convert: require_convert_convert.pdfToDocx
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "pptx",
+		convert: require_convert_convert.pdfToPptx
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "odt",
+		convert: require_convert_convert.pdfToOdt
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "odp",
+		convert: require_convert_convert.pdfToOdp
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "ods",
+		convert: require_convert_convert.pdfToOds
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "odg",
+		convert: require_convert_convert.pdfToOdg
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "xlsx",
+		convert: require_convert_convert.pdfToXlsx
+	},
+	{
+		kind: "bridge",
+		source: "odt",
+		target: "docx",
+		convert: require_convert_convert.odtToDocx
+	},
+	{
+		kind: "bridge",
+		source: "docx",
+		target: "odt",
+		convert: require_convert_convert.docxToOdt
+	},
+	{
+		kind: "bridge",
+		source: "odp",
+		target: "pptx",
+		convert: require_convert_convert.odpToPptx
+	},
+	{
+		kind: "bridge",
+		source: "pptx",
+		target: "odp",
+		convert: require_convert_convert.pptxToOdp
+	},
+	{
+		kind: "bridge",
+		source: "ods",
+		target: "xlsx",
+		convert: require_convert_convert.odsToXlsx
+	},
+	{
+		kind: "bridge",
+		source: "xlsx",
+		target: "ods",
+		convert: require_convert_convert.xlsxToOds
+	}
+];
+function resolveConversionPath(source, target, edges = DIRECT_EDGES) {
+	if (source === target) return;
+	const direct = edges.find((edge) => edge.source === source && edge.target === target);
+	if (direct !== void 0) return {
+		kind: "direct",
+		edge: direct
+	};
+	for (const first of edges) {
+		if (first.source !== source) continue;
+		const second = edges.find((edge) => edge.source === first.target && edge.target === target);
+		if (second !== void 0) return {
+			kind: "composed",
+			via: first.target,
+			first,
+			second
+		};
+	}
+}
+//#endregion
+exports.DIRECT_EDGES = DIRECT_EDGES;
+exports.FORMAT_CAPABILITIES = FORMAT_CAPABILITIES;
+exports.resolveConversionPath = resolveConversionPath;

package/dist/convert/capability.d.cts

@@ -0,0 +1,42 @@
+import { DocumentBridgeOptions, DocumentToPdfOptions, PdfToDocumentOptions } from "./convert.cjs";
+import { DocumentFormat } from "./port.cjs";
+//#region src/convert/capability.d.ts
+type ContentVariant = 'wordprocessing' | 'presentation' | 'spreadsheet' | 'drawing';
+interface FormatCapability {
+  readonly format: DocumentFormat;
+  readonly variant?: ContentVariant;
+  readonly hasLayoutPath: boolean;
+}
+declare const FORMAT_CAPABILITIES: Readonly<Record<DocumentFormat, FormatCapability>>;
+interface ToPdfEdge {
+  readonly kind: 'toPdf';
+  readonly source: DocumentFormat;
+  readonly target: 'pdf';
+  readonly convert: (bytes: Uint8Array<ArrayBuffer>, options: DocumentToPdfOptions) => Uint8Array<ArrayBuffer>;
+}
+interface FromPdfEdge {
+  readonly kind: 'fromPdf';
+  readonly source: 'pdf';
+  readonly target: DocumentFormat;
+  readonly convert: (bytes: Uint8Array<ArrayBuffer>, options: PdfToDocumentOptions) => Uint8Array<ArrayBuffer>;
+}
+interface BridgeEdge {
+  readonly kind: 'bridge';
+  readonly source: DocumentFormat;
+  readonly target: DocumentFormat;
+  readonly convert: (bytes: Uint8Array<ArrayBuffer>, options: DocumentBridgeOptions) => Uint8Array<ArrayBuffer>;
+}
+type ConversionEdge = ToPdfEdge | FromPdfEdge | BridgeEdge;
+declare const DIRECT_EDGES: readonly ConversionEdge[];
+type ConversionStrategy = {
+  readonly kind: 'direct';
+  readonly edge: ConversionEdge;
+} | {
+  readonly kind: 'composed';
+  readonly via: DocumentFormat;
+  readonly first: ConversionEdge;
+  readonly second: ConversionEdge;
+};
+declare function resolveConversionPath(source: DocumentFormat, target: DocumentFormat, edges?: readonly ConversionEdge[]): ConversionStrategy | undefined;
+//#endregion
+export { BridgeEdge, ContentVariant, ConversionEdge, ConversionStrategy, DIRECT_EDGES, FORMAT_CAPABILITIES, FormatCapability, FromPdfEdge, ToPdfEdge, resolveConversionPath };

package/dist/convert/capability.d.ts

@@ -0,0 +1,42 @@
+import { DocumentBridgeOptions, DocumentToPdfOptions, PdfToDocumentOptions } from "./convert.js";
+import { DocumentFormat } from "./port.js";
+//#region src/convert/capability.d.ts
+type ContentVariant = 'wordprocessing' | 'presentation' | 'spreadsheet' | 'drawing';
+interface FormatCapability {
+  readonly format: DocumentFormat;
+  readonly variant?: ContentVariant;
+  readonly hasLayoutPath: boolean;
+}
+declare const FORMAT_CAPABILITIES: Readonly<Record<DocumentFormat, FormatCapability>>;
+interface ToPdfEdge {
+  readonly kind: 'toPdf';
+  readonly source: DocumentFormat;
+  readonly target: 'pdf';
+  readonly convert: (bytes: Uint8Array<ArrayBuffer>, options: DocumentToPdfOptions) => Uint8Array<ArrayBuffer>;
+}
+interface FromPdfEdge {
+  readonly kind: 'fromPdf';
+  readonly source: 'pdf';
+  readonly target: DocumentFormat;
+  readonly convert: (bytes: Uint8Array<ArrayBuffer>, options: PdfToDocumentOptions) => Uint8Array<ArrayBuffer>;
+}
+interface BridgeEdge {
+  readonly kind: 'bridge';
+  readonly source: DocumentFormat;
+  readonly target: DocumentFormat;
+  readonly convert: (bytes: Uint8Array<ArrayBuffer>, options: DocumentBridgeOptions) => Uint8Array<ArrayBuffer>;
+}
+type ConversionEdge = ToPdfEdge | FromPdfEdge | BridgeEdge;
+declare const DIRECT_EDGES: readonly ConversionEdge[];
+type ConversionStrategy = {
+  readonly kind: 'direct';
+  readonly edge: ConversionEdge;
+} | {
+  readonly kind: 'composed';
+  readonly via: DocumentFormat;
+  readonly first: ConversionEdge;
+  readonly second: ConversionEdge;
+};
+declare function resolveConversionPath(source: DocumentFormat, target: DocumentFormat, edges?: readonly ConversionEdge[]): ConversionStrategy | undefined;
+//#endregion
+export { BridgeEdge, ContentVariant, ConversionEdge, ConversionStrategy, DIRECT_EDGES, FORMAT_CAPABILITIES, FormatCapability, FromPdfEdge, ToPdfEdge, resolveConversionPath };

package/dist/convert/capability.js

@@ -0,0 +1,195 @@
+import { docxToOdt, docxToPdf, odfToPdf, odgToPdf, odpToPdf, odpToPptx, odsToPdf, odsToXlsx, odtToDocx, odtToPdf, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOds, pdfToOdt, pdfToPptx, pdfToXlsx, pptxToOdp, pptxToPdf, xlsxToOds, xlsxToPdf } from "./convert.js";
+//#region src/convert/capability.ts
+const FORMAT_CAPABILITIES = {
+	docx: {
+		format: "docx",
+		variant: "wordprocessing",
+		hasLayoutPath: true
+	},
+	odt: {
+		format: "odt",
+		variant: "wordprocessing",
+		hasLayoutPath: true
+	},
+	pptx: {
+		format: "pptx",
+		variant: "presentation",
+		hasLayoutPath: true
+	},
+	odp: {
+		format: "odp",
+		variant: "presentation",
+		hasLayoutPath: true
+	},
+	ods: {
+		format: "ods",
+		variant: "spreadsheet",
+		hasLayoutPath: true
+	},
+	xlsx: {
+		format: "xlsx",
+		variant: "spreadsheet",
+		hasLayoutPath: false
+	},
+	odg: {
+		format: "odg",
+		variant: "drawing",
+		hasLayoutPath: true
+	},
+	odf: {
+		format: "odf",
+		hasLayoutPath: false
+	},
+	pdf: {
+		format: "pdf",
+		hasLayoutPath: false
+	}
+};
+const DIRECT_EDGES = [
+	{
+		kind: "toPdf",
+		source: "docx",
+		target: "pdf",
+		convert: docxToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "pptx",
+		target: "pdf",
+		convert: pptxToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odt",
+		target: "pdf",
+		convert: odtToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odp",
+		target: "pdf",
+		convert: odpToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "ods",
+		target: "pdf",
+		convert: odsToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odg",
+		target: "pdf",
+		convert: odgToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "odf",
+		target: "pdf",
+		convert: odfToPdf
+	},
+	{
+		kind: "toPdf",
+		source: "xlsx",
+		target: "pdf",
+		convert: xlsxToPdf
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "docx",
+		convert: pdfToDocx
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "pptx",
+		convert: pdfToPptx
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "odt",
+		convert: pdfToOdt
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "odp",
+		convert: pdfToOdp
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "ods",
+		convert: pdfToOds
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "odg",
+		convert: pdfToOdg
+	},
+	{
+		kind: "fromPdf",
+		source: "pdf",
+		target: "xlsx",
+		convert: pdfToXlsx
+	},
+	{
+		kind: "bridge",
+		source: "odt",
+		target: "docx",
+		convert: odtToDocx
+	},
+	{
+		kind: "bridge",
+		source: "docx",
+		target: "odt",
+		convert: docxToOdt
+	},
+	{
+		kind: "bridge",
+		source: "odp",
+		target: "pptx",
+		convert: odpToPptx
+	},
+	{
+		kind: "bridge",
+		source: "pptx",
+		target: "odp",
+		convert: pptxToOdp
+	},
+	{
+		kind: "bridge",
+		source: "ods",
+		target: "xlsx",
+		convert: odsToXlsx
+	},
+	{
+		kind: "bridge",
+		source: "xlsx",
+		target: "ods",
+		convert: xlsxToOds
+	}
+];
+function resolveConversionPath(source, target, edges = DIRECT_EDGES) {
+	if (source === target) return;
+	const direct = edges.find((edge) => edge.source === source && edge.target === target);
+	if (direct !== void 0) return {
+		kind: "direct",
+		edge: direct
+	};
+	for (const first of edges) {
+		if (first.source !== source) continue;
+		const second = edges.find((edge) => edge.source === first.target && edge.target === target);
+		if (second !== void 0) return {
+			kind: "composed",
+			via: first.target,
+			first,
+			second
+		};
+	}
+}
+//#endregion
+export { DIRECT_EDGES, FORMAT_CAPABILITIES, resolveConversionPath };

package/dist/convert/codec.cjs

@@ -27,6 +27,10 @@ const odgPdfCodec = zod.z.codec(require_model_bytes.OdgBytesSchema, require_mode
 	decode: (odgBytes) => require_convert_convert.odgToPdf(odgBytes),
 	encode: (pdfBytes) => require_convert_convert.pdfToOdg(pdfBytes)
 });
+const xlsxPdfCodec = zod.z.codec(require_model_bytes.XlsxBytesSchema, require_model_bytes.PdfBytesSchema, {
+	decode: (xlsxBytes) => require_convert_convert.xlsxToPdf(xlsxBytes),
+	encode: (pdfBytes) => require_convert_convert.pdfToXlsx(pdfBytes)
+});
 const odtDocxCodec = zod.z.codec(require_model_bytes.OdtBytesSchema, require_model_bytes.DocxBytesSchema, {
 	decode: (odtBytes) => require_convert_convert.odtToDocx(odtBytes),
 	encode: (docxBytes) => require_convert_convert.docxToOdt(docxBytes)
@@ -49,3 +53,4 @@ exports.odsXlsxCodec = odsXlsxCodec;
 exports.odtDocxCodec = odtDocxCodec;
 exports.odtPdfCodec = odtPdfCodec;
 exports.pptxPdfCodec = pptxPdfCodec;
+exports.xlsxPdfCodec = xlsxPdfCodec;

package/dist/convert/codec.d.cts

@@ -6,8 +6,9 @@ declare const odtPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8
 declare const odpPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odsPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odgPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
+declare const xlsxPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odtDocxCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odpPptxCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odsXlsxCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 //#endregion
-export { docxPdfCodec, odgPdfCodec, odpPdfCodec, odpPptxCodec, odsPdfCodec, odsXlsxCodec, odtDocxCodec, odtPdfCodec, pptxPdfCodec };
+export { docxPdfCodec, odgPdfCodec, odpPdfCodec, odpPptxCodec, odsPdfCodec, odsXlsxCodec, odtDocxCodec, odtPdfCodec, pptxPdfCodec, xlsxPdfCodec };

package/dist/convert/codec.d.ts

@@ -6,8 +6,9 @@ declare const odtPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8
 declare const odpPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odsPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odgPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
+declare const xlsxPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odtDocxCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odpPptxCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odsXlsxCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 //#endregion
-export { docxPdfCodec, odgPdfCodec, odpPdfCodec, odpPptxCodec, odsPdfCodec, odsXlsxCodec, odtDocxCodec, odtPdfCodec, pptxPdfCodec };
+export { docxPdfCodec, odgPdfCodec, odpPdfCodec, odpPptxCodec, odsPdfCodec, odsXlsxCodec, odtDocxCodec, odtPdfCodec, pptxPdfCodec, xlsxPdfCodec };

package/dist/convert/codec.js

@@ -1,5 +1,5 @@
 import { DocxBytesSchema, OdgBytesSchema, OdpBytesSchema, OdsBytesSchema, OdtBytesSchema, PdfBytesSchema, PptxBytesSchema, XlsxBytesSchema } from "../model/bytes.js";
-import { docxToOdt, docxToPdf, odgToPdf, odpToPdf, odpToPptx, odsToPdf, odsToXlsx, odtToDocx, odtToPdf, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOds, pdfToOdt, pdfToPptx, pptxToOdp, pptxToPdf, xlsxToOds } from "./convert.js";
+import { docxToOdt, docxToPdf, odgToPdf, odpToPdf, odpToPptx, odsToPdf, odsToXlsx, odtToDocx, odtToPdf, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOds, pdfToOdt, pdfToPptx, pdfToXlsx, pptxToOdp, pptxToPdf, xlsxToOds, xlsxToPdf } from "./convert.js";
 import { z } from "zod";
 //#region src/convert/codec.ts
 const docxPdfCodec = z.codec(DocxBytesSchema, PdfBytesSchema, {
@@ -26,6 +26,10 @@ const odgPdfCodec = z.codec(OdgBytesSchema, PdfBytesSchema, {
 	decode: (odgBytes) => odgToPdf(odgBytes),
 	encode: (pdfBytes) => pdfToOdg(pdfBytes)
 });
+const xlsxPdfCodec = z.codec(XlsxBytesSchema, PdfBytesSchema, {
+	decode: (xlsxBytes) => xlsxToPdf(xlsxBytes),
+	encode: (pdfBytes) => pdfToXlsx(pdfBytes)
+});
 const odtDocxCodec = z.codec(OdtBytesSchema, DocxBytesSchema, {
 	decode: (odtBytes) => odtToDocx(odtBytes),
 	encode: (docxBytes) => docxToOdt(docxBytes)
@@ -39,4 +43,4 @@ const odsXlsxCodec = z.codec(OdsBytesSchema, XlsxBytesSchema, {
 	encode: (xlsxBytes) => xlsxToOds(xlsxBytes)
 });
 //#endregion
-export { docxPdfCodec, odgPdfCodec, odpPdfCodec, odpPptxCodec, odsPdfCodec, odsXlsxCodec, odtDocxCodec, odtPdfCodec, pptxPdfCodec };
+export { docxPdfCodec, odgPdfCodec, odpPdfCodec, odpPptxCodec, odsPdfCodec, odsXlsxCodec, odtDocxCodec, odtPdfCodec, pptxPdfCodec, xlsxPdfCodec };