ooxml.js 2.6.0 → 2.6.1

package/README.md

@@ -231,7 +231,8 @@ The package is layered from a lossless core outward to lossy convenience views:
 
 ## Gotchas and quirks
 
-- **`readDocx`/`readPptx` are richer than a flat text/shape dump, but still not a round-trip path — here is what's still not captured.** Not modelled: numbering *definitions* themselves (glyph, format, restart-at-level, from `word/numbering.xml`) — only each paragraph's own `numId`/`level` *membership* is captured, so a consumer can group paragraphs into a list but can't render the list's own markers without separately reading `word/numbering.xml`; table cell border styling (`w:tcBorders`, `a:tcPr` line properties — only cell shading/fill is read); docx's own `w:themeColor` run-colour references (real-world runs overwhelmingly use direct `w:val` hex instead); live `PAGE`/`NUMPAGES` field re-evaluation (fields resolve to Word's own cached result text, correct unless a different pagination would change the value); and docx inline/floating images (`w:drawing`) — `readPptx`'s picture-shape reading (`p:pic`) has no docx-side equivalent yet. On the pptx side specifically: connector shapes (`p:cxnSp`) are skipped entirely (decorative, no text); a shape's rotation is passed through from its own local `a:xfrm/@rot` rather than composed through a rotated or flipped parent group (ECMA-376's real composition rule there is one of DrawingML's more arcane corners); and non-table graphic frames (chart/SmartArt/OLE) come through with correct geometry but empty content.
+- **`readDocx`/`readPptx` are richer than a flat text/shape dump, but still not a round-trip path — here is what's still not captured.** `word/numbering.xml`'s own `abstractNum`/`num` level definitions (glyph, format, restart-at-level) are now modelled (`numbering.ts`'s `readNumberingDefinitions`, surfaced as `DocxDocument.numbering`, keyed by `w:numId`) alongside each paragraph's own `numId`/`level` *membership*, so a consumer can both group paragraphs into a list and render the list's own markers. Table cell border styling (`w:tcBorders`) is now read too, alongside cell shading/fill. docx's own `w:themeColor` run-colour references are now resolved against the theme's colour scheme (`w:themeShade`/`w:themeTint` refinement of an already-resolved theme colour is the one piece still not read). docx inline/floating images (`w:drawing`) are now read into `ContentImageBlock` — sniffed from the actual media-part bytes, placed in block flow at the point the drawing was encountered, though a floating image's own `wp:anchor` position (page/margin/paragraph-relative offset) is not recorded, since `ContentImageBlock` has no absolute-positioning field to hold it. Still not modelled: live `PAGE`/`NUMPAGES` field re-evaluation (fields resolve to Word's own cached result text, correct unless a different pagination would change the value). On the pptx side specifically: connector shapes (`p:cxnSp`) are skipped entirely (decorative, no text); a shape's rotation is now composed through every enclosing group's own rotation/flip (`composeShapeRotationDeg`, `typed/shared/drawingml.ts`), not merely passed through from its own local `a:xfrm/@rot`; and non-table graphic frames (chart/SmartArt/OLE) come through with correct geometry but empty content.
+- **xlsx has no native percentage/currency/date/time cell type — both directions of that gap are now closed.** Reading, `typed/xlsx/styles.ts` resolves a cell's style index to a number-format code and `typed/xlsx/number-format.ts` classifies it, so a plain numeric cell wearing the right `numFmt` reads as `ContentCellValue`'s `percentage`/`currency`/`date`/`time`/`dateTime` kind rather than a bare `number` (a currency only carries an ISO 4217 code when the format names one explicitly; a symbol-only format like `[$£-809]` leaves it absent rather than guessing). Writing, `buildXlsxPackage` emits real `numFmt` codes for the same five kinds (including LibreOffice's own `"TRUE";"TRUE";"FALSE"` boolean format, so Excel/Calc display `TRUE`/`FALSE` rather than a bare `1`/`0`), interned on demand into a real `<numFmts>`/`<cellXfs>` pair — every code the writer emits is fed back through the reader's own classifier in the test suite, so the two halves cannot drift. The classifier is not a formatter: `displayText` stays a plain typed-value spelling (`0.4256`, not `"42.56%"`), never the producer's own rendered string.
 - **`test:smoke` depends on a fresh build.** It runs `tsdown && vitest run --project smoke`, so it always rebuilds `dist/` first — don't run it expecting to test a stale build.
 - **`--project` matters for `test/smoke.test.mjs`.** `vitest.config.ts` defines `unit` and `smoke` as separate projects; `pnpm test`/`test:watch`/`test:smoke` always pass the right `--project` flag. A bare `vitest`/`vitest run` with no `--project` filter runs both projects, and `smoke` fails loudly (`Cannot find module '../dist/index.js'`) if `dist/` hasn't been built yet — a clear failure pointing at the cause, not a silent false pass, but still worth knowing if you invoke `vitest` directly instead of through the npm scripts.
 - **Binary-vs-XML part classification is a byte sniff, not an extension check.** `package-io/read.ts`'s `looksLikeXml` looks for a leading `<` after skipping a UTF-8 BOM and whitespace; this is deliberate (no standard OOXML binary part starts with `<`) but means any future binary format starting with `<` would misclassify.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ooxml.js",
-  "version": "2.6.0",
+  "version": "2.6.1",
   "description": "Type-safe, lossless round-trip conversion between OOXML packages (docx, pptx, xlsx) and JSON, built on Zod 4 codecs.",
   "type": "module",
   "repository": {