documents.js 1.43.0 → 1.44.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, a read-and-write live-view editor for docx/pptx/odt/odp 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 ⇄ PDF conversion, one-directional ods/odg → PDF conversion, a read-and-write live-view editor for docx/pptx/odt/odp/ods 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):
+The eight round-trip ergonomic conversions (docx/pptx/odt/odp ⇄ PDF), plus `odsToPdf`/`odgToPdf`'s one-directional additions (there is no `pdfToOds` yet — PDF → spreadsheet reconstruction needs general vector-path tracking in the PDF reader that doesn't exist yet; there is no `pdfToOdg` either, for the equivalent reason on the drawing side — see [Gotchas](#gotchas-and-quirks)):
 
 ```ts
-import { docxToPdf, odpToPdf, odtToPdf, pdfToDocx, pdfToOdp, pdfToOdt, pptxToPdf, pdfToPptx } from 'documents.js';
+import { docxToPdf, odgToPdf, odpToPdf, odsToPdf, odtToPdf, pdfToDocx, pdfToOdp, pdfToOdt, pptxToPdf, pdfToPptx } from 'documents.js';
 
 const pdfBytes = docxToPdf(docxBytes);
 const docxBytes2 = pdfToDocx(pdfBytes);
@@ -46,6 +46,9 @@ const odtBytes2 = pdfToOdt(pdfFromOdt);
 
 const pdfFromOdp = odpToPdf(odpBytes);
 const odpBytes2 = pdfToOdp(pdfFromOdp);
+
+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).
@@ -97,6 +100,19 @@ slide.notes = 'Speaker notes for this slide';
 const bytes = editor.toBytes();
 ```
 
+`createOds`/`openOds` and `OdsEditor`/`OdsSheet`/`OdsCell` are the spreadsheet equivalent — cell addressing has no docx/pptx analogue at all, so this is the one editor family built from scratch rather than reusing `OdtParagraph`/`OdtRun`. Setting a cell far from the origin does not materialise every cell in between: the underlying `table:number-columns-repeated`/`table:number-rows-repeated` runs are split in place at exactly the target position, the same repeat-compression convention `odf.js`'s own reader already reads.
+
+```ts
+import { createOds } from 'documents.js';
+
+const editor = createOds();
+const sheet = editor.addSheet('Sheet1');
+sheet.cell(0, 0).value = { kind: 'string', value: 'Total' }; // 0-based (row, column) -- there is no A1-string overload
+sheet.cell(0, 1).value = { kind: 'currency', value: 42.5, currency: 'USD' };
+sheet.cell(500, 50).value = { kind: 'boolean', value: true }; // does not materialise 500x50 empty cells
+const bytes = editor.toBytes();
+```
+
 Reading and writing PDF bytes directly, without going through docx/pptx:
 
 ```ts
@@ -119,24 +135,24 @@ const pdfFromDocx = z.decode(docxPdfCodec, docxBytes);
 const docxBack = z.encode(docxPdfCodec, pdfFromDocx);
 ```
 
-`readDocxContent`/`readPptxContent`/`readOdtContent`/`readOdpContent` (docx/pptx/odt/odp → `ContentDocument`), `convertWordprocessingToLayout`/`convertPresentationToLayout` (`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`.
+`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)).
 
 ## Architecture
 
 The package is layered from generic primitives outward to the two conversion directions:
 
-- **`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/link items, PDF-native coordinates and units) and `ContentDocument` (the semantic pivot: a discriminated union of `wordprocessing` and `presentation` variants sharing paragraph/run/table/image building blocks) 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/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`) wrapping the actual `XmlElement` objects inside a decoded `Package`, plus `buildDocxPackage`/`buildPptxPackage`/`buildOdtPackage`/`buildOdpPackage` bridging a `ContentDocument` to a fresh package built entirely through those same primitives. `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/`** — 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`) wrapping the actual `XmlElement` objects inside a decoded `Package`, plus `buildDocxPackage`/`buildPptxPackage`/`buildOdtPackage`/`buildOdpPackage`/`buildOdsPackage` bridging a `ContentDocument` to a fresh package built entirely through those same primitives (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/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. Both directions now build the reverse too — `buildOdtPackage` (`src/edit/odt/content.ts`) and `buildOdpPackage` (`src/edit/odp/content.ts`) — closing the PDF → odt/odp direction on the live-view editors above.
-- **`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), `reconstruct.ts` (`LayoutDocument` → `ContentDocument`, both variants: 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), `codec.ts` (`docxPdfCodec`/`pptxPdfCodec`/`odtPdfCodec`/`odpPdfCodec`, a `z.codec()` pair over each), `port.ts`/`local.ts` (the swappable `DocumentConverter` contract and its synchronous local implementation, covering `docx`/`pptx`/`odt`/`odp` → `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). Every direction now builds the reverse too, except odg's — `buildOdtPackage`/`buildOdpPackage`/`buildOdsPackage` (`src/edit/{odt,odp,ods}/content.ts`) — closing the PDF → odt/odp direction on the live-view editors above (ods's own `buildOdsPackage` exists and is exported, but nothing calls it yet — see the `pdfToOds` gotcha below; there is no `buildOdgPackage`/live-view odg editor at all yet, matching `pdfToOdg`'s own absence).
+- **`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`).
 
 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/`.
 
@@ -148,7 +164,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 conversions, and a real createOdp/odpToPdf/pdfToOdp round trip, 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), and a real createOdp/odpToPdf/pdfToOdp round trip, from the built CJS bundle
 pnpm test:corpus   # optional real-world PDF conformance checks against a local, gitignored test/corpus/ (see Fidelity)
 ```
 
@@ -170,6 +186,13 @@ 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.
+- **`odsToPdf` is one-directional — there is no `pdfToOds` yet, and no `reconstructSpreadsheet`.** Unlike odt/odp, going from PDF back to a spreadsheet needs general vector-path tracking in the PDF reader (`src/pdf/interpret.ts` currently only tracks the specific `re` rectangle operator, discarding general `m`/`l`/`c` path construction) so a reconstructed sheet's gridlines can be detected from the recovered geometry — that infrastructure doesn't exist yet. `buildOdsPackage` (`src/edit/ods/content.ts`) is built and exported, ready for `pdfToOds` to call the moment path tracking lands; nothing currently calls it.
+- **`odgToPdf` is one-directional too — there is no `pdfToOdg`, no `reconstructDrawing`, and no live-view odg editor at all.** Reconstructing a `ContentDrawPage`'s own vector-primitive geometry (which recovered path is a rect vs. a genuine curve, where one shape ends and another begins) from PDF geometry alone is a fundamentally different, unstarted problem from `reconstructWordprocessing`/`reconstructPresentation`'s own paragraph/shape geometry clustering — the same `src/pdf/interpret.ts` gap `odsToPdf`'s own gotcha above describes (no general `m`/`l`/`c` path tracking) blocks this direction too, on top of needing its own reconstruction algorithm even once that infrastructure exists.
+- **`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 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.
 - **PDF output uses the standard 14 fonts only — no font embedding.** Helvetica/Times-Roman are genuinely metric-compatible substitutes for Arial/Times New Roman, but Word's actual current defaults (Calibri, Aptos) are not, so line wrapping and pagination will drift slightly from what Word itself would produce. Expect a faithful visual approximation, not a line-identical reproduction.
 - **Reading arbitrary real-world PDFs is the single largest risk surface in this package**, and the parser is honest about its design target: cleanly-generated output from mainstream producers (Word, PowerPoint, Chrome, LibreOffice, Acrobat), recovering from the malformations those producers and their downstream tooling actually create, and failing loudly and specifically on anything else — not matching a mature library's robustness against adversarial input.
 - **Encrypted PDFs are unsupported.** `/Encrypt` present in the trailer throws `PdfEncryptedError`, even for the common empty-user-password case.
@@ -182,7 +205,7 @@ To run a single test file: `pnpm vitest run src/path/to/file.test.ts`.
 
 ## Fidelity
 
-**docx/pptx/odt/odp → PDF** is a genuine layout render: the docx/odt flow/pagination engine and the pptx/odp direct-placement engine both produce real positioned text, images, tables, and (for docx/odt) numbered/bulleted lists, styled through the full cascade (theme fonts/colours, `basedOn` chains, placeholder inheritance for docx/pptx; `style:default-style`/`style:parent-style-name` chains for odt/odp). It is a faithful **visual approximation**, not a pixel- or line-identical reproduction of what Word/PowerPoint/Writer/Impress would themselves render — see the standard-14 font substitution gotcha above.
+**docx/pptx/odt/odp/ods/odg → PDF** is a genuine layout render: the docx/odt flow/pagination engine and the pptx/odp direct-placement engine both produce real positioned text, images, tables, and (for docx/odt) numbered/bulleted lists, styled through the full cascade (theme fonts/colours, `basedOn` chains, placeholder inheritance for docx/pptx; `style:default-style`/`style:parent-style-name` chains for odt/odp). `odg` renders its vector primitives (rect/ellipse/line/path, the last emitted as real PDF `m`/`l`/`c`/`h` content-stream operators, not a polygon approximation of any curve) and reuses the pptx/odp direct-placement engine's own shape conversion for whatever text it also carries. It is a faithful **visual approximation**, not a pixel- or line-identical reproduction of what Word/PowerPoint/Writer/Impress/Draw would themselves render — see the standard-14 font substitution gotcha above.
 
 **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.
 
@@ -204,7 +227,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/edit/odt/*`'s `StyleRegistry`/`resolveStyle` (style interning) and `src/edit/odp/shape.ts`'s `applyOdfTransform`/`resolveOdfShapeGeometry` (rotation), both consumed directly rather than reimplemented. odt and odp → `ContentDocument` reading and PDF conversion are now integrated both ways; ods/odg → `ContentDocument` reading (the equivalent for spreadsheets and drawings) is not yet.
+- [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 — feeding `odgToPdf`; `src/edit/odt/*`'s `StyleRegistry`/`resolveStyle` (style interning) and `src/edit/odp/shape.ts`'s `applyOdfTransform`/`resolveOdfShapeGeometry` (rotation), both 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).
 
 ## License
 

package/dist/index.cjs

@@ -24,6 +24,12 @@ const ContentDocumentSchema = zod.z.discriminatedUnion("kind", [
 		formatVersion: zod.z.literal(1),
 		metadata: document_content_model.LayoutMetadataSchema,
 		sheets: zod.z.array(document_content_model.ContentSheetSchema)
+	}),
+	zod.z.object({
+		kind: zod.z.literal("drawing"),
+		formatVersion: zod.z.literal(1),
+		metadata: document_content_model.LayoutMetadataSchema,
+		pages: zod.z.array(document_content_model.ContentDrawPageSchema)
 	})
 ]);
 //#endregion
@@ -7604,11 +7610,15 @@ function writeText(writer, item, context, substitutions) {
 		writeUnderline(writer, item, item.widthPt ?? encoded.width1000 / 1e3 * item.sizePt * scale, context.measurer);
 	}
 }
-function paintOperatorFor(fill, stroke) {
-	if (fill !== void 0 && stroke !== void 0) return "B";
-	if (fill !== void 0) return "f";
+function paintOperatorFor(fill, stroke, fillRule) {
+	const evenOdd = fillRule === "evenodd";
+	if (fill !== void 0 && stroke !== void 0) return evenOdd ? "B*" : "B";
+	if (fill !== void 0) return evenOdd ? "f*" : "f";
 	if (stroke !== void 0) return "S";
 }
+function formatPoint(x, y) {
+	return `${formatNumber(x)} ${formatNumber(y)}`;
+}
 function writeFillAndStroke(writer, fill, stroke) {
 	if (fill !== void 0) writeRgbOperator(writer, fill, "rg");
 	if (stroke !== void 0) {
@@ -7639,12 +7649,24 @@ function writeEllipse(writer, item) {
 	const ry = item.heightPt / 2;
 	const kx = rx * BEZIER_KAPPA;
 	const ky = ry * BEZIER_KAPPA;
-	const point = (x, y) => `${formatNumber(x)} ${formatNumber(y)}`;
-	writer.writeAscii(`${point(cx + rx, cy)} m\n`);
-	writer.writeAscii(`${point(cx + rx, cy + ky)} ${point(cx + kx, cy + ry)} ${point(cx, cy + ry)} c\n`);
-	writer.writeAscii(`${point(cx - kx, cy + ry)} ${point(cx - rx, cy + ky)} ${point(cx - rx, cy)} c\n`);
-	writer.writeAscii(`${point(cx - rx, cy - ky)} ${point(cx - kx, cy - ry)} ${point(cx, cy - ry)} c\n`);
-	writer.writeAscii(`${point(cx + kx, cy - ry)} ${point(cx + rx, cy - ky)} ${point(cx + rx, cy)} c\n`);
+	writer.writeAscii(`${formatPoint(cx + rx, cy)} m\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(`${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(`${paint}\n`);
+}
+function writeSubpath(writer, subpath) {
+	writer.writeAscii(`${formatPoint(subpath.startXPt, subpath.startYPt)} m\n`);
+	for (const segment of subpath.segments) if (segment.kind === "line") writer.writeAscii(`${formatPoint(segment.xPt, segment.yPt)} l\n`);
+	else writer.writeAscii(`${formatPoint(segment.c1xPt, segment.c1yPt)} ${formatPoint(segment.c2xPt, segment.c2yPt)} ${formatPoint(segment.xPt, segment.yPt)} c\n`);
+	if (subpath.closed) writer.writeAscii("h\n");
+}
+function writePath(writer, item) {
+	const paint = paintOperatorFor(item.fill, item.stroke, item.fillRule);
+	if (paint === void 0) return;
+	writeFillAndStroke(writer, item.fill, item.stroke);
+	for (const subpath of item.subpaths) writeSubpath(writer, subpath);
 	writer.writeAscii(`${paint}\n`);
 }
 function writeImage(writer, item, context) {
@@ -7663,6 +7685,7 @@ function writeContentStream(items, context) {
 	else if (item.kind === "rect") writeRect(writer, item);
 	else if (item.kind === "line") writeLine(writer, item);
 	else if (item.kind === "ellipse") writeEllipse(writer, item);
+	else if (item.kind === "path") writePath(writer, item);
 	return {
 		bytes: writer.toBytes(),
 		substitutions
@@ -8469,6 +8492,17 @@ function readOdsContent(pkg) {
 	};
 }
 //#endregion
+//#region src/odf/odg/read.ts
+function readOdgContent(pkg) {
+	const odgDoc = (0, odf_js.readOdg)(pkg);
+	return {
+		kind: "drawing",
+		formatVersion: 1,
+		metadata: { ...odgDoc.metadata },
+		pages: odgDoc.pages
+	};
+}
+//#endregion
 //#region src/pdf/text-layout.ts
 const WORD_OR_WHITESPACE_PATTERN = /\n|\s+|\S+/g;
 function atomizeRuns(runs, measurer) {
@@ -9500,6 +9534,118 @@ function convertSpreadsheetToLayout(doc, options) {
 	};
 }
 //#endregion
+//#region src/layout/drawing.ts
+function convertRectVector(vector, pageHeightPt, out) {
+	const flipped = flipY(vector.frame, pageHeightPt);
+	out.push({
+		kind: "rect",
+		xPt: flipped.xPt,
+		yPt: flipped.yPt,
+		widthPt: flipped.widthPt,
+		heightPt: flipped.heightPt,
+		fill: vector.fill,
+		stroke: vector.stroke,
+		sourcePath: vector.sourcePath
+	});
+}
+function convertEllipseVector(vector, pageHeightPt, out) {
+	const flipped = flipY(vector.frame, pageHeightPt);
+	out.push({
+		kind: "ellipse",
+		xPt: flipped.xPt,
+		yPt: flipped.yPt,
+		widthPt: flipped.widthPt,
+		heightPt: flipped.heightPt,
+		fill: vector.fill,
+		stroke: vector.stroke,
+		sourcePath: vector.sourcePath
+	});
+}
+function convertLineVector(vector, pageHeightPt, out) {
+	out.push({
+		kind: "line",
+		x1Pt: vector.from.xPt,
+		y1Pt: pageHeightPt - vector.from.yPt,
+		x2Pt: vector.to.xPt,
+		y2Pt: pageHeightPt - vector.to.yPt,
+		color: vector.stroke.color,
+		widthPt: vector.stroke.widthPt,
+		sourcePath: vector.sourcePath
+	});
+}
+function placePathPoint(frame, point, pageHeightPt) {
+	return {
+		xPt: frame.xPt + point.xPt,
+		yPt: pageHeightPt - frame.yPt - point.yPt
+	};
+}
+function convertPathVector(vector, pageHeightPt, out) {
+	const subpaths = vector.subpaths.map((subpath) => {
+		const start = placePathPoint(vector.frame, subpath.start, pageHeightPt);
+		return {
+			startXPt: start.xPt,
+			startYPt: start.yPt,
+			closed: subpath.closed,
+			segments: subpath.segments.map((segment) => {
+				if (segment.kind === "line") {
+					const to = placePathPoint(vector.frame, segment.to, pageHeightPt);
+					return {
+						kind: "line",
+						xPt: to.xPt,
+						yPt: to.yPt
+					};
+				}
+				const control1 = placePathPoint(vector.frame, segment.control1, pageHeightPt);
+				const control2 = placePathPoint(vector.frame, segment.control2, pageHeightPt);
+				const to = placePathPoint(vector.frame, segment.to, pageHeightPt);
+				return {
+					kind: "cubic",
+					c1xPt: control1.xPt,
+					c1yPt: control1.yPt,
+					c2xPt: control2.xPt,
+					c2yPt: control2.yPt,
+					xPt: to.xPt,
+					yPt: to.yPt
+				};
+			})
+		};
+	});
+	out.push({
+		kind: "path",
+		subpaths,
+		fill: vector.fill,
+		fillRule: vector.fillRule,
+		stroke: vector.stroke,
+		sourcePath: vector.sourcePath
+	});
+}
+function convertVector(vector, pageHeightPt, out) {
+	if (vector.kind === "rect") convertRectVector(vector, pageHeightPt, out);
+	else if (vector.kind === "ellipse") convertEllipseVector(vector, pageHeightPt, out);
+	else if (vector.kind === "line") convertLineVector(vector, pageHeightPt, out);
+	else convertPathVector(vector, pageHeightPt, out);
+}
+function convertPage(page, measurer, images) {
+	const items = [];
+	for (const vector of page.vectors) convertVector(vector, page.size.heightPt, items);
+	for (const shape of page.shapes) convertShape(shape, page.size.heightPt, measurer, images, items);
+	return {
+		widthPt: page.size.widthPt,
+		heightPt: page.size.heightPt,
+		items
+	};
+}
+function convertDrawingToLayout(doc, options) {
+	const images = {};
+	const pages = doc.pages.map((page) => convertPage(page, options.measurer, images));
+	return {
+		formatVersion: document_content_model.LAYOUT_FORMAT_VERSION,
+		metadata: doc.metadata,
+		pages,
+		images
+	};
+}
+//#endregion
 //#region src/layout/reconstruct.ts
 const ZERO_MARGINS = {
 	topPt: 0,
@@ -9879,6 +10025,14 @@ function odsToPdf(bytes, options) {
 		onSubstitution: options?.onSubstitution
 	});
 }
+function odgToPdf(bytes, options) {
+	const content = readOdgContent((0, odf_js.decodePackage)(bytes));
+	if (content.kind !== "drawing") throw new Error("readOdgContent returned a non-drawing ContentDocument");
+	return writePdf(convertDrawingToLayout(content, { measurer: createStandardFontMeasurer() }), {
+		signal: options?.signal,
+		onSubstitution: options?.onSubstitution
+	});
+}
 function pdfToDocx(bytes, options) {
 	const content = reconstructWordprocessing(readPdf(bytes, {
 		signal: options?.signal,
@@ -9948,6 +10102,10 @@ const SUPPORTED_CONVERSIONS = [
 		source: "ods",
 		target: "pdf"
 	},
+	{
+		source: "odg",
+		target: "pdf"
+	},
 	{
 		source: "pdf",
 		target: "docx"
@@ -10053,6 +10211,19 @@ function createLocalDocumentConverter() {
 					diagnostics
 				});
 			}
+			if (source.format === "odg" && targetFormat === "pdf") {
+				const bytes = odgToPdf(source.bytes, {
+					signal: options.signal,
+					onSubstitution: (s, c) => diagnostics.push(substitutionDiagnostic(s, c))
+				});
+				return Promise.resolve({
+					document: {
+						format: "pdf",
+						bytes
+					},
+					diagnostics
+				});
+			}
 			if (source.format === "pdf" && targetFormat === "docx") {
 				const bytes = pdfToDocx(source.bytes, {
 					signal: options.signal,
@@ -10172,6 +10343,12 @@ Object.defineProperty(exports, "ContentCellValueSchema", {
 	}
 });
 exports.ContentDocumentSchema = ContentDocumentSchema;
+Object.defineProperty(exports, "ContentDrawPageSchema", {
+	enumerable: true,
+	get: function() {
+		return document_content_model.ContentDrawPageSchema;
+	}
+});
 Object.defineProperty(exports, "ContentImageBlockSchema", {
 	enumerable: true,
 	get: function() {
@@ -10190,6 +10367,18 @@ Object.defineProperty(exports, "ContentParagraphSchema", {
 		return document_content_model.ContentParagraphSchema;
 	}
 });
+Object.defineProperty(exports, "ContentPathPointSchema", {
+	enumerable: true,
+	get: function() {
+		return document_content_model.ContentPathPointSchema;
+	}
+});
+Object.defineProperty(exports, "ContentPathSegmentSchema", {
+	enumerable: true,
+	get: function() {
+		return document_content_model.ContentPathSegmentSchema;
+	}
+});
 Object.defineProperty(exports, "ContentRunSchema", {
 	enumerable: true,
 	get: function() {
@@ -10256,6 +10445,18 @@ Object.defineProperty(exports, "ContentSlideSchema", {
 		return document_content_model.ContentSlideSchema;
 	}
 });
+Object.defineProperty(exports, "ContentStrokeSchema", {
+	enumerable: true,
+	get: function() {
+		return document_content_model.ContentStrokeSchema;
+	}
+});
+Object.defineProperty(exports, "ContentSubpathSchema", {
+	enumerable: true,
+	get: function() {
+		return document_content_model.ContentSubpathSchema;
+	}
+});
 Object.defineProperty(exports, "ContentTableCellSchema", {
 	enumerable: true,
 	get: function() {
@@ -10274,6 +10475,12 @@ Object.defineProperty(exports, "ContentTableSchema", {
 		return document_content_model.ContentTableSchema;
 	}
 });
+Object.defineProperty(exports, "ContentVectorSchema", {
+	enumerable: true,
+	get: function() {
+		return document_content_model.ContentVectorSchema;
+	}
+});
 Object.defineProperty(exports, "DEFAULT_LAYOUT_FONT", {
 	enumerable: true,
 	get: function() {
@@ -10456,6 +10663,7 @@ Object.defineProperty(exports, "compactPackageCodec", {
 		return ooxml_js.compactPackageCodec;
 	}
 });
+exports.convertDrawingToLayout = convertDrawingToLayout;
 exports.convertPresentationToLayout = convertPresentationToLayout;
 exports.convertSpreadsheetToLayout = convertSpreadsheetToLayout;
 exports.convertWordprocessingToLayout = convertWordprocessingToLayout;
@@ -10529,6 +10737,7 @@ Object.defineProperty(exports, "isXmlNode", {
 		return ooxml_js.isXmlNode;
 	}
 });
+exports.odgToPdf = odgToPdf;
 exports.odpPdfCodec = odpPdfCodec;
 exports.odpToPdf = odpToPdf;
 exports.odsToPdf = odsToPdf;
@@ -10565,6 +10774,7 @@ exports.pdfToPptx = pdfToPptx;
 exports.pptxPdfCodec = pptxPdfCodec;
 exports.pptxToPdf = pptxToPdf;
 exports.readDocxContent = readDocxContent;
+exports.readOdgContent = readOdgContent;
 exports.readOdpContent = readOdpContent;
 exports.readOdsContent = readOdsContent;
 exports.readOdtContent = readOdtContent;