documents.js 1.46.1 → 1.47.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 ⇄ PDF conversion, one-directional ods/odg → PDF conversion, a read-and-write live-view editor for docx/pptx/odt/odp/ods/odg content, 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).
+> Bidirectional docx/pptx/odt/odp/odg ⇄ PDF conversion, one-directional ods → PDF conversion, a read-and-write live-view editor for docx/pptx/odt/odp/ods/odg content, 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 entirely hand-written: no external PDF library (`pdf-lib`, `pdfjs-dist`, `mupdf`, or any other) is a dependency. The one exception is [`fflate`](https://github.com/101arrowz/fflate) for raw DEFLATE/zlib compression underneath PDF's `FlateDecode` filter and PNG's `IDAT` chunks — the same dependency `ooxml.js` itself already relies on for ZIP handling.
 
@@ -30,10 +30,10 @@ npm install documents.js
 
 ## Usage
 
-The eight round-trip ergonomic conversions (docx/pptx/odt/odp ⇄ PDF), plus `odsToPdf`/`odgToPdf`'s one-directional additions (there is no `pdfToOds`/`pdfToOdg` yet — the PDF reader's general vector-path tracking both directions need now exists (`src/pdf/interpret.ts`), but the reconstruction algorithms themselves, `reconstructSpreadsheet`/`reconstructDrawing`, are not yet built — see [Gotchas](#gotchas-and-quirks)):
+The nine round-trip ergonomic conversions (docx/pptx/odt/odp/odg ⇄ PDF), plus `odsToPdf`'s one-directional addition (there is no `pdfToOds` yet — the PDF reader's general vector-path tracking that both `pdfToOds` and `pdfToOdg` need now exists (`src/pdf/interpret.ts`), and `pdfToOdg`'s own `reconstructDrawing` already uses it, but the spreadsheet-side reconstruction algorithm, `reconstructSpreadsheet`, is not yet built — see [Gotchas](#gotchas-and-quirks)):
 
 ```ts
-import { docxToPdf, odgToPdf, odpToPdf, odsToPdf, odtToPdf, pdfToDocx, pdfToOdp, pdfToOdt, pptxToPdf, pdfToPptx } from 'documents.js';
+import { docxToPdf, odgToPdf, odpToPdf, odsToPdf, odtToPdf, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOdt, pptxToPdf, pdfToPptx } from 'documents.js';
 
 const pdfBytes = docxToPdf(docxBytes);
 const docxBytes2 = pdfToDocx(pdfBytes);
@@ -47,11 +47,13 @@ const odtBytes2 = pdfToOdt(pdfFromOdt);
 const pdfFromOdp = odpToPdf(odpBytes);
 const odpBytes2 = pdfToOdp(pdfFromOdp);
 
+const pdfFromOdg = odgToPdf(odgBytes);
+const odgBytes2 = pdfToOdg(pdfFromOdg);
+
 const pdfFromOds = odsToPdf(odsBytes); // ods -> PDF only -- there is no pdfToOds yet
-const pdfFromOdg = odgToPdf(odgBytes); // odg -> PDF only -- there is no pdfToOdg yet
 ```
 
-Each accepts an optional `signal` (`AbortSignal`) and either a `onSubstitution` callback (docx/pptx/odt/odp → PDF, called once per character not representable in a standard-14 font) or a `sink` (PDF → docx/pptx/odt/odp, called once per recoverable parse diagnostic).
+Each accepts an optional `signal` (`AbortSignal`) and either a `onSubstitution` callback (docx/pptx/odt/odp/odg → PDF, called once per character not representable in a standard-14 font) or a `sink` (PDF → docx/pptx/odt/odp/odg, called once per recoverable parse diagnostic).
 
 The same conversions behind a swappable port, for a caller that wants to inject a different implementation later without changing call sites:
 
@@ -131,7 +133,7 @@ page.addTextBox({ frame: { xPt: 20, yPt: 200, widthPt: 300, heightPt: 30 }, text
 const bytes = editor.toBytes();
 ```
 
-`buildOdgPackage` bridges a drawing `ContentDocument` (most naturally one from `readOdgContent` itself) to a fresh package built entirely through the same primitives — a standalone bridge like `buildOdsPackage`, not yet a step this package's own conversion pipeline calls (there is no `pdfToOdg` — see [Gotchas](#gotchas-and-quirks)).
+`buildOdgPackage` bridges a drawing `ContentDocument` (either one from `readOdgContent`, or a best-effort one from `reconstructDrawing`) to a fresh package built entirely through the same primitives — `pdfToOdg`'s own package-building half, mirroring `buildOdtPackage`/`buildOdpPackage`'s role for `pdfToOdt`/`pdfToOdp`.
 
 Reading and writing PDF bytes directly, without going through docx/pptx:
 
@@ -142,7 +144,7 @@ const layout = readPdf(pdfBytes); // -> LayoutDocument: pages of positioned text
 const bytes = writePdf(layout);
 ```
 
-The same five round trips (PDF ⇄ `LayoutDocument`, docx ⇄ PDF, pptx ⇄ PDF, odt ⇄ PDF, odp ⇄ PDF) are each also available as a schema-validated [`z.codec()`](https://zod.dev) pair, mirroring `ooxml.js`'s own `packageCodec` — `z.decode`/`z.encode` validate both the raw bytes (against the magic-byte schemas below) and the parsed value (against `LayoutDocumentSchema`) on every call, catching a malformed value that a bare function call wouldn't. This is the no-extra-options form: `readPdf`/`writePdf`/`docxToPdf`/etc. remain the entry points for cancellation (`signal`), diagnostics (`sink`), or substitution reporting (`onSubstitution`), none of which fit `z.codec()`'s fixed `decode(input)`/`encode(output)` signature.
+The same six round trips (PDF ⇄ `LayoutDocument`, docx ⇄ PDF, pptx ⇄ PDF, odt ⇄ PDF, odp ⇄ PDF, odg ⇄ PDF) are each also available as a schema-validated [`z.codec()`](https://zod.dev) pair, mirroring `ooxml.js`'s own `packageCodec` — `z.decode`/`z.encode` validate both the raw bytes (against the magic-byte schemas below) and the parsed value (against `LayoutDocumentSchema`) on every call, catching a malformed value that a bare function call wouldn't. This is the no-extra-options form: `readPdf`/`writePdf`/`docxToPdf`/etc. remain the entry points for cancellation (`signal`), diagnostics (`sink`), or substitution reporting (`onSubstitution`), none of which fit `z.codec()`'s fixed `decode(input)`/`encode(output)` signature.
 
 ```ts
 import { z } from 'zod';
@@ -155,7 +157,7 @@ const pdfFromDocx = z.decode(docxPdfCodec, docxBytes);
 const docxBack = z.encode(docxPdfCodec, pdfFromDocx);
 ```
 
-`readDocxContent`/`readPptxContent`/`readOdtContent`/`readOdpContent`/`readOdsContent`/`readOdgContent` (docx/pptx/odt/odp/ods/odg → `ContentDocument`), `convertWordprocessingToLayout`/`convertPresentationToLayout`/`convertSpreadsheetToLayout`/`convertDrawingToLayout` (`ContentDocument` → `LayoutDocument`), and `reconstructWordprocessing`/`reconstructPresentation` (`LayoutDocument` → `ContentDocument`) are each exported individually too, for a caller that wants one stage of the pipeline without the rest. `readDocxContent` and `readOdtContent` both produce the identical `wordprocessing`-variant `ContentDocument` shape from two completely unrelated package formats (OOXML and ODF), which is what lets `odtToPdf` feed `convertWordprocessingToLayout` without a single line of that engine changing; `readPptxContent` and `readOdpContent` do the same for the `presentation` variant and `convertPresentationToLayout`. `readOdsContent`/`convertSpreadsheetToLayout` and `readOdgContent`/`convertDrawingToLayout` each have no OOXML-side counterpart at all (no `readXlsxContent`/xlsx layout, no drawing-equivalent OOXML format this package reads) — both `convertSpreadsheetToLayout` and `convertDrawingToLayout` are genuinely new layout algorithms, since a spreadsheet's addressed-grid-with-print-settings semantics and a drawing's vector-primitive vocabulary (rect/ellipse/line/path) have no flow/pagination or direct-placement analogue; `convertDrawingToLayout` does still reuse `convertPresentationToLayout`'s own shape-conversion logic (`convertShape`, exported from `src/layout/slides.ts`) verbatim for whatever text/image/table content a drawing page also carries. There is no `reconstructSpreadsheet` or `reconstructDrawing` yet (see [Gotchas](#gotchas-and-quirks)).
+`readDocxContent`/`readPptxContent`/`readOdtContent`/`readOdpContent`/`readOdsContent`/`readOdgContent` (docx/pptx/odt/odp/ods/odg → `ContentDocument`), `convertWordprocessingToLayout`/`convertPresentationToLayout`/`convertSpreadsheetToLayout`/`convertDrawingToLayout` (`ContentDocument` → `LayoutDocument`), and `reconstructWordprocessing`/`reconstructPresentation`/`reconstructDrawing` (`LayoutDocument` → `ContentDocument`) are each exported individually too, for a caller that wants one stage of the pipeline without the rest. `readDocxContent` and `readOdtContent` both produce the identical `wordprocessing`-variant `ContentDocument` shape from two completely unrelated package formats (OOXML and ODF), which is what lets `odtToPdf` feed `convertWordprocessingToLayout` without a single line of that engine changing; `readPptxContent` and `readOdpContent` do the same for the `presentation` variant and `convertPresentationToLayout`. `readOdsContent`/`convertSpreadsheetToLayout` and `readOdgContent`/`convertDrawingToLayout` each have no OOXML-side counterpart at all (no `readXlsxContent`/xlsx layout, no drawing-equivalent OOXML format this package reads) — both `convertSpreadsheetToLayout` and `convertDrawingToLayout` are genuinely new layout algorithms, since a spreadsheet's addressed-grid-with-print-settings semantics and a drawing's vector-primitive vocabulary (rect/ellipse/line/path) have no flow/pagination or direct-placement analogue; `convertDrawingToLayout` does still reuse `convertPresentationToLayout`'s own shape-conversion logic (`convertShape`, exported from `src/layout/slides.ts`) verbatim for whatever text/image/table content a drawing page also carries. `reconstructDrawing` is `reconstructWordprocessing`/`reconstructPresentation`'s drawing-side counterpart, but does no baseline/paragraph clustering at all — a drawing has no semantic structure to recover, only a near-1:1 `LayoutItem` → `ContentVector`/`ContentShape` mapping to make, in the same paint order the items were recovered in. There is no `reconstructSpreadsheet` yet (see [Gotchas](#gotchas-and-quirks)).
 
 ## Architecture
 
@@ -164,15 +166,15 @@ The package is layered from generic primitives outward to the two conversion dir
 - **`src/model/`** — thin, documents.js-specific additions on top of the sibling [`document-content-model`](https://github.com/ExaDev/document-content-model) package, which now owns the two pivot models themselves: `LayoutDocument` (the PDF-side pivot: pages of positioned text/image/rect/line/ellipse/path/link items, PDF-native coordinates and units — `LayoutPath` is a general vector path, one or more subpaths of line/cubic segments sharing one fill/fillRule/stroke, the item kind `writePath`, src/pdf/content-write.ts, turns into PDF `m`/`l`/`c`/`h` content-stream operators) and `ContentDocument` (the semantic pivot: a discriminated union of `wordprocessing`, `presentation`, `spreadsheet`, and `drawing` variants sharing paragraph/run/table/image building blocks, `drawing`'s own `ContentVector` vocabulary — rect/ellipse/line/path — being the vector-primitive counterpart to the shared `ContentShape`) are both imported, not defined here — `document-content-model` exists specifically so `ooxml.js`, `odf.js`, and `documents.js` share one schema instead of each maintaining an independent, drift-prone copy. What remains local: `bytes.ts` (magic-byte-validated `Uint8Array` schemas for docx/pptx/PDF, plus `Odt`/`Ods`/`Odp`/`OdgBytesSchema`, which check the package's actual declared media type against `odf.js`'s `ODF_MEDIA_TYPES` table rather than only the generic ZIP signature the OOXML schemas are limited to), `units.ts` (OOXML EMU/twip/point/half-point conversions), and `geometry.ts`/`color.ts`/`style.ts`, each now mostly a thin re-export of `document-content-model`'s `Box`/`Margins`/`PageSize`/`Color`/`Alignment`/`LayoutFont` — the one genuinely PDF-specific piece each still adds locally is `geometry.ts`'s `flipY` (the top-left/y-down ↔ bottom-left/y-up space conversion between OOXML/ODF and PDF coordinates); `LayoutFont`/`DEFAULT_LAYOUT_FONT` moved to `document-content-model` too (since `LayoutText`, part of the pivot, needs the field), leaving only the standard-14 font *resolution* logic that consumes it (`src/pdf/fonts.ts`/`font-read.ts`) as PDF-specific and local.
 - **`src/bytes/`** and **`src/image/`** — generic byte and image-container primitives with zero PDF or OOXML knowledge: a chunked byte writer, a backtracking byte reader, CRC32, and a hand-written PNG decoder/encoder (palette/gray/RGB/alpha, multi-`IDAT` files, all five scanline filters) plus JPEG marker scanning for dimensions only — JPEG's compressed bytes pass through completely unchanged in both directions. `src/bytes/flate.ts` is the only file that imports `fflate`, mirroring how `ooxml.js`'s own `src/zip.ts` wraps it for ZIP handling.
 - **`src/xml/`** and **`src/opc/`** — parent-aware XML query/mutation and OPC package mechanics (relationship IDs, content-type entries, atomic media-part insertion) built over `ooxml.js`'s `Package`/`XmlNode`, needed because `ooxml.js`'s own XML nodes have no parent pointers and `ooxml.js` never writes new parts into an existing package.
-- **`src/edit/`** — the read-and-write editable model: live-view classes (`DocxEditor`/`DocxParagraph`/`DocxRun`/`DocxTable`, `PptxEditor`/`PptxSlide`/`PptxShape`, `OdtEditor`/`OdtParagraph`/`OdtRun`/`OdtTable`/`OdtList`, `OdpEditor`/`OdpSlide`/`OdpShape`, `OdsEditor`/`OdsSheet`/`OdsCell`, `OdgEditor`/`OdgPage`/`OdgBoxVector`/`OdgLineVector`/`OdgPathVector`) wrapping the actual `XmlElement` objects inside a decoded `Package`, plus `buildDocxPackage`/`buildPptxPackage`/`buildOdtPackage`/`buildOdpPackage`/`buildOdsPackage`/`buildOdgPackage` bridging a `ContentDocument` to a fresh package built entirely through those same primitives (there is no `pdfToOds`/`pdfToOdg` calling `buildOdsPackage`/`buildOdgPackage` yet, though — see below). `src/edit/odp/*` reuses `src/edit/odt/*`'s own paragraph/run/list/style-interning classes WHOLESALE rather than reimplementing them for presentations: a `draw:frame`'s `draw:text-box` holds the identical `text:p`/`text:span` content model `office:text` does, interned into the identical `content.xml` `office:automatic-styles` registry (`src/edit/odt/props.ts`'s `applyStyleChange`) — `OdpShape.appendParagraph`/`.paragraphs()`/`.addList()` return real `OdtParagraph`/`OdtList` instances, not odp-specific lookalikes. The genuinely new odp-specific work is `draw:page`/`draw:frame` mechanics (a slide is a `draw:page`, a shape's geometry is explicit `svg:x`/`svg:y`/`svg:width`/`svg:height` rather than pptx's placeholder-inheritance-heavy model) and rotation: `OdpShape.rotationDeg` is a genuine `draw:transform` setter built on `odf.js`'s own `applyOdfTransform`/`resolveOdfShapeGeometry` (`typed/shared/transform.ts`) — the write-side inverse of the exact function odf.js's own reader uses — unlike `PptxShape`, which has no rotation setter yet (see Gotchas below). `src/edit/ods/*` has no docx/pptx/odt/odp analogue to reuse for its core concern (cell addressing) but still reuses `src/edit/odt/*`'s style interning and `src/edit/odt/content.ts`'s `populateParagraph` for cell text content — `src/edit/ods/address.ts` is the write-side counterpart to `odf.js`'s own read-side `table:number-*-repeated`-aware cursor: setting a distant cell's value splits the covering repeated run in place at that one position rather than materialising every cell in between, exactly mirroring the read-side hazard `odf.js`'s own `typed/shared/a1.ts` already solved. `src/edit/odg/*` reuses `OdpShape`/`buildTextBoxFrame`/`insertImageFrameMedia` WHOLESALE for `draw:frame` text/image content (a drawing page's `draw:frame` content model and geometry resolution — rotation included — are byte-for-byte identical to a presentation's, both resolved through `odf.js`'s own shared `readDrawFrame`), so there is no separate `OdgShape` class at all; the genuinely new work is the vector-primitive classes (no rotation, a per-kind attribute vocabulary: `svg:x`/`y`/`width`/`height` for rect/ellipse/path, `svg:x1`/`y1`/`x2`/`y2` for a line) and their own fill/stroke, which needed a small, self-contained graphic-family style writer (`src/edit/odg/style.ts`) since `odf.js`'s own `StyleRegistry` recognises `'graphic'` as a style family but its `StylePropertiesSchema` only ever models text/paragraph formatting — it has no fill/stroke fields and never emits a `style:graphic-properties` element. A path vector's own `svg:d` is generated by `src/edit/odg/svg-path.ts`, the write-side inverse of `odf.js`'s own `typed/shared/path.ts` parser — always absolute, always space-separated commands, anchoring `svg:viewBox` at `"0 0 {widthPt} {heightPt}"` so the written numbers are the exact source `ContentPathPoint` values with no rescaling arithmetic either way (see Gotchas below for the cross-check against that exact parser).
+- **`src/edit/`** — the read-and-write editable model: live-view classes (`DocxEditor`/`DocxParagraph`/`DocxRun`/`DocxTable`, `PptxEditor`/`PptxSlide`/`PptxShape`, `OdtEditor`/`OdtParagraph`/`OdtRun`/`OdtTable`/`OdtList`, `OdpEditor`/`OdpSlide`/`OdpShape`, `OdsEditor`/`OdsSheet`/`OdsCell`, `OdgEditor`/`OdgPage`/`OdgBoxVector`/`OdgLineVector`/`OdgPathVector`) wrapping the actual `XmlElement` objects inside a decoded `Package`, plus `buildDocxPackage`/`buildPptxPackage`/`buildOdtPackage`/`buildOdpPackage`/`buildOdsPackage`/`buildOdgPackage` bridging a `ContentDocument` to a fresh package built entirely through those same primitives (`pdfToOdg` now calls `buildOdgPackage`; there is no `pdfToOds` calling `buildOdsPackage` yet, though — see below). `src/edit/odp/*` reuses `src/edit/odt/*`'s own paragraph/run/list/style-interning classes WHOLESALE rather than reimplementing them for presentations: a `draw:frame`'s `draw:text-box` holds the identical `text:p`/`text:span` content model `office:text` does, interned into the identical `content.xml` `office:automatic-styles` registry (`src/edit/odt/props.ts`'s `applyStyleChange`) — `OdpShape.appendParagraph`/`.paragraphs()`/`.addList()` return real `OdtParagraph`/`OdtList` instances, not odp-specific lookalikes. The genuinely new odp-specific work is `draw:page`/`draw:frame` mechanics (a slide is a `draw:page`, a shape's geometry is explicit `svg:x`/`svg:y`/`svg:width`/`svg:height` rather than pptx's placeholder-inheritance-heavy model) and rotation: `OdpShape.rotationDeg` is a genuine `draw:transform` setter built on `odf.js`'s own `applyOdfTransform`/`resolveOdfShapeGeometry` (`typed/shared/transform.ts`) — the write-side inverse of the exact function odf.js's own reader uses — unlike `PptxShape`, which has no rotation setter yet (see Gotchas below). `src/edit/ods/*` has no docx/pptx/odt/odp analogue to reuse for its core concern (cell addressing) but still reuses `src/edit/odt/*`'s style interning and `src/edit/odt/content.ts`'s `populateParagraph` for cell text content — `src/edit/ods/address.ts` is the write-side counterpart to `odf.js`'s own read-side `table:number-*-repeated`-aware cursor: setting a distant cell's value splits the covering repeated run in place at that one position rather than materialising every cell in between, exactly mirroring the read-side hazard `odf.js`'s own `typed/shared/a1.ts` already solved. `src/edit/odg/*` reuses `OdpShape`/`buildTextBoxFrame`/`insertImageFrameMedia` WHOLESALE for `draw:frame` text/image content (a drawing page's `draw:frame` content model and geometry resolution — rotation included — are byte-for-byte identical to a presentation's, both resolved through `odf.js`'s own shared `readDrawFrame`), so there is no separate `OdgShape` class at all; the genuinely new work is the vector-primitive classes (no rotation, a per-kind attribute vocabulary: `svg:x`/`y`/`width`/`height` for rect/ellipse/path, `svg:x1`/`y1`/`x2`/`y2` for a line) and their own fill/stroke, which needed a small, self-contained graphic-family style writer (`src/edit/odg/style.ts`) since `odf.js`'s own `StyleRegistry` recognises `'graphic'` as a style family but its `StylePropertiesSchema` only ever models text/paragraph formatting — it has no fill/stroke fields and never emits a `style:graphic-properties` element. A path vector's own `svg:d` is generated by `src/edit/odg/svg-path.ts`, the write-side inverse of `odf.js`'s own `typed/shared/path.ts` parser — always absolute, always space-separated commands, anchoring `svg:viewBox` at `"0 0 {widthPt} {heightPt}"` so the written numbers are the exact source `ContentPathPoint` values with no rescaling arithmetic either way (see Gotchas below for the cross-check against that exact parser).
 - **`src/pdf/`** — the hand-written PDF codec, importing only `model`/`bytes`/`image` (no OOXML knowledge at all):
   - **Write**: `objects.ts` (the `PdfObject` discriminated union), `afm-widths.ts`/`encoding.ts`/`winansi.ts`/`fonts.ts` (standard-14 metrics, WinAnsi encoding, family resolution), `measure.ts`/`text-layout.ts` (greedy line-wrapping), `matrix.ts`, `content-write.ts` (`LayoutItem[]` → content-stream operators), `write.ts` (the full object graph, classic cross-reference table, trailer).
   - **Read**: `lexer.ts`/`parse.ts` (byte tokenizer and tokens → `PdfObject`), `filters.ts`/`predictors.ts` (Flate/LZW/ASCII85/ASCIIHex/RunLength, TIFF/PNG predictors), `xref.ts`/`document.ts` (classic and cross-reference-stream resolution, object streams, `/Prev` chains, linear-scan recovery, the page tree with attribute inheritance), `content-read.ts`/`interpret.ts` (the content-stream tokenizer and graphics/text state machine, including form-XObject recursion), `cmap.ts`/`font-style.ts`/`font-read.ts` (`/ToUnicode` CMaps, font-dictionary resolution), `images-read.ts` (Image XObjects → PNG/JPEG bytes), `read.ts` (`readPdf`, assembling all of the above into a `LayoutDocument`).
   - `codec.ts` — `pdfCodec`, a `z.codec()` pair over `readPdf`/`writePdf` (PDF bytes ⇄ `LayoutDocument`).
 - **`src/ooxml/`** — resolves a `Package` into a `ContentDocument`: `docx/read.ts` and `pptx/read.ts` are now thin adapters over `ooxml.js`'s own `readDocx`/`readPptx`, wrapping their `{ metadata, sections }`/`{ metadata, slides }` result into `ContentDocument`'s `wordprocessing`/`presentation` shape. The docx style cascade (`docDefaults` → named-style `basedOn` chains → paragraph-mark run properties → character styles → direct formatting), the pptx placeholder → layout → master → theme inheritance cascade, and DrawingML geometry/colour resolution all now live upstream in `ooxml.js` itself, not in this package.
-- **`src/odf/`** — the ODF-side counterpart to `src/ooxml/`, resolving an `odf.js` `Package` into a `ContentDocument`: `odt/read.ts`'s `readOdtContent` is a thin adapter over `odf.js`'s own `readOdt`, wrapping its `{ metadata, sections }` result into the identical `wordprocessing` shape `readDocxContent` produces — the concrete proof that odt and docx genuinely share one pivot and one layout engine. `odp/read.ts`'s `readOdpContent` is the same adapter over `odf.js`'s `readOdp`, wrapping `{ metadata, slides }` into the identical `presentation` shape `readPptxContent` produces. `ods/read.ts`'s `readOdsContent` wraps `odf.js`'s `readOds`'s `{ metadata, sheets }` into the `spreadsheet` `ContentDocument` variant, and `odg/read.ts`'s `readOdgContent` wraps `odf.js`'s `readOdg`'s `{ metadata, pages }` into the `drawing` variant — neither has an OOXML-side sibling adapter (there is no `readXlsxContent`, and no drawing-equivalent OOXML format this package reads at all). `buildOdtPackage`/`buildOdpPackage`/`buildOdsPackage`/`buildOdgPackage` (`src/edit/{odt,odp,ods,odg}/content.ts`) each bridge a `ContentDocument` back to a fresh package built on that format's own live-view editor: odt/odp's close the PDF → odt/odp direction (`pdfToOdt`/`pdfToOdp` call them); ods's and odg's exist and are exported, live-view editor included, but nothing calls either yet — see the `pdfToOds`/`pdfToOdg` gotcha below.
-- **`src/layout/`** — the pure conversion algorithms, importing only `model` (no I/O): `engine.ts` (`ContentDocument` wordprocessing → `LayoutDocument`: flow, line-breaking, pagination — fed identically by docx- and odt-sourced content), `slides.ts` (`ContentDocument` presentation → `LayoutDocument`: direct EMU-to-point placement, no pagination needed — fed identically by pptx- and odp-sourced content; also exports `convertShape`, the single-`ContentShape`-to-`LayoutItem[]` conversion `drawing.ts` below reuses verbatim), `sheets.ts` (`ContentDocument` spreadsheet → `LayoutDocument`: resolve the print range, build cumulative column/row offsets skipping hidden ones, reserve header/repeat-row-column space, resolve an explicit or non-iterative fit-to-page scale, partition into column/row bands honouring manual breaks with the same "an oversized item gets its own band and overflows rather than looping" guarantee `engine.ts`'s `ensureRoom` documents, emit pages in `downThenOver`/`overThenDown` order, then per page paint backgrounds/gridlines/headers/cell text with default alignment by value kind and `###`/spill-then-truncate overflow handling — the first layout algorithm in this package that accepts an `AbortSignal`, since a 50k-cell sheet needs cancellation where a docx/pptx page count never did), `drawing.ts` (`ContentDocument` drawing → `LayoutDocument`: one `ContentDrawPage` per PDF page, direct placement like `slides.ts`, with one new emission path — a `ContentVector` `rect`/`ellipse`/`line` maps onto the pre-existing `LayoutRect`/`LayoutEllipse`/`LayoutLine` kinds, and a `path` vector's local, viewBox-relative subpath points are resolved through the vector's own frame offset then a single page-space flip into a `LayoutPath` value; vectors paint before shapes, a documented, bounded choice — see this module's own top-of-file note — since `ContentDrawPageSchema` keeps `shapes` and `vectors` as two independently paint-ordered arrays with no field recording their relative order when the two genuinely overlap), `reconstruct.ts` (`LayoutDocument` → `ContentDocument`, wordprocessing and presentation only — no `reconstructSpreadsheet`/`reconstructDrawing` yet, see Gotchas: baseline-proximity line clustering, then paragraph/text-block clustering from geometry — PDF has no semantic paragraph or shape structure to recover, only positioned glyphs).
-- **`src/convert/`** — `convert.ts` (the eight round-trip ergonomic wrappers plus `odsToPdf`/`odgToPdf`'s one-directional ninth and tenth), `codec.ts` (`docxPdfCodec`/`pptxPdfCodec`/`odtPdfCodec`/`odpPdfCodec`, a `z.codec()` pair over each — deliberately no `odsPdfCodec`/`odgPdfCodec` yet, matching this package's own established rule that a codec needs both a genuine `decode` and `encode` half, and `odsToPdf`/`odgToPdf` alone each have no `pdfToOds`/`pdfToOdg` to encode with), `port.ts`/`local.ts` (the swappable `DocumentConverter` contract and its synchronous local implementation, covering `docx`/`pptx`/`odt`/`odp`/`ods`/`odg` → `pdf` and `pdf` → `docx`/`pptx`/`odt`/`odp`).
+- **`src/odf/`** — the ODF-side counterpart to `src/ooxml/`, resolving an `odf.js` `Package` into a `ContentDocument`: `odt/read.ts`'s `readOdtContent` is a thin adapter over `odf.js`'s own `readOdt`, wrapping its `{ metadata, sections }` result into the identical `wordprocessing` shape `readDocxContent` produces — the concrete proof that odt and docx genuinely share one pivot and one layout engine. `odp/read.ts`'s `readOdpContent` is the same adapter over `odf.js`'s `readOdp`, wrapping `{ metadata, slides }` into the identical `presentation` shape `readPptxContent` produces. `ods/read.ts`'s `readOdsContent` wraps `odf.js`'s `readOds`'s `{ metadata, sheets }` into the `spreadsheet` `ContentDocument` variant, and `odg/read.ts`'s `readOdgContent` wraps `odf.js`'s `readOdg`'s `{ metadata, pages }` into the `drawing` variant — neither has an OOXML-side sibling adapter (there is no `readXlsxContent`, and no drawing-equivalent OOXML format this package reads at all). `buildOdtPackage`/`buildOdpPackage`/`buildOdsPackage`/`buildOdgPackage` (`src/edit/{odt,odp,ods,odg}/content.ts`) each bridge a `ContentDocument` back to a fresh package built on that format's own live-view editor: odt/odp/odg's close the PDF → odt/odp/odg direction (`pdfToOdt`/`pdfToOdp`/`pdfToOdg` call them); ods's exists and is exported, live-view editor included, but nothing calls it yet — see the `pdfToOds` gotcha below.
+- **`src/layout/`** — the pure conversion algorithms, importing only `model` (no I/O): `engine.ts` (`ContentDocument` wordprocessing → `LayoutDocument`: flow, line-breaking, pagination — fed identically by docx- and odt-sourced content), `slides.ts` (`ContentDocument` presentation → `LayoutDocument`: direct EMU-to-point placement, no pagination needed — fed identically by pptx- and odp-sourced content; also exports `convertShape`, the single-`ContentShape`-to-`LayoutItem[]` conversion `drawing.ts` below reuses verbatim), `sheets.ts` (`ContentDocument` spreadsheet → `LayoutDocument`: resolve the print range, build cumulative column/row offsets skipping hidden ones, reserve header/repeat-row-column space, resolve an explicit or non-iterative fit-to-page scale, partition into column/row bands honouring manual breaks with the same "an oversized item gets its own band and overflows rather than looping" guarantee `engine.ts`'s `ensureRoom` documents, emit pages in `downThenOver`/`overThenDown` order, then per page paint backgrounds/gridlines/headers/cell text with default alignment by value kind and `###`/spill-then-truncate overflow handling — the first layout algorithm in this package that accepts an `AbortSignal`, since a 50k-cell sheet needs cancellation where a docx/pptx page count never did), `drawing.ts` (`ContentDocument` drawing → `LayoutDocument`: one `ContentDrawPage` per PDF page, direct placement like `slides.ts`, with one new emission path — a `ContentVector` `rect`/`ellipse`/`line` maps onto the pre-existing `LayoutRect`/`LayoutEllipse`/`LayoutLine` kinds, and a `path` vector's local, viewBox-relative subpath points are resolved through the vector's own frame offset then a single page-space flip into a `LayoutPath` value; vectors paint before shapes, a documented, bounded choice — see this module's own top-of-file note — since `ContentDrawPageSchema` keeps `shapes` and `vectors` as two independently paint-ordered arrays with no field recording their relative order when the two genuinely overlap), `reconstruct.ts` (`LayoutDocument` → `ContentDocument`: `reconstructWordprocessing`/`reconstructPresentation` do baseline-proximity line clustering, then paragraph/text-block clustering from geometry — PDF has no semantic paragraph or shape structure to recover, only positioned glyphs; `reconstructDrawing` does no clustering at all, since a drawing has no such structure to infer in the first place — every `LayoutItem` maps close to 1:1 back onto a `ContentVector` `rect`/`ellipse`/`line`/`path` or a `ContentShape`, in the exact z-order it was painted, bucketed into `ContentDrawPageSchema`'s own two independently-ordered `shapes`/`vectors` arrays the same way `drawing.ts` produced them. No `reconstructSpreadsheet` yet, see Gotchas).
+- **`src/convert/`** — `convert.ts` (the nine round-trip ergonomic wrappers plus `odsToPdf`'s one-directional tenth), `codec.ts` (`docxPdfCodec`/`pptxPdfCodec`/`odtPdfCodec`/`odpPdfCodec`/`odgPdfCodec`, a `z.codec()` pair over each — deliberately no `odsPdfCodec` yet, matching this package's own established rule that a codec needs both a genuine `decode` and `encode` half, and `odsToPdf` alone has no `pdfToOds` to encode with), `port.ts`/`local.ts` (the swappable `DocumentConverter` contract and its synchronous local implementation, covering `docx`/`pptx`/`odt`/`odp`/`ods`/`odg` → `pdf` and `pdf` → `docx`/`pptx`/`odt`/`odp`/`odg`).
 
 Dependency direction is strictly downward and checkable: `model`/`bytes` import nothing local; `image` imports `bytes` only; `pdf` imports `model`+`bytes`+`image` only; `ooxml/*` imports `xml`/`model` only (no PDF knowledge); `odf/*` imports `model` only (no PDF knowledge, no `xml/*` — `odf.js` already owns its own XML query helpers); `layout` imports `model` only; `convert` composes everything else. No `PdfObject`/`PdfDict`/`PdfStream` type appears outside `src/pdf/`.
 
@@ -184,7 +186,7 @@ pnpm typecheck     # tsc --noEmit
 pnpm lint          # eslint . --max-warnings 0
 pnpm test          # vitest run --project unit
 pnpm test:watch    # vitest --project unit
-pnpm test:smoke    # rebuilds dist/, then verifies ESM/CJS parity, a real docxToPdf/pdfToDocx round trip, real odtToPdf/odpToPdf/odsToPdf/odgToPdf conversions (odgToPdf's own fixture carries a real curved path, proving writePath reaches the built dist/ bundle), a real createOdp/odpToPdf/pdfToOdp round trip, and a real createOdg/odgToPdf/buildOdgPackage exercise (a curved path, a filled rect, and text, built entirely through the odg live-view editor), from the built CJS bundle
+pnpm test:smoke    # rebuilds dist/, then verifies ESM/CJS parity, a real docxToPdf/pdfToDocx round trip, real odtToPdf/odpToPdf/odsToPdf/odgToPdf conversions (odgToPdf's own fixture carries a real curved path, proving writePath reaches the built dist/ bundle), a real createOdp/odpToPdf/pdfToOdp round trip, and a real createOdg/odgToPdf/pdfToOdg round trip (a curved path, a filled rect, and text, built entirely through the odg live-view editor, converted to PDF and reconstructed back to odg via reconstructDrawing), from the built CJS bundle
 pnpm test:corpus   # optional real-world PDF conformance checks against a local, gitignored test/corpus/ (see Fidelity)
 ```
 
@@ -193,7 +195,7 @@ To run a single test file: `pnpm vitest run src/path/to/file.test.ts`.
 ## Conventions
 
 - **Zod-first schema/type/guard**, matching `ooxml.js`: every model type is inferred from its Zod schema, never hand-written. `ContentBlock` (recursive, mirroring `ooxml.js`'s own `XmlNode` treatment) uses a hand-written structural guard + `z.custom`, not `z.lazy`, which collapses to `unknown` for recursive element-children in the pinned Zod version.
-- **`z.codec()` for every schema-to-schema round trip**, matching `ooxml.js`'s `packageCodec`/`xmlCodec`: `pdfCodec` (PDF bytes ⇄ `LayoutDocument`) and `docxPdfCodec`/`pptxPdfCodec`/`odtPdfCodec`/`odpPdfCodec` (docx/pptx/odt/odp bytes ⇄ PDF bytes) each wrap an already-independently-tested function pair, adding automatic two-way schema validation. These are deliberately the no-options form — `readPdf`/`writePdf`/`docxToPdf`/`pdfToDocx`/`pptxToPdf`/`pdfToPptx`/`odtToPdf`/`pdfToOdt`/`odpToPdf`/`pdfToOdp` remain the primary entry points wherever a caller needs an `AbortSignal`, a `PdfDiagnosticSink`, or an `onSubstitution` callback, since `z.codec()`'s fixed `decode(input)`/`encode(output)` signature has no room for side-channel options.
+- **`z.codec()` for every schema-to-schema round trip**, matching `ooxml.js`'s `packageCodec`/`xmlCodec`: `pdfCodec` (PDF bytes ⇄ `LayoutDocument`) and `docxPdfCodec`/`pptxPdfCodec`/`odtPdfCodec`/`odpPdfCodec`/`odgPdfCodec` (docx/pptx/odt/odp/odg bytes ⇄ PDF bytes) each wrap an already-independently-tested function pair, adding automatic two-way schema validation. These are deliberately the no-options form — `readPdf`/`writePdf`/`docxToPdf`/`pdfToDocx`/`pptxToPdf`/`pdfToPptx`/`odtToPdf`/`pdfToOdt`/`odpToPdf`/`pdfToOdp`/`odgToPdf`/`pdfToOdg` remain the primary entry points wherever a caller needs an `AbortSignal`, a `PdfDiagnosticSink`, or an `onSubstitution` callback, since `z.codec()`'s fixed `decode(input)`/`encode(output)` signature has no room for side-channel options.
 - **`PdfObject` has no Zod schema at all**, deliberately: it never crosses a public boundary or round-trips through JSON, and is constructed exclusively by this package's own parser — validating it would just be validating our own output. It narrows natively on its own `kind` discriminant instead, the same reasoning `ooxml.js` applies when it picks a hand-written `isXmlNode` guard over `z.lazy`.
 - **No type assertions anywhere.** Every third-party or loosely-typed value is narrowed through a type guard or a Zod parse at the boundary.
 - **Live views, not flatten-and-regenerate.** `src/edit/*`'s editor classes hold a reference directly into the real `Package`/`XmlElement` objects; saving is `encodePackage(pkg)`, nothing more. This is what makes "everything you didn't touch stays byte-faithful" a structural guarantee rather than a best effort.
@@ -206,14 +208,15 @@ To run a single test file: `pnpm vitest run src/path/to/file.test.ts`.
 - **The docx⇄PDF and pptx⇄PDF conversions are explicitly not round-trip-lossless** — in deliberate contrast to `ooxml.js`'s own `packageCodec`, which is byte/part-faithful by design. See [Fidelity](#fidelity).
 - **`odpToPdf`/`pdfToOdp` needed zero new layout code.** `readOdpContent` (`src/odf/odp/read.ts`) produces the identical `presentation` `ContentDocument` shape `readPptxContent` does, so it feeds `convertPresentationToLayout` unmodified — including the existing hidden-annotation speaker-notes mechanism below, which carries odp's `presentation:notes` through to the PDF with no new notes-handling code at all; `pdfToOdp` reuses `reconstructPresentation` unmodified too, the same architectural bet `pdfToOdt` already proved for `reconstructWordprocessing`. The genuinely new work for the reverse direction was the live-view editor itself (`src/edit/odp/*`) — see Architecture above.
 - **`OdpShape.rotationDeg` writes a real `draw:transform`, built on `odf.js`'s own transform machinery.** It is the write-side inverse of `odf.js`'s `resolveOdfShapeGeometry` (`typed/shared/transform.ts`), built on that module's own exported `applyOdfTransform` rather than a hand-rolled rotation matrix, so it inherits that module's own empirically-verified rotate/translate composition order and sign convention by construction. Unlike `PptxShape` (see the `colSpan`/`rowSpan` gotcha below, which pptx still has and odp does not), `buildOdpPackage` writes a rotated shape's rotation back correctly — verified both by this package's own tests and by opening a fresh, editor-built `.odp` in actual LibreOffice.
-- **`src/pdf/interpret.ts` now tracks general vector paths, not just axis-aligned `re` rectangles.** `m`/`l`/`c`/`v`/`y`/`h` (and `re` itself, per its own ISO 32000-1 definition as a 4-point rectangle subpath) accumulate real subpaths — CTM-transformed line/cubic segments, open or closed — and any paint operator (`f`/`F`/`f*`/`S`/`s`/`B`/`B*`/`b`/`b*`) emits a `LayoutPath` item when the path isn't reducible to the simple single-`re`-on-an-axis-aligned-CTM case (which still takes the original, unchanged `LayoutRect` fast path). Verified both by dedicated tests and by a genuine `writePath` → `writePdf` → `readPdf` round trip recovering the original `LayoutPath` value exactly. This is the shared infrastructure both `pdfToOds` and `pdfToOdg` below need — it exists now, but neither conversion function itself does yet.
+- **`src/pdf/interpret.ts` now tracks general vector paths, not just axis-aligned `re` rectangles.** `m`/`l`/`c`/`v`/`y`/`h` (and `re` itself, per its own ISO 32000-1 definition as a 4-point rectangle subpath) accumulate real subpaths — CTM-transformed line/cubic segments, open or closed — and any paint operator (`f`/`F`/`f*`/`S`/`s`/`B`/`B*`/`b`/`b*`) emits a `LayoutPath` item when the path isn't reducible to the simple single-`re`-on-an-axis-aligned-CTM case (which still takes the original, unchanged `LayoutRect` fast path). Verified both by dedicated tests and by a genuine `writePath` → `writePdf` → `readPdf` round trip recovering the original `LayoutPath` value exactly. This is the shared infrastructure both `pdfToOds` and `reconstructDrawing` need; `reconstructDrawing` now uses it (`pdfToOdg` exists — see the `reconstructDrawing` gotcha below), `pdfToOds` still doesn't.
 - **`odsToPdf` is one-directional — there is no `pdfToOds` yet, and no `reconstructSpreadsheet`.** The PDF-side blocker (general vector-path tracking, needed to detect a reconstructed sheet's gridlines from recovered geometry) is resolved — see the `interpret.ts` gotcha above. What's still missing is `reconstructSpreadsheet` itself: the actual gridline-detection/text-clustering-into-a-grid algorithm. `buildOdsPackage` (`src/edit/ods/content.ts`) is built and exported, ready for `pdfToOds` to call the moment that algorithm lands; nothing currently calls it.
-- **`odgToPdf` is one-directional — there is no `pdfToOdg`, and no `reconstructDrawing`, even though the odg live-view editor and `buildOdgPackage` both now exist.** The PDF-side blocker (general vector-path tracking) is resolved — see the `interpret.ts` gotcha above. What's still missing is `reconstructDrawing` itself: mapping recovered `LayoutRect`/`LayoutPath`/`LayoutText`/`LayoutImage` geometry back onto ODF shapes (which recovered path is a rect vs. a genuine curve, where one shape ends and another begins) — a fundamentally different, unstarted problem from `reconstructWordprocessing`/`reconstructPresentation`'s own paragraph/shape geometry clustering, though genuinely more tractable since a drawing has no semantic structure to infer, only shapes to map near-1:1. `buildOdgPackage` (`src/edit/odg/content.ts`) is built and exported, ready for `pdfToOdg` to call the moment that algorithm lands; nothing currently calls it, mirroring `buildOdsPackage`'s own identical situation.
+- **`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: `src/pdf/interpret.ts`'s `LayoutRect` fast path only fires for a fill-only rectangle under a non-rotated CTM (see the `interpret.ts` 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` (`src/pdf/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.
 - **A path vector's own `svg:d` is cross-checked against `odf.js`'s real parser, not merely asserted to "look plausible".** `src/edit/odg/svg-path.ts`'s `buildSvgPathData` is the write-side inverse of `odf.js`'s `parseOdfPathData`; `OdgPathVector.subpaths` re-derives its value by reparsing the actual written `svg:viewBox`/`svg:d` through that exact function (plus `parseOdfViewBox`/`buildOdfSubpaths`) on every read, rather than echoing back whatever `ContentSubpath[]` the caller originally passed to `addPath` — so every read is itself a live round-trip proof, and this module's own test suite additionally feeds `buildSvgPathData`'s output straight into `parseOdfPathData` to confirm point-for-point recovery.
 - **A newly added vector/shape's paint order is expressed purely as document order, with no `draw:z-index` ever written.** This matches `odf.js`'s own reader-side convention exactly (`typed/draw/shapes.ts`'s `paintOrderKey`: honour an explicit `draw:z-index` when present, otherwise fall back to document order — and real LibreOffice output never emits one, it reorders elements instead), so `OdgPage.addRect`/`addEllipse`/`addLine`/`addPath`/`addTextBox`/`addImage` simply append to `draw:page`'s own children in call order and nothing more is needed for a later `add*` call to paint in front of an earlier one.
 - **`LayoutPathSchema` (`document-content-model`) has no quadratic or elliptical-arc segment kind, deliberately — not a scope gap that happens to be unfilled.** `writePath` (`src/pdf/content-write.ts`) therefore has no quadratic-to-cubic elevation and no SVG-arc-to-cubic endpoint-to-centre parameterization anywhere in it: `odf.js`'s own real-LibreOffice-output-verified `svg:d` parser (`typed/shared/path.ts`) recognises `S`/`s`/`Q`/`q`/`T`/`t`/`A`/`a` as command letters (so its own token stream stays in sync) but produces no segment for any of them — real LibreOffice output for rectangles, ellipses, freeform curves, and basic custom-shape presets never emits a quadratic or an arc in the first place, only `M`/`L`/`H`/`V`/`C`/`Z`. Building unused quadratic/arc conversion code against a segment kind that can never occur would be speculative, not root-cause work.
-- **A drawing page's `shapes` and `vectors` paint in two independently-ordered arrays, with no field recording their relative order.** `ContentDrawPageSchema` (`document-content-model`) keeps text/image/table content (`shapes`) and vector primitives (`vectors`) as two separate arrays, each correctly paint-ordered on its own by `odf.js`'s own reader (honouring a real `draw:z-index` when present, falling back to document order otherwise) — but there is no shared ordering field between the two arrays at all, a real, tracked gap in the shared schema, not something `convertDrawingToLayout` can reconstruct after the fact. `convertDrawingToLayout` resolves it with one fixed, documented choice: every vector paints before every shape (vectors are the common "diagram" content in a real `.odg`; shapes are far more often text labels layered on top of them than the reverse). A page that genuinely interleaves the two mid-stack will not paint in true document z-order until the schema itself grows a shared field.
+- **A drawing page's `shapes` and `vectors` paint in two independently-ordered arrays, with no field recording their relative order.** `ContentDrawPageSchema` (`document-content-model`) keeps text/image/table content (`shapes`) and vector primitives (`vectors`) as two separate arrays, each correctly paint-ordered on its own by `odf.js`'s own reader (honouring a real `draw:z-index` when present, falling back to document order otherwise) — but there is no shared ordering field between the two arrays at all, a real, tracked gap in the shared schema, not something `convertDrawingToLayout` can reconstruct after the fact. `convertDrawingToLayout` resolves it with one fixed, documented choice: every vector paints before every shape (vectors are the common "diagram" content in a real `.odg`; shapes are far more often text labels layered on top of them than the reverse). A page that genuinely interleaves the two mid-stack will not paint in true document z-order until the schema itself grows a shared field. `reconstructDrawing` resolves the identical gap in reverse the same way: it buckets each recovered `LayoutItem` into `vectors` or `shapes` by kind while walking the page once in overall paint order, so each array keeps its own items' relative order — which reproduces a `convertDrawingToLayout`-produced page's original paint order exactly (vectors-then-shapes, by construction), and is still the best either array's own shape is able to express for a `LayoutDocument` from any other producer.
 - **A vector primitive's own rotation is never read at all.** None of `ContentVectorSchema`'s variants carry a rotation field, unlike `ContentShapeSchema` — `readOdgContent`'s underlying `odf.js` reader deliberately discards a `draw:rect`/`draw:ellipse`/`draw:custom-shape`'s own rotation, so it reads (and `convertDrawingToLayout` places) at its unrotated bounding frame. A real, tracked model limitation inherited from `odf.js`, not something this package's own layout code introduces.
 - **`ContentVector`'s `path` variant's `fillRule` is never populated by the reader — always `undefined`, which `writePath` treats as nonzero.** `odf.js`'s `readDrawPathVector` does not currently resolve an evenodd fill rule from real ODF output, so every path this pipeline reads paints with PDF's default nonzero winding rule. `LayoutPathSchema`/`writePath` fully support `fillRule: 'evenodd'` regardless — a caller constructing a `LayoutPath` (or a future `ContentVector` producer) directly can still set it; it just never arrives via `odgToPdf` today.
 - **`ContentSheetCellSchema` (`document-content-model`) models no per-cell border or background, and no per-cell alignment override** — unlike `ContentTableCellSchema.background`. `sheets.ts`'s cell-background and cell-border z-order steps are consequently skipped entirely (no dead placeholder code), and cell text alignment always falls back to the value-kind default (numeric right, boolean/error centre, string left) since there is nothing to override it with. A tracked, documented gap, not a silent one.
@@ -233,7 +236,9 @@ To run a single test file: `pnpm vitest run src/path/to/file.test.ts`.
 
 **PDF → docx/pptx/odt/odp** is necessarily a **best-effort reconstruction** from geometry: a PDF page is just positioned glyphs and images, with no semantic paragraph or shape structure to recover. Reading order, bold/italic/colour/font-size, and page/slide count are preserved; paragraph and text-block boundaries are inferred from baseline spacing and left-margin indentation, not recovered exactly.
 
-Neither direction is round-trip-lossless, and the two conversions are not inverses of each other — `pdfToDocx(docxToPdf(x))` will not reproduce `x` exactly, and is not intended to. This is a deliberate, permanent contrast with `ooxml.js`'s own `packageCodec`, which genuinely is a lossless round trip. `docxPdfCodec`/`pptxPdfCodec`/`odtPdfCodec`/`odpPdfCodec`/`pdfCodec` share `packageCodec`'s *mechanism* (`z.codec()`, schema-validated both ways) but not its *guarantee* — wrapping a lossy conversion in `z.codec()` validates the shape of what comes out, not its fidelity to what went in.
+**PDF → odg** (`reconstructDrawing`) is a best-effort reconstruction too, but for the opposite reason: not because a drawing's structure is hard to infer, but because a drawing has no semantic structure to infer at all, so there is no clustering step to get right or wrong in the first place. Every recovered `LayoutItem` maps close to 1:1 onto a `ContentVector`/`ContentShape`, in the exact order it was painted. What is genuinely lossy is upstream of `reconstructDrawing`, in what a PDF's own content-stream operators can even preserve: position, size, and fill/stroke colour survive within ordinary floating-point tolerance regardless of vector kind, but a filled-and-stroked rect, any ellipse, and any line each come back as a generic `path` vector rather than their original kind, since PDF has no native rect/ellipse/line primitive beyond one narrow fast-path case — see the `reconstructDrawing` gotcha above for the exact boundary. The one place this genuinely reorganises content rather than just approximating it: a single wrapped multi-line text box comes back as several separate single-line text boxes, one per line PDF's own line-wrapper produced, since `reconstructDrawing` maps one `LayoutText` item to one shape with no clustering — the text survives, its original grouping into one box does not. Verified against real LibreOffice 26.2, not merely against this package's own reader: a richly-varied `.odg` (overlapping rects, a filled-and-stroked ellipse, a stroked line, a filled-and-stroked Bezier curve, a wrapped text label) round-tripped through `odgToPdf` then `pdfToOdg` opens as a valid drawing with correct position, colour, and z-order throughout, the curve genuinely curved rather than polygon-approximated, and only the vector-kind-narrowing and text-splitting above visibly distinguishing it from the source.
+
+Neither direction is round-trip-lossless, and no conversion is the exact inverse of its own reverse direction — `pdfToDocx(docxToPdf(x))` will not reproduce `x` exactly, and neither will `pdfToOdg(odgToPdf(x))`; neither is intended to. This is a deliberate, permanent contrast with `ooxml.js`'s own `packageCodec`, which genuinely is a lossless round trip. `docxPdfCodec`/`pptxPdfCodec`/`odtPdfCodec`/`odpPdfCodec`/`odgPdfCodec`/`pdfCodec` share `packageCodec`'s *mechanism* (`z.codec()`, schema-validated both ways) but not its *guarantee* — wrapping a lossy conversion in `z.codec()` validates the shape of what comes out, not its fidelity to what went in.
 
 **Optional real-world corpus.** `test/corpus/` (gitignored, never committed) holds a `pnpm test:corpus` vitest project for manual conformance checking against real PDFs a hand-built fixture can't fully stand in for — a Word "Save as PDF", a PowerPoint "Save as PDF", a Chrome "Print to PDF", a LibreOffice export. It is not part of `pnpm test` and does not gate CI; drop files in locally before a significant parser change.
 
@@ -251,7 +256,7 @@ Commits follow Conventional Commits (`feat:`, `fix:`, `test:`, `chore:`, …), e
 
 - [ooxml.js](https://github.com/ExaDev/ooxml.js) — the sibling package this depends on for all docx/pptx/xlsx ⇄ JSON handling and cascade-resolved typed reading.
 - [document-content-model](https://github.com/ExaDev/document-content-model) — the sibling package that owns `ContentDocument`/`LayoutDocument` themselves; both `ooxml.js` and `documents.js` import from it rather than each maintaining an independent copy.
-- [odf.js](https://github.com/ExaDev/odf.js) — a sibling package doing the equivalent lossless-codec job for the OpenDocument Format (odt/ods/odp/odg/…), also built on `document-content-model`. A dependency of `documents.js` for: this package's `Odt`/`Ods`/`Odp`/`OdgBytesSchema` (`src/model/bytes.ts`), which validate against its `ODF_MEDIA_TYPES` table; `src/interop.test.ts`, a type-level guard that `ooxml.js`'s and `odf.js`'s raw `XmlElement`/`XmlNode`/`Attribute`/`Package` container types stay structurally compatible; `src/odf/odt/read.ts`'s `readOdtContent`, a thin adapter over `odf.js`'s own `readOdt`, feeding `odtToPdf`/`pdfToOdt` (`src/convert/convert.ts`); `src/odf/odp/read.ts`'s `readOdpContent`, the same adapter over `odf.js`'s `readOdp`, feeding `odpToPdf`/`pdfToOdp`; `src/odf/ods/read.ts`'s `readOdsContent`, the same adapter over `odf.js`'s `readOds`, feeding `odsToPdf`; `src/odf/odg/read.ts`'s `readOdgContent`, the same adapter over `odf.js`'s `readOdg` — including its own `typed/shared/path.ts`, the real-LibreOffice-output-verified `svg:d`/`draw:points` parser this package's `writePath` content is ultimately sourced from, and which `src/edit/odg/svg-path.ts`'s `buildSvgPathData` (the write-side inverse) also cross-checks its own output against directly — feeding `odgToPdf`; `src/edit/odt/*`'s `StyleRegistry`/`resolveStyle` (style interning), `src/edit/odp/shape.ts`'s `applyOdfTransform`/`resolveOdfShapeGeometry` (rotation), and `src/edit/odt/automatic-styles.ts`'s `ensureAutomaticStyles`/`nextStyleName` (reused by `src/edit/odg/style.ts`'s own graphic-family style writer), all consumed directly rather than reimplemented. odt and odp → `ContentDocument` reading and PDF conversion are now integrated both ways; ods and odg → `ContentDocument` reading and PDF conversion (the equivalent for spreadsheets and drawings) are integrated one-directionally (→ PDF only, no reverse direction yet), even though both now have their own live-view editor and `build*Package` bridge ready for the day `pdfToOds`/`pdfToOdg` exist.
+- [odf.js](https://github.com/ExaDev/odf.js) — a sibling package doing the equivalent lossless-codec job for the OpenDocument Format (odt/ods/odp/odg/…), also built on `document-content-model`. A dependency of `documents.js` for: this package's `Odt`/`Ods`/`Odp`/`OdgBytesSchema` (`src/model/bytes.ts`), which validate against its `ODF_MEDIA_TYPES` table; `src/interop.test.ts`, a type-level guard that `ooxml.js`'s and `odf.js`'s raw `XmlElement`/`XmlNode`/`Attribute`/`Package` container types stay structurally compatible; `src/odf/odt/read.ts`'s `readOdtContent`, a thin adapter over `odf.js`'s own `readOdt`, feeding `odtToPdf`/`pdfToOdt` (`src/convert/convert.ts`); `src/odf/odp/read.ts`'s `readOdpContent`, the same adapter over `odf.js`'s `readOdp`, feeding `odpToPdf`/`pdfToOdp`; `src/odf/ods/read.ts`'s `readOdsContent`, the same adapter over `odf.js`'s `readOds`, feeding `odsToPdf`; `src/odf/odg/read.ts`'s `readOdgContent`, the same adapter over `odf.js`'s `readOdg` — including its own `typed/shared/path.ts`, the real-LibreOffice-output-verified `svg:d`/`draw:points` parser this package's `writePath` content is ultimately sourced from, and which `src/edit/odg/svg-path.ts`'s `buildSvgPathData` (the write-side inverse) also cross-checks its own output against directly — feeding `odgToPdf`/`pdfToOdg` (the latter re-reading a rebuilt package's own real geometry through this same `readOdg`, not just writing one); `src/edit/odt/*`'s `StyleRegistry`/`resolveStyle` (style interning), `src/edit/odp/shape.ts`'s `applyOdfTransform`/`resolveOdfShapeGeometry` (rotation), and `src/edit/odt/automatic-styles.ts`'s `ensureAutomaticStyles`/`nextStyleName` (reused by `src/edit/odg/style.ts`'s own graphic-family style writer), all consumed directly rather than reimplemented. odt, odp, and odg → `ContentDocument` reading and PDF conversion are now integrated both ways; ods → `ContentDocument` reading and PDF conversion (the equivalent for spreadsheets) is integrated one-directionally (→ PDF only, no reverse direction yet), even though it too has its own live-view editor and `buildOdsPackage` bridge ready for the day `pdfToOds` exists.
 
 ## License
 

package/dist/index.cjs

@@ -3762,7 +3762,10 @@ const GRAPHIC_STYLE_PREFIX = "gr";
 function graphicPropertyAttrs(init) {
 	const attrs = {};
 	if (init.fill === void 0) attrs["draw:fill"] = "none";
-	else attrs["draw:fill-color"] = (0, odf_js.formatOdfColor)(init.fill);
+	else {
+		attrs["draw:fill"] = "solid";
+		attrs["draw:fill-color"] = (0, odf_js.formatOdfColor)(init.fill);
+	}
 	if (init.stroke === void 0) attrs["draw:stroke"] = "none";
 	else {
 		attrs["svg:stroke-color"] = (0, odf_js.formatOdfColor)(init.stroke.color);
@@ -8442,6 +8445,7 @@ function writeEllipse(writer, item) {
 	writer.writeAscii(`${formatPoint(cx - kx, cy + ry)} ${formatPoint(cx - rx, cy + ky)} ${formatPoint(cx - rx, cy)} c\n`);
 	writer.writeAscii(`${formatPoint(cx - rx, cy - ky)} ${formatPoint(cx - kx, cy - ry)} ${formatPoint(cx, cy - ry)} c\n`);
 	writer.writeAscii(`${formatPoint(cx + kx, cy - ry)} ${formatPoint(cx + rx, cy - ky)} ${formatPoint(cx + rx, cy)} c\n`);
+	writer.writeAscii("h\n");
 	writer.writeAscii(`${paint}\n`);
 }
 function writeSubpath(writer, subpath) {
@@ -10824,6 +10828,202 @@ function imageToShape(img, slideHeightPt, images) {
 		}]
 	};
 }
+function reconstructDrawing(doc, options) {
+	const signal = options?.signal;
+	const pages = doc.pages.map((page) => {
+		throwIfAborted(signal);
+		return reconstructDrawPage(page, doc.images);
+	});
+	return {
+		kind: "drawing",
+		formatVersion: 1,
+		metadata: doc.metadata,
+		pages
+	};
+}
+function reconstructDrawPage(page, images) {
+	const vectors = [];
+	const shapes = [];
+	for (const item of page.items) if (item.kind === "rect") vectors.push(layoutRectToVector(item, page.heightPt));
+	else if (item.kind === "ellipse") vectors.push(layoutEllipseToVector(item, page.heightPt));
+	else if (item.kind === "line") vectors.push(layoutLineToVector(item, page.heightPt));
+	else if (item.kind === "path") vectors.push(layoutPathToVector(item, page.heightPt));
+	else if (item.kind === "text") shapes.push(layoutTextToShape(item, page.heightPt));
+	else if (item.kind === "image") {
+		const shape = imageToShape(item, page.heightPt, images);
+		if (shape !== void 0) shapes.push(shape);
+	}
+	return {
+		size: {
+			widthPt: page.widthPt,
+			heightPt: page.heightPt
+		},
+		shapes,
+		vectors
+	};
+}
+function layoutRectToVector(item, pageHeightPt) {
+	return {
+		kind: "rect",
+		frame: flipY({
+			xPt: item.xPt,
+			yPt: item.yPt,
+			widthPt: item.widthPt,
+			heightPt: item.heightPt
+		}, pageHeightPt),
+		fill: item.fill,
+		stroke: item.stroke,
+		sourcePath: item.sourcePath
+	};
+}
+function layoutEllipseToVector(item, pageHeightPt) {
+	return {
+		kind: "ellipse",
+		frame: flipY({
+			xPt: item.xPt,
+			yPt: item.yPt,
+			widthPt: item.widthPt,
+			heightPt: item.heightPt
+		}, pageHeightPt),
+		fill: item.fill,
+		stroke: item.stroke,
+		sourcePath: item.sourcePath
+	};
+}
+function layoutLineToVector(item, pageHeightPt) {
+	return {
+		kind: "line",
+		from: {
+			xPt: item.x1Pt,
+			yPt: pageHeightPt - item.y1Pt
+		},
+		to: {
+			xPt: item.x2Pt,
+			yPt: pageHeightPt - item.y2Pt
+		},
+		stroke: {
+			color: item.color,
+			widthPt: item.widthPt
+		},
+		sourcePath: item.sourcePath
+	};
+}
+function collectPathPoints(subpaths) {
+	const points = [];
+	for (const subpath of subpaths) {
+		points.push({
+			xPt: subpath.startXPt,
+			yPt: subpath.startYPt
+		});
+		for (const segment of subpath.segments) {
+			if (segment.kind === "cubic") {
+				points.push({
+					xPt: segment.c1xPt,
+					yPt: segment.c1yPt
+				});
+				points.push({
+					xPt: segment.c2xPt,
+					yPt: segment.c2yPt
+				});
+			}
+			points.push({
+				xPt: segment.xPt,
+				yPt: segment.yPt
+			});
+		}
+	}
+	return points;
+}
+function pathBoundingFrame(points, pageHeightPt) {
+	if (points.length === 0) return {
+		xPt: 0,
+		yPt: 0,
+		widthPt: 0,
+		heightPt: 0
+	};
+	let minX = Number.POSITIVE_INFINITY;
+	let maxX = Number.NEGATIVE_INFINITY;
+	let minYDown = Number.POSITIVE_INFINITY;
+	let maxYDown = Number.NEGATIVE_INFINITY;
+	for (const point of points) {
+		const yDown = pageHeightPt - point.yPt;
+		minX = Math.min(minX, point.xPt);
+		maxX = Math.max(maxX, point.xPt);
+		minYDown = Math.min(minYDown, yDown);
+		maxYDown = Math.max(maxYDown, yDown);
+	}
+	return {
+		xPt: minX,
+		yPt: minYDown,
+		widthPt: maxX - minX,
+		heightPt: maxYDown - minYDown
+	};
+}
+function localizePathPoint(frame, point, pageHeightPt) {
+	return {
+		xPt: point.xPt - frame.xPt,
+		yPt: pageHeightPt - frame.yPt - point.yPt
+	};
+}
+function layoutPathToVector(item, pageHeightPt) {
+	const frame = pathBoundingFrame(collectPathPoints(item.subpaths), pageHeightPt);
+	return {
+		kind: "path",
+		frame,
+		subpaths: item.subpaths.map((subpath) => ({
+			start: localizePathPoint(frame, {
+				xPt: subpath.startXPt,
+				yPt: subpath.startYPt
+			}, pageHeightPt),
+			closed: subpath.closed,
+			segments: subpath.segments.map((segment) => {
+				if (segment.kind === "line") return {
+					kind: "line",
+					to: localizePathPoint(frame, {
+						xPt: segment.xPt,
+						yPt: segment.yPt
+					}, pageHeightPt)
+				};
+				return {
+					kind: "cubic",
+					control1: localizePathPoint(frame, {
+						xPt: segment.c1xPt,
+						yPt: segment.c1yPt
+					}, pageHeightPt),
+					control2: localizePathPoint(frame, {
+						xPt: segment.c2xPt,
+						yPt: segment.c2yPt
+					}, pageHeightPt),
+					to: localizePathPoint(frame, {
+						xPt: segment.xPt,
+						yPt: segment.yPt
+					}, pageHeightPt)
+				};
+			})
+		})),
+		fill: item.fill,
+		fillRule: item.fillRule,
+		stroke: item.stroke,
+		sourcePath: item.sourcePath
+	};
+}
+function layoutTextToShape(item, pageHeightPt) {
+	return {
+		frame: computeBlockFrame({ lines: [{
+			items: [item],
+			baselineY: item.yPt
+		}] }, pageHeightPt),
+		rotationDeg: item.rotationDeg !== void 0 ? -item.rotationDeg : void 0,
+		insetLeftPt: 0,
+		insetTopPt: 0,
+		insetRightPt: 0,
+		insetBottomPt: 0,
+		blocks: [{
+			kind: "paragraph",
+			runs: [textItemToContentRun(item)]
+		}]
+	};
+}
 //#endregion
 //#region src/convert/convert.ts
 function docxToPdf(bytes, options) {
@@ -10905,6 +11105,13 @@ function pdfToOdp(bytes, options) {
 	}), { signal: options?.signal });
 	return (0, odf_js.encodePackage)(buildOdpPackage(content));
 }
+function pdfToOdg(bytes, options) {
+	const content = reconstructDrawing(readPdf(bytes, {
+		signal: options?.signal,
+		sink: options?.sink
+	}), { signal: options?.signal });
+	return (0, odf_js.encodePackage)(buildOdgPackage(content));
+}
 //#endregion
 //#region src/convert/codec.ts
 const docxPdfCodec = zod.z.codec(DocxBytesSchema, PdfBytesSchema, {
@@ -10923,6 +11130,10 @@ const odpPdfCodec = zod.z.codec(OdpBytesSchema, PdfBytesSchema, {
 	decode: (odpBytes) => odpToPdf(odpBytes),
 	encode: (pdfBytes) => pdfToOdp(pdfBytes)
 });
+const odgPdfCodec = zod.z.codec(OdgBytesSchema, PdfBytesSchema, {
+	decode: (odgBytes) => odgToPdf(odgBytes),
+	encode: (pdfBytes) => pdfToOdg(pdfBytes)
+});
 //#endregion
 //#region src/convert/local.ts
 const SUPPORTED_CONVERSIONS = [
@@ -10965,6 +11176,10 @@ const SUPPORTED_CONVERSIONS = [
 	{
 		source: "pdf",
 		target: "odp"
+	},
+	{
+		source: "pdf",
+		target: "odg"
 	}
 ];
 function substitutionDiagnostic(substitution, context) {
@@ -11120,6 +11335,19 @@ function createLocalDocumentConverter() {
 					diagnostics
 				});
 			}
+			if (source.format === "pdf" && targetFormat === "odg") {
+				const bytes = pdfToOdg(source.bytes, {
+					signal: options.signal,
+					sink: (d) => diagnostics.push(fromPdfDiagnostic(d))
+				});
+				return Promise.resolve({
+					document: {
+						format: "odg",
+						bytes
+					},
+					diagnostics
+				});
+			}
 			return Promise.reject(/* @__PURE__ */ new Error(`unsupported conversion: ${source.format} -> ${targetFormat}`));
 		}
 	};
@@ -11588,6 +11816,7 @@ Object.defineProperty(exports, "isXmlNode", {
 		return ooxml_js.isXmlNode;
 	}
 });
+exports.odgPdfCodec = odgPdfCodec;
 exports.odgToPdf = odgToPdf;
 exports.odpPdfCodec = odpPdfCodec;
 exports.odpToPdf = odpToPdf;
@@ -11620,6 +11849,7 @@ Object.defineProperty(exports, "parseXml", {
 });
 exports.pdfCodec = pdfCodec;
 exports.pdfToDocx = pdfToDocx;
+exports.pdfToOdg = pdfToOdg;
 exports.pdfToOdp = pdfToOdp;
 exports.pdfToOdt = pdfToOdt;
 exports.pdfToPptx = pdfToPptx;
@@ -11632,6 +11862,7 @@ exports.readOdsContent = readOdsContent;
 exports.readOdtContent = readOdtContent;
 exports.readPdf = readPdf;
 exports.readPptxContent = readPptxContent;
+exports.reconstructDrawing = reconstructDrawing;
 exports.reconstructPresentation = reconstructPresentation;
 exports.reconstructWordprocessing = reconstructWordprocessing;
 Object.defineProperty(exports, "resolveRelationships", {

package/dist/index.d.cts

@@ -1242,6 +1242,7 @@ interface ReconstructOptions {
 }
 declare function reconstructWordprocessing(doc: LayoutDocument$1, options?: ReconstructOptions): ContentDocument;
 declare function reconstructPresentation(doc: LayoutDocument$1, options?: ReconstructOptions): ContentDocument;
+declare function reconstructDrawing(doc: LayoutDocument$1, options?: ReconstructOptions): ContentDocument;
 //#endregion
 //#region src/convert/convert.d.ts
 interface DocumentToPdfOptions {
@@ -1264,12 +1265,14 @@ declare function pdfToDocx(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocume
 declare function pdfToPptx(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
 declare function pdfToOdt(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
 declare function pdfToOdp(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
+declare function pdfToOdg(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
 //#endregion
 //#region src/convert/codec.d.ts
 declare const docxPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const pptxPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odtPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odpPdfCodec: 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>>>;
 //#endregion
 //#region src/convert/port.d.ts
 type DocumentFormat = 'docx' | 'pptx' | 'odt' | 'odp' | 'ods' | 'odg' | 'pdf';
@@ -1315,4 +1318,4 @@ declare function fixedClock(date: Date): ClockPort;
 //#region src/ports/abort.d.ts
 declare function throwIfAborted(signal: AbortSignal | undefined): void;
 //#endregion
-export { type Alignment, type Attribute, AttributeSchema, type BinaryPart, BinaryPartSchema, type Box, COLOR_BLACK, CONTENT_FORMAT_VERSION, type ClockPort, type Comment, CommentSchema, type CompactAttrPairs, type CompactPackage, CompactPackageSchema, type CompactPart, CompactPartSchema, type CompactXmlNode, CompactXmlNodeSchema, type ContentBlock, ContentBlockSchema, type ContentCellValue, ContentCellValueSchema, type ContentDocument, ContentDocumentSchema, type ContentDrawPage, ContentDrawPageSchema, type ContentImageBlock, ContentImageBlockSchema, type ContentListMembership, type ContentPageBreak, ContentPageBreakSchema, type ContentParagraph, ContentParagraphSchema, type ContentPathPoint, ContentPathPointSchema, type ContentPathSegment, ContentPathSegmentSchema, type ContentRun, ContentRunSchema, type ContentSection, ContentSectionSchema, type ContentShape, ContentShapeSchema, type ContentSheet, type ContentSheetCell, ContentSheetCellSchema, type ContentSheetColumn, ContentSheetColumnSchema, type ContentSheetImage, type ContentSheetPrintRange, ContentSheetPrintRangeSchema, type ContentSheetPrintSettings, ContentSheetPrintSettingsSchema, type ContentSheetRepeatRange, ContentSheetRepeatRangeSchema, type ContentSheetRow, ContentSheetRowSchema, ContentSheetSchema, type ContentSlide, ContentSlideSchema, type ContentStroke, ContentStrokeSchema, type ContentSubpath, ContentSubpathSchema, type ContentTable, type ContentTableCell, ContentTableCellSchema, type ContentTableRow, ContentTableRowSchema, ContentTableSchema, type ContentVector, ContentVectorSchema, type ConversionRequest, type ConversionResult, DEFAULT_LAYOUT_FONT, type DefinedName, DefinedNameSchema, type Diagnostic, type DocumentConverter, type DocumentFormat, type DocumentPayload, type DocumentToPdfOptions, type DocxBody, DocxBytesSchema, DocxEditor, DocxParagraph, DocxRun, DocxTable, DocxTableCell, DocxTableRow, type DrawingLayoutOptions, type DrawingParagraphInit, type DrawingRunInit, type EngineLayoutOptions, LAYOUT_FORMAT_VERSION, type LayoutColor, type LayoutDocument, type LayoutEllipse, type LayoutFont, type LayoutImage, type LayoutImageAsset, type LayoutItem, type LayoutLine, type LayoutLink, type LayoutMetadata, type LayoutPage, type LayoutPath, type LayoutPathSegment, type LayoutRect, type LayoutSubpath, type LayoutText, type Margins, NOOP_DIAGNOSTIC_SINK, OdgBoxVector, type BoxVectorInit as OdgBoxVectorInit, OdgBytesSchema, OdgEditor, OdgLineVector, type LineVectorInit as OdgLineVectorInit, OdgPage, type PageImageInit as OdgPageImageInit, OdgPathVector, type PathVectorInit as OdgPathVectorInit, type TextBoxInit as OdgTextBoxInit, OdpBytesSchema, OdpEditor, OdpShape, OdpSlide, type SlideImageInit as OdpSlideImageInit, type TextBoxInit$1 as OdpTextBoxInit, OdsBytesSchema, OdsCell, OdsEditor, OdsSheet, type OdtBody, OdtBytesSchema, OdtEditor, OdtList, OdtListItem, OdtParagraph, type ParagraphInit as OdtParagraphInit, OdtRun, type RunInit as OdtRunInit, OdtTable, OdtTableCell, type TableInit as OdtTableInit, OdtTableRow, PAGE_SIZE_A4, PAGE_SIZE_LETTER, type Package, PackageSchema, type PageSize, type Part, PartSchema, PdfBytesSchema, type PdfDiagnostic, type PdfDiagnosticSeverity, type PdfDiagnosticSink, PdfEncryptedError, PdfParseError, type PdfToDocumentOptions, PptxBytesSchema, PptxEditor, PptxShape, PptxSlide, type ReadPdfOptions, type ReconstructOptions, type Relationship, SLIDE_SIZE_STANDARD, SLIDE_SIZE_WIDESCREEN, type SheetsLayoutOptions, type SlideImageInit$1 as SlideImageInit, type SlidesLayoutOptions, type TextBoxInit$2 as TextBoxInit, type WinAnsiSubstitution, type WritePdfOptions, type XmlCdata, XmlCdataSchema, type XmlComment, XmlCommentSchema, type XmlDeclaration, XmlDeclarationSchema, type XmlElement, XmlElementSchema, type XmlNode, XmlNodeSchema, type XmlPart, XmlPartSchema, type XmlPi, XmlPiSchema, type XmlText, XmlTextSchema, attr, base64ToBytes, buildDocxPackage, buildOdgPackage, buildOdpPackage, buildOdsPackage, buildOdtPackage, buildPptxPackage, buildXml, bytesToBase64, childrenWithTag, compactCodec, compactPackageCodec, convertDrawingToLayout, convertPresentationToLayout, convertSpreadsheetToLayout, convertWordprocessingToLayout, createDocx, createLocalDocumentConverter, createOdg, createOdp, createOds, createOdt, createPptx, decodeCompactPackage, decodeEntities, decodePackage, docxPdfCodec, docxToPdf, elementsWithTag, encodeCompactPackage, encodePackage, fixedClock, flipY, fromCompact, isCompactXmlNode, isContentBlock, isXmlNode, odgToPdf, odpPdfCodec, odpToPdf, odsToPdf, odtPdfCodec, odtToPdf, openDocx, openOdg, openOdp, openOds, openOdt, openPptx, packageCodec, parsePackage, parseXml, pdfCodec, pdfToDocx, pdfToOdp, pdfToOdt, pdfToPptx, pptxPdfCodec, pptxToPdf, readDocxContent, readOdgContent, readOdpContent, readOdsContent, readOdtContent, readPdf, readPptxContent, reconstructPresentation, reconstructWordprocessing, resolveRelationships, rgbHexToColor, rootElement, serializePackage, systemClock, textContent, throwIfAborted, toCompact, unzipPackage, walk, writePdf, xmlCodec, zipPackage };
+export { type Alignment, type Attribute, AttributeSchema, type BinaryPart, BinaryPartSchema, type Box, COLOR_BLACK, CONTENT_FORMAT_VERSION, type ClockPort, type Comment, CommentSchema, type CompactAttrPairs, type CompactPackage, CompactPackageSchema, type CompactPart, CompactPartSchema, type CompactXmlNode, CompactXmlNodeSchema, type ContentBlock, ContentBlockSchema, type ContentCellValue, ContentCellValueSchema, type ContentDocument, ContentDocumentSchema, type ContentDrawPage, ContentDrawPageSchema, type ContentImageBlock, ContentImageBlockSchema, type ContentListMembership, type ContentPageBreak, ContentPageBreakSchema, type ContentParagraph, ContentParagraphSchema, type ContentPathPoint, ContentPathPointSchema, type ContentPathSegment, ContentPathSegmentSchema, type ContentRun, ContentRunSchema, type ContentSection, ContentSectionSchema, type ContentShape, ContentShapeSchema, type ContentSheet, type ContentSheetCell, ContentSheetCellSchema, type ContentSheetColumn, ContentSheetColumnSchema, type ContentSheetImage, type ContentSheetPrintRange, ContentSheetPrintRangeSchema, type ContentSheetPrintSettings, ContentSheetPrintSettingsSchema, type ContentSheetRepeatRange, ContentSheetRepeatRangeSchema, type ContentSheetRow, ContentSheetRowSchema, ContentSheetSchema, type ContentSlide, ContentSlideSchema, type ContentStroke, ContentStrokeSchema, type ContentSubpath, ContentSubpathSchema, type ContentTable, type ContentTableCell, ContentTableCellSchema, type ContentTableRow, ContentTableRowSchema, ContentTableSchema, type ContentVector, ContentVectorSchema, type ConversionRequest, type ConversionResult, DEFAULT_LAYOUT_FONT, type DefinedName, DefinedNameSchema, type Diagnostic, type DocumentConverter, type DocumentFormat, type DocumentPayload, type DocumentToPdfOptions, type DocxBody, DocxBytesSchema, DocxEditor, DocxParagraph, DocxRun, DocxTable, DocxTableCell, DocxTableRow, type DrawingLayoutOptions, type DrawingParagraphInit, type DrawingRunInit, type EngineLayoutOptions, LAYOUT_FORMAT_VERSION, type LayoutColor, type LayoutDocument, type LayoutEllipse, type LayoutFont, type LayoutImage, type LayoutImageAsset, type LayoutItem, type LayoutLine, type LayoutLink, type LayoutMetadata, type LayoutPage, type LayoutPath, type LayoutPathSegment, type LayoutRect, type LayoutSubpath, type LayoutText, type Margins, NOOP_DIAGNOSTIC_SINK, OdgBoxVector, type BoxVectorInit as OdgBoxVectorInit, OdgBytesSchema, OdgEditor, OdgLineVector, type LineVectorInit as OdgLineVectorInit, OdgPage, type PageImageInit as OdgPageImageInit, OdgPathVector, type PathVectorInit as OdgPathVectorInit, type TextBoxInit as OdgTextBoxInit, OdpBytesSchema, OdpEditor, OdpShape, OdpSlide, type SlideImageInit as OdpSlideImageInit, type TextBoxInit$1 as OdpTextBoxInit, OdsBytesSchema, OdsCell, OdsEditor, OdsSheet, type OdtBody, OdtBytesSchema, OdtEditor, OdtList, OdtListItem, OdtParagraph, type ParagraphInit as OdtParagraphInit, OdtRun, type RunInit as OdtRunInit, OdtTable, OdtTableCell, type TableInit as OdtTableInit, OdtTableRow, PAGE_SIZE_A4, PAGE_SIZE_LETTER, type Package, PackageSchema, type PageSize, type Part, PartSchema, PdfBytesSchema, type PdfDiagnostic, type PdfDiagnosticSeverity, type PdfDiagnosticSink, PdfEncryptedError, PdfParseError, type PdfToDocumentOptions, PptxBytesSchema, PptxEditor, PptxShape, PptxSlide, type ReadPdfOptions, type ReconstructOptions, type Relationship, SLIDE_SIZE_STANDARD, SLIDE_SIZE_WIDESCREEN, type SheetsLayoutOptions, type SlideImageInit$1 as SlideImageInit, type SlidesLayoutOptions, type TextBoxInit$2 as TextBoxInit, type WinAnsiSubstitution, type WritePdfOptions, type XmlCdata, XmlCdataSchema, type XmlComment, XmlCommentSchema, type XmlDeclaration, XmlDeclarationSchema, type XmlElement, XmlElementSchema, type XmlNode, XmlNodeSchema, type XmlPart, XmlPartSchema, type XmlPi, XmlPiSchema, type XmlText, XmlTextSchema, attr, base64ToBytes, buildDocxPackage, buildOdgPackage, buildOdpPackage, buildOdsPackage, buildOdtPackage, buildPptxPackage, buildXml, bytesToBase64, childrenWithTag, compactCodec, compactPackageCodec, convertDrawingToLayout, convertPresentationToLayout, convertSpreadsheetToLayout, convertWordprocessingToLayout, createDocx, createLocalDocumentConverter, createOdg, createOdp, createOds, createOdt, createPptx, decodeCompactPackage, decodeEntities, decodePackage, docxPdfCodec, docxToPdf, elementsWithTag, encodeCompactPackage, encodePackage, fixedClock, flipY, fromCompact, isCompactXmlNode, isContentBlock, isXmlNode, odgPdfCodec, odgToPdf, odpPdfCodec, odpToPdf, odsToPdf, odtPdfCodec, odtToPdf, openDocx, openOdg, openOdp, openOds, openOdt, openPptx, packageCodec, parsePackage, parseXml, pdfCodec, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOdt, pdfToPptx, pptxPdfCodec, pptxToPdf, readDocxContent, readOdgContent, readOdpContent, readOdsContent, readOdtContent, readPdf, readPptxContent, reconstructDrawing, reconstructPresentation, reconstructWordprocessing, resolveRelationships, rgbHexToColor, rootElement, serializePackage, systemClock, textContent, throwIfAborted, toCompact, unzipPackage, walk, writePdf, xmlCodec, zipPackage };

package/dist/index.d.ts

@@ -1242,6 +1242,7 @@ interface ReconstructOptions {
 }
 declare function reconstructWordprocessing(doc: LayoutDocument$1, options?: ReconstructOptions): ContentDocument;
 declare function reconstructPresentation(doc: LayoutDocument$1, options?: ReconstructOptions): ContentDocument;
+declare function reconstructDrawing(doc: LayoutDocument$1, options?: ReconstructOptions): ContentDocument;
 //#endregion
 //#region src/convert/convert.d.ts
 interface DocumentToPdfOptions {
@@ -1264,12 +1265,14 @@ declare function pdfToDocx(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocume
 declare function pdfToPptx(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
 declare function pdfToOdt(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
 declare function pdfToOdp(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
+declare function pdfToOdg(bytes: Uint8Array<ArrayBuffer>, options?: PdfToDocumentOptions): Uint8Array<ArrayBuffer>;
 //#endregion
 //#region src/convert/codec.d.ts
 declare const docxPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const pptxPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odtPdfCodec: z.ZodCodec<z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>, z.ZodCustom<Uint8Array<ArrayBuffer>, Uint8Array<ArrayBuffer>>>;
 declare const odpPdfCodec: 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>>>;
 //#endregion
 //#region src/convert/port.d.ts
 type DocumentFormat = 'docx' | 'pptx' | 'odt' | 'odp' | 'ods' | 'odg' | 'pdf';
@@ -1315,4 +1318,4 @@ declare function fixedClock(date: Date): ClockPort;
 //#region src/ports/abort.d.ts
 declare function throwIfAborted(signal: AbortSignal | undefined): void;
 //#endregion
-export { type Alignment, type Attribute, AttributeSchema, type BinaryPart, BinaryPartSchema, type Box, COLOR_BLACK, CONTENT_FORMAT_VERSION, type ClockPort, type Comment, CommentSchema, type CompactAttrPairs, type CompactPackage, CompactPackageSchema, type CompactPart, CompactPartSchema, type CompactXmlNode, CompactXmlNodeSchema, type ContentBlock, ContentBlockSchema, type ContentCellValue, ContentCellValueSchema, type ContentDocument, ContentDocumentSchema, type ContentDrawPage, ContentDrawPageSchema, type ContentImageBlock, ContentImageBlockSchema, type ContentListMembership, type ContentPageBreak, ContentPageBreakSchema, type ContentParagraph, ContentParagraphSchema, type ContentPathPoint, ContentPathPointSchema, type ContentPathSegment, ContentPathSegmentSchema, type ContentRun, ContentRunSchema, type ContentSection, ContentSectionSchema, type ContentShape, ContentShapeSchema, type ContentSheet, type ContentSheetCell, ContentSheetCellSchema, type ContentSheetColumn, ContentSheetColumnSchema, type ContentSheetImage, type ContentSheetPrintRange, ContentSheetPrintRangeSchema, type ContentSheetPrintSettings, ContentSheetPrintSettingsSchema, type ContentSheetRepeatRange, ContentSheetRepeatRangeSchema, type ContentSheetRow, ContentSheetRowSchema, ContentSheetSchema, type ContentSlide, ContentSlideSchema, type ContentStroke, ContentStrokeSchema, type ContentSubpath, ContentSubpathSchema, type ContentTable, type ContentTableCell, ContentTableCellSchema, type ContentTableRow, ContentTableRowSchema, ContentTableSchema, type ContentVector, ContentVectorSchema, type ConversionRequest, type ConversionResult, DEFAULT_LAYOUT_FONT, type DefinedName, DefinedNameSchema, type Diagnostic, type DocumentConverter, type DocumentFormat, type DocumentPayload, type DocumentToPdfOptions, type DocxBody, DocxBytesSchema, DocxEditor, DocxParagraph, DocxRun, DocxTable, DocxTableCell, DocxTableRow, type DrawingLayoutOptions, type DrawingParagraphInit, type DrawingRunInit, type EngineLayoutOptions, LAYOUT_FORMAT_VERSION, type LayoutColor, type LayoutDocument, type LayoutEllipse, type LayoutFont, type LayoutImage, type LayoutImageAsset, type LayoutItem, type LayoutLine, type LayoutLink, type LayoutMetadata, type LayoutPage, type LayoutPath, type LayoutPathSegment, type LayoutRect, type LayoutSubpath, type LayoutText, type Margins, NOOP_DIAGNOSTIC_SINK, OdgBoxVector, type BoxVectorInit as OdgBoxVectorInit, OdgBytesSchema, OdgEditor, OdgLineVector, type LineVectorInit as OdgLineVectorInit, OdgPage, type PageImageInit as OdgPageImageInit, OdgPathVector, type PathVectorInit as OdgPathVectorInit, type TextBoxInit as OdgTextBoxInit, OdpBytesSchema, OdpEditor, OdpShape, OdpSlide, type SlideImageInit as OdpSlideImageInit, type TextBoxInit$1 as OdpTextBoxInit, OdsBytesSchema, OdsCell, OdsEditor, OdsSheet, type OdtBody, OdtBytesSchema, OdtEditor, OdtList, OdtListItem, OdtParagraph, type ParagraphInit as OdtParagraphInit, OdtRun, type RunInit as OdtRunInit, OdtTable, OdtTableCell, type TableInit as OdtTableInit, OdtTableRow, PAGE_SIZE_A4, PAGE_SIZE_LETTER, type Package, PackageSchema, type PageSize, type Part, PartSchema, PdfBytesSchema, type PdfDiagnostic, type PdfDiagnosticSeverity, type PdfDiagnosticSink, PdfEncryptedError, PdfParseError, type PdfToDocumentOptions, PptxBytesSchema, PptxEditor, PptxShape, PptxSlide, type ReadPdfOptions, type ReconstructOptions, type Relationship, SLIDE_SIZE_STANDARD, SLIDE_SIZE_WIDESCREEN, type SheetsLayoutOptions, type SlideImageInit$1 as SlideImageInit, type SlidesLayoutOptions, type TextBoxInit$2 as TextBoxInit, type WinAnsiSubstitution, type WritePdfOptions, type XmlCdata, XmlCdataSchema, type XmlComment, XmlCommentSchema, type XmlDeclaration, XmlDeclarationSchema, type XmlElement, XmlElementSchema, type XmlNode, XmlNodeSchema, type XmlPart, XmlPartSchema, type XmlPi, XmlPiSchema, type XmlText, XmlTextSchema, attr, base64ToBytes, buildDocxPackage, buildOdgPackage, buildOdpPackage, buildOdsPackage, buildOdtPackage, buildPptxPackage, buildXml, bytesToBase64, childrenWithTag, compactCodec, compactPackageCodec, convertDrawingToLayout, convertPresentationToLayout, convertSpreadsheetToLayout, convertWordprocessingToLayout, createDocx, createLocalDocumentConverter, createOdg, createOdp, createOds, createOdt, createPptx, decodeCompactPackage, decodeEntities, decodePackage, docxPdfCodec, docxToPdf, elementsWithTag, encodeCompactPackage, encodePackage, fixedClock, flipY, fromCompact, isCompactXmlNode, isContentBlock, isXmlNode, odgToPdf, odpPdfCodec, odpToPdf, odsToPdf, odtPdfCodec, odtToPdf, openDocx, openOdg, openOdp, openOds, openOdt, openPptx, packageCodec, parsePackage, parseXml, pdfCodec, pdfToDocx, pdfToOdp, pdfToOdt, pdfToPptx, pptxPdfCodec, pptxToPdf, readDocxContent, readOdgContent, readOdpContent, readOdsContent, readOdtContent, readPdf, readPptxContent, reconstructPresentation, reconstructWordprocessing, resolveRelationships, rgbHexToColor, rootElement, serializePackage, systemClock, textContent, throwIfAborted, toCompact, unzipPackage, walk, writePdf, xmlCodec, zipPackage };
+export { type Alignment, type Attribute, AttributeSchema, type BinaryPart, BinaryPartSchema, type Box, COLOR_BLACK, CONTENT_FORMAT_VERSION, type ClockPort, type Comment, CommentSchema, type CompactAttrPairs, type CompactPackage, CompactPackageSchema, type CompactPart, CompactPartSchema, type CompactXmlNode, CompactXmlNodeSchema, type ContentBlock, ContentBlockSchema, type ContentCellValue, ContentCellValueSchema, type ContentDocument, ContentDocumentSchema, type ContentDrawPage, ContentDrawPageSchema, type ContentImageBlock, ContentImageBlockSchema, type ContentListMembership, type ContentPageBreak, ContentPageBreakSchema, type ContentParagraph, ContentParagraphSchema, type ContentPathPoint, ContentPathPointSchema, type ContentPathSegment, ContentPathSegmentSchema, type ContentRun, ContentRunSchema, type ContentSection, ContentSectionSchema, type ContentShape, ContentShapeSchema, type ContentSheet, type ContentSheetCell, ContentSheetCellSchema, type ContentSheetColumn, ContentSheetColumnSchema, type ContentSheetImage, type ContentSheetPrintRange, ContentSheetPrintRangeSchema, type ContentSheetPrintSettings, ContentSheetPrintSettingsSchema, type ContentSheetRepeatRange, ContentSheetRepeatRangeSchema, type ContentSheetRow, ContentSheetRowSchema, ContentSheetSchema, type ContentSlide, ContentSlideSchema, type ContentStroke, ContentStrokeSchema, type ContentSubpath, ContentSubpathSchema, type ContentTable, type ContentTableCell, ContentTableCellSchema, type ContentTableRow, ContentTableRowSchema, ContentTableSchema, type ContentVector, ContentVectorSchema, type ConversionRequest, type ConversionResult, DEFAULT_LAYOUT_FONT, type DefinedName, DefinedNameSchema, type Diagnostic, type DocumentConverter, type DocumentFormat, type DocumentPayload, type DocumentToPdfOptions, type DocxBody, DocxBytesSchema, DocxEditor, DocxParagraph, DocxRun, DocxTable, DocxTableCell, DocxTableRow, type DrawingLayoutOptions, type DrawingParagraphInit, type DrawingRunInit, type EngineLayoutOptions, LAYOUT_FORMAT_VERSION, type LayoutColor, type LayoutDocument, type LayoutEllipse, type LayoutFont, type LayoutImage, type LayoutImageAsset, type LayoutItem, type LayoutLine, type LayoutLink, type LayoutMetadata, type LayoutPage, type LayoutPath, type LayoutPathSegment, type LayoutRect, type LayoutSubpath, type LayoutText, type Margins, NOOP_DIAGNOSTIC_SINK, OdgBoxVector, type BoxVectorInit as OdgBoxVectorInit, OdgBytesSchema, OdgEditor, OdgLineVector, type LineVectorInit as OdgLineVectorInit, OdgPage, type PageImageInit as OdgPageImageInit, OdgPathVector, type PathVectorInit as OdgPathVectorInit, type TextBoxInit as OdgTextBoxInit, OdpBytesSchema, OdpEditor, OdpShape, OdpSlide, type SlideImageInit as OdpSlideImageInit, type TextBoxInit$1 as OdpTextBoxInit, OdsBytesSchema, OdsCell, OdsEditor, OdsSheet, type OdtBody, OdtBytesSchema, OdtEditor, OdtList, OdtListItem, OdtParagraph, type ParagraphInit as OdtParagraphInit, OdtRun, type RunInit as OdtRunInit, OdtTable, OdtTableCell, type TableInit as OdtTableInit, OdtTableRow, PAGE_SIZE_A4, PAGE_SIZE_LETTER, type Package, PackageSchema, type PageSize, type Part, PartSchema, PdfBytesSchema, type PdfDiagnostic, type PdfDiagnosticSeverity, type PdfDiagnosticSink, PdfEncryptedError, PdfParseError, type PdfToDocumentOptions, PptxBytesSchema, PptxEditor, PptxShape, PptxSlide, type ReadPdfOptions, type ReconstructOptions, type Relationship, SLIDE_SIZE_STANDARD, SLIDE_SIZE_WIDESCREEN, type SheetsLayoutOptions, type SlideImageInit$1 as SlideImageInit, type SlidesLayoutOptions, type TextBoxInit$2 as TextBoxInit, type WinAnsiSubstitution, type WritePdfOptions, type XmlCdata, XmlCdataSchema, type XmlComment, XmlCommentSchema, type XmlDeclaration, XmlDeclarationSchema, type XmlElement, XmlElementSchema, type XmlNode, XmlNodeSchema, type XmlPart, XmlPartSchema, type XmlPi, XmlPiSchema, type XmlText, XmlTextSchema, attr, base64ToBytes, buildDocxPackage, buildOdgPackage, buildOdpPackage, buildOdsPackage, buildOdtPackage, buildPptxPackage, buildXml, bytesToBase64, childrenWithTag, compactCodec, compactPackageCodec, convertDrawingToLayout, convertPresentationToLayout, convertSpreadsheetToLayout, convertWordprocessingToLayout, createDocx, createLocalDocumentConverter, createOdg, createOdp, createOds, createOdt, createPptx, decodeCompactPackage, decodeEntities, decodePackage, docxPdfCodec, docxToPdf, elementsWithTag, encodeCompactPackage, encodePackage, fixedClock, flipY, fromCompact, isCompactXmlNode, isContentBlock, isXmlNode, odgPdfCodec, odgToPdf, odpPdfCodec, odpToPdf, odsToPdf, odtPdfCodec, odtToPdf, openDocx, openOdg, openOdp, openOds, openOdt, openPptx, packageCodec, parsePackage, parseXml, pdfCodec, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOdt, pdfToPptx, pptxPdfCodec, pptxToPdf, readDocxContent, readOdgContent, readOdpContent, readOdsContent, readOdtContent, readPdf, readPptxContent, reconstructDrawing, reconstructPresentation, reconstructWordprocessing, resolveRelationships, rgbHexToColor, rootElement, serializePackage, systemClock, textContent, throwIfAborted, toCompact, unzipPackage, walk, writePdf, xmlCodec, zipPackage };

package/dist/index.js

@@ -3761,7 +3761,10 @@ const GRAPHIC_STYLE_PREFIX = "gr";
 function graphicPropertyAttrs(init) {
 	const attrs = {};
 	if (init.fill === void 0) attrs["draw:fill"] = "none";
-	else attrs["draw:fill-color"] = formatOdfColor(init.fill);
+	else {
+		attrs["draw:fill"] = "solid";
+		attrs["draw:fill-color"] = formatOdfColor(init.fill);
+	}
 	if (init.stroke === void 0) attrs["draw:stroke"] = "none";
 	else {
 		attrs["svg:stroke-color"] = formatOdfColor(init.stroke.color);
@@ -8441,6 +8444,7 @@ function writeEllipse(writer, item) {
 	writer.writeAscii(`${formatPoint(cx - kx, cy + ry)} ${formatPoint(cx - rx, cy + ky)} ${formatPoint(cx - rx, cy)} c\n`);
 	writer.writeAscii(`${formatPoint(cx - rx, cy - ky)} ${formatPoint(cx - kx, cy - ry)} ${formatPoint(cx, cy - ry)} c\n`);
 	writer.writeAscii(`${formatPoint(cx + kx, cy - ry)} ${formatPoint(cx + rx, cy - ky)} ${formatPoint(cx + rx, cy)} c\n`);
+	writer.writeAscii("h\n");
 	writer.writeAscii(`${paint}\n`);
 }
 function writeSubpath(writer, subpath) {
@@ -10823,6 +10827,202 @@ function imageToShape(img, slideHeightPt, images) {
 		}]
 	};
 }
+function reconstructDrawing(doc, options) {
+	const signal = options?.signal;
+	const pages = doc.pages.map((page) => {
+		throwIfAborted(signal);
+		return reconstructDrawPage(page, doc.images);
+	});
+	return {
+		kind: "drawing",
+		formatVersion: 1,
+		metadata: doc.metadata,
+		pages
+	};
+}
+function reconstructDrawPage(page, images) {
+	const vectors = [];
+	const shapes = [];
+	for (const item of page.items) if (item.kind === "rect") vectors.push(layoutRectToVector(item, page.heightPt));
+	else if (item.kind === "ellipse") vectors.push(layoutEllipseToVector(item, page.heightPt));
+	else if (item.kind === "line") vectors.push(layoutLineToVector(item, page.heightPt));
+	else if (item.kind === "path") vectors.push(layoutPathToVector(item, page.heightPt));
+	else if (item.kind === "text") shapes.push(layoutTextToShape(item, page.heightPt));
+	else if (item.kind === "image") {
+		const shape = imageToShape(item, page.heightPt, images);
+		if (shape !== void 0) shapes.push(shape);
+	}
+	return {
+		size: {
+			widthPt: page.widthPt,
+			heightPt: page.heightPt
+		},
+		shapes,
+		vectors
+	};
+}
+function layoutRectToVector(item, pageHeightPt) {
+	return {
+		kind: "rect",
+		frame: flipY({
+			xPt: item.xPt,
+			yPt: item.yPt,
+			widthPt: item.widthPt,
+			heightPt: item.heightPt
+		}, pageHeightPt),
+		fill: item.fill,
+		stroke: item.stroke,
+		sourcePath: item.sourcePath
+	};
+}
+function layoutEllipseToVector(item, pageHeightPt) {
+	return {
+		kind: "ellipse",
+		frame: flipY({
+			xPt: item.xPt,
+			yPt: item.yPt,
+			widthPt: item.widthPt,
+			heightPt: item.heightPt
+		}, pageHeightPt),
+		fill: item.fill,
+		stroke: item.stroke,
+		sourcePath: item.sourcePath
+	};
+}
+function layoutLineToVector(item, pageHeightPt) {
+	return {
+		kind: "line",
+		from: {
+			xPt: item.x1Pt,
+			yPt: pageHeightPt - item.y1Pt
+		},
+		to: {
+			xPt: item.x2Pt,
+			yPt: pageHeightPt - item.y2Pt
+		},
+		stroke: {
+			color: item.color,
+			widthPt: item.widthPt
+		},
+		sourcePath: item.sourcePath
+	};
+}
+function collectPathPoints(subpaths) {
+	const points = [];
+	for (const subpath of subpaths) {
+		points.push({
+			xPt: subpath.startXPt,
+			yPt: subpath.startYPt
+		});
+		for (const segment of subpath.segments) {
+			if (segment.kind === "cubic") {
+				points.push({
+					xPt: segment.c1xPt,
+					yPt: segment.c1yPt
+				});
+				points.push({
+					xPt: segment.c2xPt,
+					yPt: segment.c2yPt
+				});
+			}
+			points.push({
+				xPt: segment.xPt,
+				yPt: segment.yPt
+			});
+		}
+	}
+	return points;
+}
+function pathBoundingFrame(points, pageHeightPt) {
+	if (points.length === 0) return {
+		xPt: 0,
+		yPt: 0,
+		widthPt: 0,
+		heightPt: 0
+	};
+	let minX = Number.POSITIVE_INFINITY;
+	let maxX = Number.NEGATIVE_INFINITY;
+	let minYDown = Number.POSITIVE_INFINITY;
+	let maxYDown = Number.NEGATIVE_INFINITY;
+	for (const point of points) {
+		const yDown = pageHeightPt - point.yPt;
+		minX = Math.min(minX, point.xPt);
+		maxX = Math.max(maxX, point.xPt);
+		minYDown = Math.min(minYDown, yDown);
+		maxYDown = Math.max(maxYDown, yDown);
+	}
+	return {
+		xPt: minX,
+		yPt: minYDown,
+		widthPt: maxX - minX,
+		heightPt: maxYDown - minYDown
+	};
+}
+function localizePathPoint(frame, point, pageHeightPt) {
+	return {
+		xPt: point.xPt - frame.xPt,
+		yPt: pageHeightPt - frame.yPt - point.yPt
+	};
+}
+function layoutPathToVector(item, pageHeightPt) {
+	const frame = pathBoundingFrame(collectPathPoints(item.subpaths), pageHeightPt);
+	return {
+		kind: "path",
+		frame,
+		subpaths: item.subpaths.map((subpath) => ({
+			start: localizePathPoint(frame, {
+				xPt: subpath.startXPt,
+				yPt: subpath.startYPt
+			}, pageHeightPt),
+			closed: subpath.closed,
+			segments: subpath.segments.map((segment) => {
+				if (segment.kind === "line") return {
+					kind: "line",
+					to: localizePathPoint(frame, {
+						xPt: segment.xPt,
+						yPt: segment.yPt
+					}, pageHeightPt)
+				};
+				return {
+					kind: "cubic",
+					control1: localizePathPoint(frame, {
+						xPt: segment.c1xPt,
+						yPt: segment.c1yPt
+					}, pageHeightPt),
+					control2: localizePathPoint(frame, {
+						xPt: segment.c2xPt,
+						yPt: segment.c2yPt
+					}, pageHeightPt),
+					to: localizePathPoint(frame, {
+						xPt: segment.xPt,
+						yPt: segment.yPt
+					}, pageHeightPt)
+				};
+			})
+		})),
+		fill: item.fill,
+		fillRule: item.fillRule,
+		stroke: item.stroke,
+		sourcePath: item.sourcePath
+	};
+}
+function layoutTextToShape(item, pageHeightPt) {
+	return {
+		frame: computeBlockFrame({ lines: [{
+			items: [item],
+			baselineY: item.yPt
+		}] }, pageHeightPt),
+		rotationDeg: item.rotationDeg !== void 0 ? -item.rotationDeg : void 0,
+		insetLeftPt: 0,
+		insetTopPt: 0,
+		insetRightPt: 0,
+		insetBottomPt: 0,
+		blocks: [{
+			kind: "paragraph",
+			runs: [textItemToContentRun(item)]
+		}]
+	};
+}
 //#endregion
 //#region src/convert/convert.ts
 function docxToPdf(bytes, options) {
@@ -10904,6 +11104,13 @@ function pdfToOdp(bytes, options) {
 	}), { signal: options?.signal });
 	return encodePackage$2(buildOdpPackage(content));
 }
+function pdfToOdg(bytes, options) {
+	const content = reconstructDrawing(readPdf(bytes, {
+		signal: options?.signal,
+		sink: options?.sink
+	}), { signal: options?.signal });
+	return encodePackage$2(buildOdgPackage(content));
+}
 //#endregion
 //#region src/convert/codec.ts
 const docxPdfCodec = z.codec(DocxBytesSchema, PdfBytesSchema, {
@@ -10922,6 +11129,10 @@ const odpPdfCodec = z.codec(OdpBytesSchema, PdfBytesSchema, {
 	decode: (odpBytes) => odpToPdf(odpBytes),
 	encode: (pdfBytes) => pdfToOdp(pdfBytes)
 });
+const odgPdfCodec = z.codec(OdgBytesSchema, PdfBytesSchema, {
+	decode: (odgBytes) => odgToPdf(odgBytes),
+	encode: (pdfBytes) => pdfToOdg(pdfBytes)
+});
 //#endregion
 //#region src/convert/local.ts
 const SUPPORTED_CONVERSIONS = [
@@ -10964,6 +11175,10 @@ const SUPPORTED_CONVERSIONS = [
 	{
 		source: "pdf",
 		target: "odp"
+	},
+	{
+		source: "pdf",
+		target: "odg"
 	}
 ];
 function substitutionDiagnostic(substitution, context) {
@@ -11119,6 +11334,19 @@ function createLocalDocumentConverter() {
 					diagnostics
 				});
 			}
+			if (source.format === "pdf" && targetFormat === "odg") {
+				const bytes = pdfToOdg(source.bytes, {
+					signal: options.signal,
+					sink: (d) => diagnostics.push(fromPdfDiagnostic(d))
+				});
+				return Promise.resolve({
+					document: {
+						format: "odg",
+						bytes
+					},
+					diagnostics
+				});
+			}
 			return Promise.reject(/* @__PURE__ */ new Error(`unsupported conversion: ${source.format} -> ${targetFormat}`));
 		}
 	};
@@ -11130,4 +11358,4 @@ function fixedClock(date) {
 	return { now: () => date };
 }
 //#endregion
-export { AttributeSchema, BinaryPartSchema, COLOR_BLACK, CONTENT_FORMAT_VERSION, CommentSchema, CompactPackageSchema, CompactPartSchema, CompactXmlNodeSchema, ContentBlockSchema, ContentCellValueSchema, ContentDocumentSchema, ContentDrawPageSchema, ContentImageBlockSchema, ContentPageBreakSchema, ContentParagraphSchema, ContentPathPointSchema, ContentPathSegmentSchema, ContentRunSchema, ContentSectionSchema, ContentShapeSchema, ContentSheetCellSchema, ContentSheetColumnSchema, ContentSheetPrintRangeSchema, ContentSheetPrintSettingsSchema, ContentSheetRepeatRangeSchema, ContentSheetRowSchema, ContentSheetSchema, ContentSlideSchema, ContentStrokeSchema, ContentSubpathSchema, ContentTableCellSchema, ContentTableRowSchema, ContentTableSchema, ContentVectorSchema, DEFAULT_LAYOUT_FONT, DefinedNameSchema, DocxBytesSchema, DocxEditor, DocxParagraph, DocxRun, DocxTable, DocxTableCell, DocxTableRow, LAYOUT_FORMAT_VERSION, NOOP_DIAGNOSTIC_SINK, OdgBoxVector, OdgBytesSchema, OdgEditor, OdgLineVector, OdgPage, OdgPathVector, OdpBytesSchema, OdpEditor, OdpShape, OdpSlide, OdsBytesSchema, OdsCell, OdsEditor, OdsSheet, OdtBytesSchema, OdtEditor, OdtList, OdtListItem, OdtParagraph, OdtRun, OdtTable, OdtTableCell, OdtTableRow, PAGE_SIZE_A4, PAGE_SIZE_LETTER, PackageSchema, PartSchema, PdfBytesSchema, PdfEncryptedError, PdfParseError, PptxBytesSchema, PptxEditor, PptxShape, PptxSlide, SLIDE_SIZE_STANDARD, SLIDE_SIZE_WIDESCREEN, XmlCdataSchema, XmlCommentSchema, XmlDeclarationSchema, XmlElementSchema, XmlNodeSchema, XmlPartSchema, XmlPiSchema, XmlTextSchema, attr, base64ToBytes, buildDocxPackage, buildOdgPackage, buildOdpPackage, buildOdsPackage, buildOdtPackage, buildPptxPackage, buildXml, bytesToBase64, childrenWithTag, compactCodec, compactPackageCodec, convertDrawingToLayout, convertPresentationToLayout, convertSpreadsheetToLayout, convertWordprocessingToLayout, createDocx, createLocalDocumentConverter, createOdg, createOdp, createOds, createOdt, createPptx, decodeCompactPackage, decodeEntities, decodePackage, docxPdfCodec, docxToPdf, elementsWithTag, encodeCompactPackage, encodePackage, fixedClock, flipY, fromCompact, isCompactXmlNode, isContentBlock, isXmlNode, odgToPdf, odpPdfCodec, odpToPdf, odsToPdf, odtPdfCodec, odtToPdf, openDocx, openOdg, openOdp, openOds, openOdt, openPptx, packageCodec, parsePackage, parseXml, pdfCodec, pdfToDocx, pdfToOdp, pdfToOdt, pdfToPptx, pptxPdfCodec, pptxToPdf, readDocxContent, readOdgContent, readOdpContent, readOdsContent, readOdtContent, readPdf, readPptxContent, reconstructPresentation, reconstructWordprocessing, resolveRelationships, rgbHexToColor, rootElement, serializePackage, systemClock, textContent, throwIfAborted, toCompact, unzipPackage, walk, writePdf, xmlCodec, zipPackage };
+export { AttributeSchema, BinaryPartSchema, COLOR_BLACK, CONTENT_FORMAT_VERSION, CommentSchema, CompactPackageSchema, CompactPartSchema, CompactXmlNodeSchema, ContentBlockSchema, ContentCellValueSchema, ContentDocumentSchema, ContentDrawPageSchema, ContentImageBlockSchema, ContentPageBreakSchema, ContentParagraphSchema, ContentPathPointSchema, ContentPathSegmentSchema, ContentRunSchema, ContentSectionSchema, ContentShapeSchema, ContentSheetCellSchema, ContentSheetColumnSchema, ContentSheetPrintRangeSchema, ContentSheetPrintSettingsSchema, ContentSheetRepeatRangeSchema, ContentSheetRowSchema, ContentSheetSchema, ContentSlideSchema, ContentStrokeSchema, ContentSubpathSchema, ContentTableCellSchema, ContentTableRowSchema, ContentTableSchema, ContentVectorSchema, DEFAULT_LAYOUT_FONT, DefinedNameSchema, DocxBytesSchema, DocxEditor, DocxParagraph, DocxRun, DocxTable, DocxTableCell, DocxTableRow, LAYOUT_FORMAT_VERSION, NOOP_DIAGNOSTIC_SINK, OdgBoxVector, OdgBytesSchema, OdgEditor, OdgLineVector, OdgPage, OdgPathVector, OdpBytesSchema, OdpEditor, OdpShape, OdpSlide, OdsBytesSchema, OdsCell, OdsEditor, OdsSheet, OdtBytesSchema, OdtEditor, OdtList, OdtListItem, OdtParagraph, OdtRun, OdtTable, OdtTableCell, OdtTableRow, PAGE_SIZE_A4, PAGE_SIZE_LETTER, PackageSchema, PartSchema, PdfBytesSchema, PdfEncryptedError, PdfParseError, PptxBytesSchema, PptxEditor, PptxShape, PptxSlide, SLIDE_SIZE_STANDARD, SLIDE_SIZE_WIDESCREEN, XmlCdataSchema, XmlCommentSchema, XmlDeclarationSchema, XmlElementSchema, XmlNodeSchema, XmlPartSchema, XmlPiSchema, XmlTextSchema, attr, base64ToBytes, buildDocxPackage, buildOdgPackage, buildOdpPackage, buildOdsPackage, buildOdtPackage, buildPptxPackage, buildXml, bytesToBase64, childrenWithTag, compactCodec, compactPackageCodec, convertDrawingToLayout, convertPresentationToLayout, convertSpreadsheetToLayout, convertWordprocessingToLayout, createDocx, createLocalDocumentConverter, createOdg, createOdp, createOds, createOdt, createPptx, decodeCompactPackage, decodeEntities, decodePackage, docxPdfCodec, docxToPdf, elementsWithTag, encodeCompactPackage, encodePackage, fixedClock, flipY, fromCompact, isCompactXmlNode, isContentBlock, isXmlNode, odgPdfCodec, odgToPdf, odpPdfCodec, odpToPdf, odsToPdf, odtPdfCodec, odtToPdf, openDocx, openOdg, openOdp, openOds, openOdt, openPptx, packageCodec, parsePackage, parseXml, pdfCodec, pdfToDocx, pdfToOdg, pdfToOdp, pdfToOdt, pdfToPptx, pptxPdfCodec, pptxToPdf, readDocxContent, readOdgContent, readOdpContent, readOdsContent, readOdtContent, readPdf, readPptxContent, reconstructDrawing, reconstructPresentation, reconstructWordprocessing, resolveRelationships, rgbHexToColor, rootElement, serializePackage, systemClock, textContent, throwIfAborted, toCompact, unzipPackage, walk, writePdf, xmlCodec, zipPackage };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "documents.js",
-  "version": "1.46.1",
+  "version": "1.47.0",
   "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": {