pdf-codec 1.7.0 → 1.9.0

package/README.md

@@ -98,7 +98,7 @@ const { box } = layoutFormula(mathml, { metrics: metricsAt(12), sizePt: 12, colo
 const pdfBytes = writePdf(doc, { formulas: [{ pageIndex: 0, xPt: 50, yPt: 700, box }] });
 ```
 
-Because `MathBox` and its own constituent types (`MathGlyphRun`/`MathRule`/`MathStroke`/`MathColor`) are plain, structurally-typed data — not a class, not branded — any producer whose output happens to match the shape works here with no cast, no wrapper, and no transformation, whether or not it imports this package at all.
+Because `MathBox` and its own constituent types (`MathGlyphRun`/`MathRule`/`MathStroke`/`MathAssembledGlyphs`/`MathColor`) are plain, structurally-typed data — not a class, not branded — any producer whose output happens to match the shape works here with no cast, no wrapper, and no transformation, whether or not it imports this package at all.
 
 Sizing a stretchy glyph — a parenthesis or brace tall enough to wrap a big fraction, a radical sign sized to its own radicand, an over-brace as wide as the content under it — is the OpenType `MATH` table's `MathVariants` job, and `loadMathFont()` exposes it directly. `stretchGlyph` takes a target extent in points and returns the glyph(s) to draw with each one's own offset along the stretch axis, already in points at the requested font size:
 
@@ -114,7 +114,11 @@ const paren = stretchGlyph(0x28, 'vertical', 40, 12); // a '(' stretched to 40pt
 
 Three outcomes are possible and `kind` records which happened: `'base'` when the unstretched glyph was already big enough, `'variant'` when one of the font's own pre-drawn larger glyphs was selected (always preferred — a hand-drawn glyph beats a glued-together one), and `'assembly'` when the construction was genuinely built by repeating the font's own extender piece between its end pieces, overlapping each seam by as much as both sides' declared connector lengths allow so the joined outlines meet cleanly. `offset` is measured along the stretch axis from the construction's own start — the bottom for a vertical construction, the left for a horizontal one. For a caller working in design units rather than points, `MathFont.stretchyConstruction(codePoint, axis)` returns the raw parsed `MathVariants` data and `assembleStretchyGlyph` performs the same computation over it.
 
-**Placing a stretched construction on a page is not something this package can do for you today**, and that is a real, tracked gap rather than an oversight: `MathBox`'s own `MathGlyphRun` carries a Unicode *string*, which the writer resolves to glyph IDs through the font's `cmap`, but most of the glyphs a `MathVariants` construction names have no Unicode code point to put in that string. Every pre-built larger variant is unencoded, and so are the radical's and the over-brace's assembly pieces; the bracket family is the one exception, since Unicode gives its pieces dedicated code points (the U+239B–U+23AD block — which is also an independent confirmation that assembly parts really are listed bottom-first, given `LEFT PARENTHESIS LOWER HOOK` comes first and `UPPER HOOK` last). Drawing the rest needs a glyph-ID-carrying `MathLayoutItem` kind, added to `MathBox` in both `documents.js`'s own `src/mathml/layout-types.ts` and this package's `src/math-types.ts` mirror, plus handling in `math-content-write.ts` and `collectUsedGlyphs` (the latter keys the emitted `/W` array and ToUnicode CMap off code points today). Until that lands, `stretchGlyph` is real, tested measurement and placement data a layout engine can size boxes from, not something it can yet render.
+A stretched construction is genuinely drawable, through `MathBox`'s own `MathAssembledGlyphs` item kind: a list of `{ glyphId, xPt, yPt }` placements addressed by **glyph ID**, not by Unicode text. That distinction is the whole point rather than a convenience — most of the glyphs a `MathVariants` construction names have no Unicode code point at all, so they could never travel through `MathGlyphRun.text`, which the writer resolves through the font's `cmap`. Every pre-built larger variant is unencoded, and so are the radical's and the over-brace's assembly pieces; the bracket family is the one exception, since Unicode gives its pieces dedicated code points (the U+239B–U+23AD block — which is also an independent confirmation that assembly parts really are listed bottom-first, given `LEFT PARENTHESIS LOWER HOOK` comes first and `UPPER HOOK` last). Drawing by glyph ID works regardless, because the composite font this package embeds is Identity-H with CID == GID (see [Gotchas](#gotchas-and-quirks)), so a bare glyph ID is directly showable with no `cmap` involvement.
+
+The one thing a glyph ID cannot carry is meaning: an unencoded glyph gets no ToUnicode entry, so `MathAssembledGlyphs` also carries the operator's own original `text` (`"("`, `"["`), which `math-content-write.ts` emits as an `/ActualText` marked-content span around the whole construction. A tall assembled bracket therefore still extracts, searches, and copies as `(`.
+
+`MathFontMetrics.stretch` is the layout-facing form of all this, and the one a layout engine actually calls: it resolves a construction at a target size and additionally **measures** it — `inkAscentPt`/`inkDescentPt` are the whole construction's real ink extent about its drawing origin, taken from actual glyph outlines. Without that a caller cannot place the result, since a construction's ink neither starts at its drawing origin (a large parenthesis variant straddles the baseline) nor is bounded by its advance-derived `size`.
 
 Building a layout engine on top of this codec (this is what `documents.js`'s own `src/layout/` does for docx/pptx/odt/odp/ods/odg): `TextMeasurer`/`createStandardFontMeasurer` and `wrapRunsToWidth` answer "how wide does this text render, and where does this line break" against the standard-14 metrics; `resolveStandardFont`/`STANDARD_METRICS` map an arbitrary requested family/weight/style onto one of the 14 standard PDF faces and that face's own AFM-derived metrics; `rotatePointAboutCenter` handles shape-rotation placement math. None of these do any PDF I/O themselves — they're the same primitives `writePdf`/`readPdf` use internally, exported so a caller assembling its own `LayoutDocument` (from any source format) can measure and wrap text identically to how this package will actually render it.
 
@@ -171,12 +175,12 @@ The package is layered from generic primitives outward to the codec itself:
 - **`src/util/`** — two small, independently-duplicated copies of logic that lives elsewhere in the family for a reason narrow enough not to warrant a shared dependency: `base64.ts` (isomorphic base64 ⇄ `Uint8Array`, a verbatim copy of `odf.js`'s own `src/util/base64.ts`, replacing a dependency this codec used to have on `ooxml.js` purely for this one helper pair) and `abort.ts` (`throwIfAborted`, a four-line signal-check helper called at every page loop boundary in `write.ts`/`read.ts` — there is no `await` point in this package's synchronous reader/writer pipeline for cancellation to hook into implicitly, so every long-running loop checks explicitly instead; a duplicate of `documents.js`'s own `src/ports/abort.ts`, which stays there since other, non-PDF consumers still depend on it in that repository).
 - **`src/crypto/`** — MD5, SHA-256/384/512, RC4, and AES-CBC, hand-written with zero local imports, exactly like `src/bytes/`. Not a preference: ISO 32000-1's own key-derivation algorithms name MD5 and RC4 directly, neither of which any platform crypto API this package could portably reach still offers, and `crypto.subtle` is asynchronous where this codec's read path is synchronous end to end. Reaching for `node:crypto` would put a Node builtin inside a `src/` tree that deliberately has none and is built with `platform: 'neutral'`, breaking the browser bundle its downstream consumer depends on. Each module cites the specification it implements (RFC 1321, FIPS 180-4, FIPS 197) and is tested against that specification's own published conformance vectors. MD5 and RC4 are cryptographically broken and are here solely to *read* files that already exist and whose format mandates them.
 - **The codec itself, importing only `math-types`/`formula`/`bytes`/`image`/`crypto` (no OOXML or ODF 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), `font-registry.ts` (the source-document → caller-supplied → vendored-substitute → standard-14 resolution port sitting in front of `resolveStandardFont`, plus `resolveFaceWithRegistry`, the one step both the measurer and the writer resolve through so they can never disagree about which face a `LayoutFont` means), `measure.ts`/`text-layout.ts` (greedy line-wrapping, measured against either a standard-14 face's AFM widths plus a per-family correction or a resolved face's own real `hmtx` advances — never both, see [Fidelity](#fidelity)), `matrix.ts`, `content-write.ts` (`LayoutItem[]` → content-stream operators, with text branching on whether its font resolved to a standard-14 face shown as a WinAnsi byte string or an embedded one shown as Identity-H 2-byte CIDs), `write.ts` (the full object graph, classic cross-reference table, trailer, and — when `WritePdfOptions.formulas` is non-empty — one embedded math composite font group, plus one embedded text font group per face `WritePdfOptions.fonts` resolved, each allocated once in a fixed sorted order and shared across pages).
-  - **sfnt font tables**: `sfnt.ts` (a bounds-checked sfnt table-directory reader, big-endian primitive readers, and the `hasBytes` range check every table parser below pre-checks with), `cmap-table.ts` (Unicode → glyph ID, formats 4/12/6), `hmtx-table.ts` (per-glyph advance widths), `font-tables.ts` (`head`/`maxp`/`OS/2`/`post`/`name` — design grid, glyph count, vertical metrics and style bits, italic angle and underline geometry, PostScript and family names), `glyf.ts` (the `loca` offset index, per-glyph headers, a composite glyph's own component records — a composite refers to its base letter and combining marks by glyph ID, and those references nest, so subsetting one safely means taking the transitive closure over this walk — and `glyphInkBounds`, a glyph's own tight ink box, read straight out of a simple glyph's header where the format already states it and unioned from a composite's own transformed, placed components where it does not), and `math-table.ts` (the OpenType `MATH` table's constants, glyph-info, and variants subtables). Every one of these parsers degrades to `undefined` on a missing or truncated table rather than throwing: the vendored fonts are trusted, but a font extracted from an arbitrary source document is not.
-  - **sfnt subsetting**: `sfnt-subset.ts` (a TrueType-outline glyph subsetter: Unicode code points → glyph IDs through `cmap-table.ts`, the transitive closure over `glyf.ts`'s composite-component walk, then a rebuilt sfnt container carrying only those glyphs' outlines). **Glyph IDs are preserved, never renumbered** — an unused ID below the highest used one survives as an empty `loca` entry rather than being squeezed out — which keeps every composite's own component references correct inside bytes copied verbatim, keeps a caller's already-resolved glyph IDs valid against the subset, and makes CID == GID trivially true for the embedded program (a `/CIDFontType2` then needs only `/CIDToGIDMap /Identity`). The output rebuilds `head`/`hhea`/`maxp`/`loca`/`glyf`/`hmtx` (with `indexToLocFormat` forced long, one always-legal code path), copies the hinting programs (`cvt `/`fpgm`/`prep`) verbatim, stubs `post` as a version 3.0 "no glyph names" header, and omits `cmap`/`name`/`OS/2`/`GSUB`/`GPOS`/`kern` — none of which an embedded `CIDFontType2` program is read through (ISO 32000-1 9.9). The honest cost of preserving IDs: `loca` and `hmtx` stay proportional to the highest used glyph ID rather than to the number of glyphs kept, so for a document touching one glyph near the end of a large font's glyph order, most of the (already much smaller) output is those two index tables rather than outline data. Applies to `glyf`-flavoured fonts only; a CFF-flavoured one returns `undefined`, the same scope boundary [Fidelity](#fidelity) states for the embedded math font.
-  - **Embedded math font**: `math-font.ts` (parses and caches the vendored STIX Two Math font once per process, exposing a size-specific `MathFontMetrics` implementation and a points-in/points-out stretchy-glyph entry point), `math-stretch.ts` (the OpenType MATH two-stage stretching model over that parsed `MathVariants` data: pick the smallest pre-built variant that reaches the target, else assemble from repeated parts with every seam overlapped inside both sides' own declared connector lengths -- unit-agnostic, so it works in design units or points alike), `math-font-write.ts` (builds the `/Type0`/`/CIDFontType0`/`/FontDescriptor`/`/FontFile3`/ToUnicode object group), `math-content-write.ts` (a `PositionedFormula[]` → PDF content-stream bytes, Identity-H 2-byte CIDs for text-showing, `re`/`m`/`l` operators for rules and the radical hook). See [Fidelity](#fidelity) for the CFF-full-embed (not glyph-subsetted) simplification this makes.
-  - **Embedded text faces**: `embedded-font.ts` (parses and caches one TrueType-outline face's `cmap`/`hmtx`/`hhea`/`head`/`OS/2`/`post`/`name` metrics, and `encodeForShowEmbedded`, the single code path both measurement and text-showing go through — the same reason `winansi.ts`'s `encodeForShow` exists, since encoding and measuring separately lets the two disagree about which characters resolved to which glyph and silently desyncs a computed wrap point from the drawn line). Every geometry field it exposes is converted into PDF's 1000-units-per-em glyph space (ISO 32000-1 9.8.1), which a font's own design grid frequently is not: STIX Two Math is drawn on a 1000-unit em so that factor is an identity for the math font, but Carlito is drawn on a 2048-unit em, where getting the conversion wrong is silent rather than loud — the font simply renders with roughly twice its intended metrics and nothing anywhere reports an error. The serif flag a `/FontDescriptor` needs is read off the face's own PANOSE classification rather than guessed from its family name. `embedded-font-write.ts` builds the `/Type0`/`/CIDFontType2`/`/FontDescriptor`/`/FontFile2`/ToUnicode object group, with `/CIDToGIDMap /Identity` written explicitly (stating outright the CID == GID invariant `sfnt-subset.ts`'s GID-preserving design guarantees) and `/Length1` set to the **uncompressed** subset length — the single most commonly mis-set key in TrueType embedding, since the obvious-looking value, the stream's own `/Length`, is silently accepted by lenient readers and rejected by strict ones. Its subset tag (`ABCDEF+Carlito-Regular`, six uppercase letters per 9.6.4) is a CRC32 over the face's PostScript name and its exact ascending glyph-ID list, so identical input yields byte-identical output and two subsets of one face carrying different glyphs can never be mistaken for one another.
-  - **ToUnicode CMaps**: `tounicode.ts`, shared by both embedded-font writers above rather than duplicated in each — a character code → Unicode code point mapping written as a bfchar CMap (9.10.3), with supplementary-plane code points encoded as genuine UTF-16BE surrogate pairs and entries emitted in blocks of at most 100, the limit the CMap syntax sets and one a subsetted text face routinely exceeds.
+  - **Write**: `objects.ts` (the `PdfObject` discriminated union), `afm-widths.ts`/`encoding.ts`/`winansi.ts`/`fonts.ts` (standard-14 metrics, WinAnsi encoding, family resolution), `font-registry.ts` (the source-document → caller-supplied → vendored-substitute → standard-14 resolution port sitting in front of `resolveStandardFont`, plus `resolveFaceWithRegistry`, the one step both the measurer and the writer resolve through so they can never disagree about which face a `LayoutFont` means), `measure.ts`/`text-layout.ts` (greedy line-wrapping, measured against either a standard-14 face's AFM widths plus a per-family correction or a resolved face's own real `hmtx` advances — never both, see [Fidelity](#fidelity)), `matrix.ts`, `content-write.ts` (`LayoutItem[]` → content-stream operators, with text branching on whether its font resolved to a standard-14 face shown as a WinAnsi byte string with `Tj` or an embedded one shown as Identity-H 2-byte CIDs, split at that face's own pair-kerning adjustments into a `TJ` array where it has any to apply and shown as a single unsplit `Tj` string where it does not), `write.ts` (the full object graph, classic cross-reference table, trailer, and — when `WritePdfOptions.formulas` is non-empty — one embedded math composite font group, plus one embedded text font group per face `WritePdfOptions.fonts` resolved, each allocated once in a fixed sorted order and shared across pages).
+  - **sfnt font tables**: `sfnt.ts` (a bounds-checked sfnt table-directory reader, big-endian primitive readers, and the `hasBytes` range check every table parser below pre-checks with), `cmap-table.ts` (Unicode → glyph ID, formats 4/12/6), `hmtx-table.ts` (per-glyph advance widths), `font-tables.ts` (`head`/`maxp`/`OS/2`/`post`/`name` — design grid, glyph count, vertical metrics and style bits, italic angle and underline geometry, PostScript and family names), `glyf.ts` (the `loca` offset index, per-glyph headers, a composite glyph's own component records — a composite refers to its base letter and combining marks by glyph ID, and those references nest, so subsetting one safely means taking the transitive closure over this walk — and `glyphInkBounds`, a glyph's own tight ink box, read straight out of a simple glyph's header where the format already states it and unioned from a composite's own transformed, placed components where it does not), and `math-table.ts` (the OpenType `MATH` table's constants, glyph-info, and variants subtables). `ot-layout-common.ts` holds the two Common Table Formats every OpenType Layout table indexes glyphs through — Coverage and ClassDef — stored as sorted glyph ranges and searched by bisection rather than expanded into a glyph-keyed map, since six bytes of a format 2 record can legitimately declare a 65536-glyph range and expanding every range of every subtable turns a small untrusted font into a large allocation. `gpos-table.ts` reads a face's own `GPOS` table for exactly one thing: how much the font wants the advance of glyph A adjusted when glyph B follows it. It resolves the `kern` feature through the ScriptList (rather than sweeping the FeatureList for every feature tagged `kern`, which is what would apply a font's Cyrillic or Greek kerning lookups to Latin text), handles both PairPos subtable formats and the LookupType 9 Extension indirection — all three are real code paths, since Carlito reaches its kerning only through Extension-wrapped format 2 subtables while Caladea uses LookupType 2 directly and mixes formats inside one lookup — and reads only the first glyph's XAdvance, the one field a horizontal left-to-right run's next glyph position can depend on. Mark attachment, cursive joining, and contextual positioning have no consumer in a codec that positions glyphs itself, so they are not parsed. Every one of these parsers degrades to `undefined` on a missing or truncated table rather than throwing: the vendored fonts are trusted, but a font extracted from an arbitrary source document is not.
+  - **sfnt subsetting**: `sfnt-subset.ts` (a TrueType-outline glyph subsetter: Unicode code points → glyph IDs through `cmap-table.ts`, the transitive closure over `glyf.ts`'s composite-component walk, then a rebuilt sfnt container carrying only those glyphs' outlines). **Glyph IDs are preserved, never renumbered** — an unused ID below the highest used one survives as an empty `loca` entry rather than being squeezed out — which keeps every composite's own component references correct inside bytes copied verbatim, keeps a caller's already-resolved glyph IDs valid against the subset, and makes CID == GID trivially true for the embedded program (a `/CIDFontType2` then needs only `/CIDToGIDMap /Identity`). The output rebuilds `head`/`hhea`/`maxp`/`loca`/`glyf`/`hmtx` (with `indexToLocFormat` forced long, one always-legal code path), copies the hinting programs (`cvt `/`fpgm`/`prep`) verbatim, stubs `post` as a version 3.0 "no glyph names" header, and omits `cmap`/`name`/`OS/2`/`GSUB`/`GPOS`/`kern` — none of which an embedded `CIDFontType2` program is read through (ISO 32000-1 9.9). Dropping `GPOS` costs the document no kerning even though its pairs are now genuinely applied: the adjustments are resolved at write time and written into the page's own `TJ` array, so a consumer reads them off the content stream rather than out of the font program. The honest cost of preserving IDs: `loca` and `hmtx` stay proportional to the highest used glyph ID rather than to the number of glyphs kept, so for a document touching one glyph near the end of a large font's glyph order, most of the (already much smaller) output is those two index tables rather than outline data. Applies to `glyf`-flavoured fonts only; a CFF-flavoured one returns `undefined`, the same scope boundary [Fidelity](#fidelity) states for the embedded math font.
+  - **Embedded math font**: `math-font.ts` (parses and caches the vendored STIX Two Math font once per process, exposing a size-specific `MathFontMetrics` implementation and a points-in/points-out stretchy-glyph entry point), `math-stretch.ts` (the OpenType MATH two-stage stretching model over that parsed `MathVariants` data: pick the smallest pre-built variant that reaches the target, else assemble from repeated parts with every seam overlapped inside both sides' own declared connector lengths -- unit-agnostic, so it works in design units or points alike), `math-font-write.ts` (builds the `/Type0`/`/CIDFontType0`/`/FontDescriptor`/`/FontFile3`/ToUnicode object group), `math-content-write.ts` (a `PositionedFormula[]` → PDF content-stream bytes, Identity-H 2-byte CIDs for text-showing, `re`/`m`/`l` operators for rules and the radical hook, and one glyph-ID-addressed text object per placement of a stretched construction, wrapped in an `/ActualText` marked-content span). See [Fidelity](#fidelity) for the CFF-full-embed (not glyph-subsetted) simplification this makes.
+  - **Embedded text faces**: `embedded-font.ts` (parses and caches one TrueType-outline face's `cmap`/`hmtx`/`hhea`/`head`/`OS/2`/`post`/`name` metrics and its own `GPOS` pair kerning, and `encodeForShowEmbedded`, the single code path both measurement and text-showing go through — the same reason `winansi.ts`'s `encodeForShow` exists, since encoding and measuring separately lets the two disagree about which characters resolved to which glyph and silently desyncs a computed wrap point from the drawn line). Pair kerning is applied inside that same one path, for that same one reason: one pass over one glyph sequence produces both the run's width and the list of adjustments `content-write.ts` positions its glyphs by, so a measurement that included kerning while the page drew unkerned glyphs (or the reverse) is not a state this can reach. Kerning is looked up between the glyphs that will actually be shown, `.notdef` included, matching the same "measure what will be drawn, not what was asked for" rule the missing-glyph handling already follows. Every geometry field it exposes is converted into PDF's 1000-units-per-em glyph space (ISO 32000-1 9.8.1), which a font's own design grid frequently is not: STIX Two Math is drawn on a 1000-unit em so that factor is an identity for the math font, but Carlito is drawn on a 2048-unit em, where getting the conversion wrong is silent rather than loud — the font simply renders with roughly twice its intended metrics and nothing anywhere reports an error. The serif flag a `/FontDescriptor` needs is read off the face's own PANOSE classification rather than guessed from its family name. `embedded-font-write.ts` builds the `/Type0`/`/CIDFontType2`/`/FontDescriptor`/`/FontFile2`/ToUnicode object group, with `/CIDToGIDMap /Identity` written explicitly (stating outright the CID == GID invariant `sfnt-subset.ts`'s GID-preserving design guarantees) and `/Length1` set to the **uncompressed** subset length — the single most commonly mis-set key in TrueType embedding, since the obvious-looking value, the stream's own `/Length`, is silently accepted by lenient readers and rejected by strict ones. Its subset tag (`ABCDEF+Carlito-Regular`, six uppercase letters per 9.6.4) is a CRC32 over the face's PostScript name and its exact ascending glyph-ID list, so identical input yields byte-identical output and two subsets of one face carrying different glyphs can never be mistaken for one another.
+  - **ToUnicode CMaps**: `tounicode.ts`, shared by both embedded-font writers above rather than duplicated in each — a character code → Unicode code point mapping written as a bfchar CMap (9.10.3), with supplementary-plane code points encoded as genuine UTF-16BE surrogate pairs and entries emitted in blocks of at most 100, the limit the CMap syntax sets and one a subsetted text face routinely exceeds. A glyph with no code point to map back to (a stretchy construction's own unencoded pieces) is dropped from the CMap rather than mapped to a stand-in that would extract as the wrong character; the `/ActualText` span around such a construction carries its real text instead.
   - **CFF reading**: `cff.ts` holds the two container structures every CFF program is built out of — the `INDEX` and the `DICT` — shared by the two readers built on it rather than hand-rolled twice. `cff-bounds.ts` is a Type 2 charstring interpreter that computes each glyph's own tight ink bounding box: a CFF glyph, unlike a TrueType one, stores no bounding box anywhere, so the only way to know what area it covers is to run its outline program. It is a path *walker*, not a rasteriser — it tracks the current point through every path-construction operator and solves each cubic's real extrema from the roots of its own derivative, so a bound it reports is genuinely tight rather than a control-point hull. Hint operators are decoded only far enough to know how many bytes a following `hintmask` consumes. Verified against the vendored STIX Two Math font's whole 5,543-glyph repertoire: every glyph matches fontTools' own `BoundsPen` to within 0.01 design units, and the union of all 5,543 computed boxes lands exactly on the font's own `head` table `FontBBox`. Out of scope, each reported as `undefined` rather than guessed at: a CID-keyed program (its local subroutines live per-FD behind `FDArray`/`FDSelect`), `endchar` in its four-argument seac-like form (which needs the charset and Standard Encoding to resolve into two other glyphs), and the arithmetic/storage/conditional escaped operators. `cff-probe.ts` reads a bare CFF program's header, Name INDEX, and just enough of its Top DICT to detect the `ROS` operator (the escaped `12 30` whose presence *is* the definition of a CID-keyed font, CFF 1.0 Appendix H). It exists to make the embedding path **refuse** such a font rather than mis-embed it: a CID-keyed CFF carries its own charset mapping CIDs onto glyph indices, so CID == GID does not hold, and showing text through Identity-H against one anyway produces no error anywhere — the file is structurally valid, every reader accepts it, and the page simply renders the wrong glyphs. Not wired into any write path yet; it is the guard a later source-embedded-font phase needs. It correctly reports the vendored STIX Two Math font's own `CFF ` table as *not* CID-keyed, which is what makes `math-font-write.ts`'s existing embedding sound.
   - **Read**: `lexer.ts`/`parse.ts` (byte tokenizer and tokens → `PdfObject`), `filters.ts`/`predictors.ts` (Flate/LZW/ASCII85/ASCIIHex/RunLength/CCITTFax, 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), `encrypt.ts` (the standard security handler: `/Encrypt` parsing, empty-user-password key derivation and `/U` verification, per-object keys, and the string/stream decryption `document.ts` applies transparently as each indirect object is fetched — see [Gotchas](#gotchas-and-quirks)), `content-read.ts`/`interpret.ts` (the content-stream tokenizer and graphics/text state machine, including form-XObject recursion and general vector-path tracking — see [Gotchas](#gotchas-and-quirks)), `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`, plus a standalone, ~20-line local copy of just the `%PDF-` header check `PdfBytesSchema` needs (`documents.js`'s own equivalent schema lives in a file that also carries unrelated docx/pptx/odt schemas that have no place here).
@@ -205,13 +209,16 @@ Dependency direction is strictly downward and checkable: `math-types`/`formula`/
 - **`interpret.ts` 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 an item built from them. 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 a caller reconstructing structure from a `LayoutDocument` (a spreadsheet grid, a vector drawing) builds on.
 - **A recovered path that matches one of three characteristic shape patterns comes back as that shape's own kind, not as a generic `LayoutPath`.** PDF has exactly one shape operator, `re`, and no ellipse or line operator at all, so a writer has no way to record what a path *was* — `interpret.ts` recovers it from the geometry instead. A single closed four-corner subpath whose every edge runs along one axis is a `LayoutRect` (so `re` under a non-rotated *or* 90°-rotated CTM, a hand-built `m`/`l`/`l`/`l`/`h` rectangle, and any combination of fill and stroke all reach it — not just the fill-only single-`re` case an earlier fast path covered); a closed subpath of exactly four cubic segments meeting at its bounding box's four cardinal points, with all eight control points at the standard kappa offset (`BEZIER_KAPPA`, 4/3·(√2−1)) those extremes imply, is a `LayoutEllipse` — precisely what `writeEllipse` emits; an open single-straight-segment stroke-only subpath is a `LayoutLine`. Tolerance is `max(1e-3pt, 1e-4 × the shape's own extent)`: the absolute floor is twenty times the 5e-5pt quantisation `formatNumber`'s 4-decimal-place rounding imposes, and the relative term is what lets a large ellipse from a producer that rounded its kappa constant more coarsely (`0.5523`) still match. **These are deliberate, bounded heuristics, not certainties** — a hand-authored freeform path that happens to consist of four kappa-ratio cubics between its bounding box's cardinal points is indistinguishable from a "real" ellipse in the PDF bytes, because at that point it geometrically *is* one, whatever the author called it. What a false positive can never do is misreport geometry: every detected shape reproduces its source path's own points exactly, so it changes an item's kind, never where or how big it is. Anything the patterns don't cover — a non-90° rotation, a curve that isn't the four-quadrant construction, a polygon that isn't a rectangle, multiple subpaths — stays a `LayoutPath`, and a rotated ellipse deliberately does too, since `LayoutEllipse` carries no rotation to report one with.
 - **`writePdf`/`readPdf` round-trip a page's own `notes` field via a hidden annotation, not any real PDF feature.** PDF has no native concept of hidden presenter notes, so a page's `LayoutPage.notes` (when present) is written as a `/Subtype /Text` annotation (the same construct Acrobat's own sticky-note tool uses) with the `Hidden` annotation flag set so it never renders or prints, and `readPdf` reads it back via an internal author marker that distinguishes this package's own notes annotation from a genuine third-party sticky note. This is a round-trip mechanism specific to this package's own writer/reader pair — a PDF produced by anything else will never carry it, and a PDF consumer other than this package's own `readPdf` will never see it as anything but an invisible, empty sticky note. `documents.js` uses this to carry pptx/odp speaker notes through `pptxToPdf`/`pdfToPptx` and `odpToPdf`/`pdfToOdp`.
-- **STIX Two Math (the embedded formula font) is a CFF-flavoured OpenType font (an `OTTO` sfnt wrapping a `CFF ` table), not TrueType/glyf** — confirmed by inspecting the vendored font's own sfnt table directory while `math-font.ts` was built. Genuine Type2-charstring glyph subsetting (re-encoding charstrings, rebuilding the CFF `INDEX` structures with a renumbered, minimal glyph set) is a substantially larger undertaking than TrueType glyf/loca subsetting, and is out of scope: the **entire** `CFF ` table is embedded verbatim, unmodified, as a single `/FontFile3` `/Subtype /CIDFontType0C` stream — a real, correct, working embedded font, just not glyph-subsetted. Everything else genuinely IS built from a targeted parse of only what's used: `cmap` resolves exactly the Unicode code points a document's formulas actually reference to glyph IDs, and the emitted `/W` widths array and ToUnicode CMap only ever cover those same glyph IDs, not the font's full ~5,500-glyph repertoire. A CID-keyed composite font built this way needs no `/CIDToGIDMap` at all (that key exists only for `/CIDFontType2`): per ISO 32000-1 9.7.4.2, a `/CIDFontType0` whose `/FontFile3` is a "bare" (non-CID-keyed) CFF program is read with CID treated as directly indexing the CFF's own `CharStrings` INDEX by glyph order — i.e. CID == GID, exactly the numbering `cmap`-derived glyph IDs already use, so Identity-H text-showing needs no further remapping anywhere in the write path.
-- **The OpenType `MATH` table's `MathVariants` subtable is now parsed and its stretchy-glyph assembly implemented (`math-table.ts`/`math-stretch.ts`), but nothing in this package can yet DRAW the result.** Variant selection and part assembly are real, tested computation — `loadMathFont().stretchGlyph(...)` gives back the glyph IDs and offsets for a parenthesis, brace, radical sign, or over-brace at any target size, with every seam overlapped inside the parts' own declared connector lengths. What is missing is the last hop: `MathBox`'s `MathGlyphRun` carries a Unicode *string* that the writer resolves through `cmap`, and most of the glyphs a `MathVariants` construction names have no Unicode code point to put in it — every pre-built larger variant is unencoded, as are the radical's and the over-brace's assembly pieces, with the bracket family the one exception (Unicode's own U+239B–U+23AD piece block covers it). Drawing one needs a glyph-ID-carrying `MathLayoutItem` kind, in `documents.js`'s own `src/mathml/layout-types.ts` and this package's `src/math-types.ts` mirror alike, plus handling in `math-content-write.ts`/`collectUsedGlyphs` (the latter also keys the emitted `/W` array and ToUnicode CMap off code points today). Until that lands, a rendered stretchy fence still comes out at its base glyph's own fixed size. `MathConstants` (every fraction/radical/script-positioning constant `MathFontMetrics` exposes) and `MathGlyphInfo` (italics correction, top-accent attachment) are genuinely parsed in full too.
-- **Real per-glyph ink bounds are now measured from the outline, but `ascentPerEm`/`descentPerEm` still exist alongside them and a caller has to choose.** `MathGlyphMetrics.inkAscentPt`/`inkDescentPt` (and `MathFont.glyphInkBounds`, the same thing in design units) carry each glyph's own tight ink extent, computed by walking its Type 2 charstring — a full stop measures 0.12 em tall against the 1.0 em the font's nominal `hhea` metrics claim for every glyph alike. `ascentPerEm`/`descentPerEm` remain what they always were: one uniform figure for the whole face, still the right measure for anything sized against the font rather than against particular characters, and still the fallback for a glyph with no outline to measure (a space) or one `cff-bounds.ts` declines to walk, where both ink fields come back `undefined` together. **The consumer that motivated this — `documents.js`'s own MathML `layoutToken` — has not been switched over yet**, so a formula rendered today still gets a uniform token box; wiring it is a one-site change in that package (take the max ink ascent and max ink descent across the run's glyphs, falling back to the nominal metrics per glyph).
+- **STIX Two Math (the embedded formula font) is a CFF-flavoured OpenType font (an `OTTO` sfnt wrapping a `CFF ` table), not TrueType/glyf** — confirmed by inspecting the vendored font's own sfnt table directory while `math-font.ts` was built. Genuine Type2-charstring glyph subsetting (re-encoding charstrings, rebuilding the CFF `INDEX` structures with a renumbered, minimal glyph set) is a substantially larger undertaking than TrueType glyf/loca subsetting, and is out of scope: the **entire** `CFF ` table is embedded verbatim, unmodified, as a single `/FontFile3` `/Subtype /CIDFontType0C` stream — a real, correct, working embedded font, just not glyph-subsetted. Everything else genuinely IS built from a targeted parse of only what's used: `cmap` resolves exactly the Unicode code points a document's formulas actually reference to glyph IDs, and the emitted `/W` widths array covers only the glyph IDs actually drawn (those, plus any unencoded pieces a stretchy construction contributed), not the font's full ~5,500-glyph repertoire; the ToUnicode CMap covers the subset of those that have a code point at all. A CID-keyed composite font built this way needs no `/CIDToGIDMap` at all (that key exists only for `/CIDFontType2`): per ISO 32000-1 9.7.4.2, a `/CIDFontType0` whose `/FontFile3` is a "bare" (non-CID-keyed) CFF program is read with CID treated as directly indexing the CFF's own `CharStrings` INDEX by glyph order — i.e. CID == GID, exactly the numbering `cmap`-derived glyph IDs already use, so Identity-H text-showing needs no further remapping anywhere in the write path.
+- **The OpenType `MATH` table's `MathVariants` subtable is parsed, its stretchy-glyph assembly implemented (`math-table.ts`/`math-stretch.ts`), and the result genuinely drawable (`math-types.ts`'s `MathAssembledGlyphs`, `math-content-write.ts`).** Variant selection and part assembly are real, tested computation — `loadMathFont().stretchGlyph(...)` gives back the glyph IDs and offsets for a parenthesis, brace, radical sign, or over-brace at any target size, with every seam overlapped inside the parts' own declared connector lengths — and `MathFontMetrics.stretch` wraps that with the real ink measurement a layout engine needs to place it. Drawing goes by **glyph ID**, because most of the glyphs a construction names have no Unicode code point at all: every pre-built larger variant is unencoded, as are the radical's and the over-brace's assembly pieces, with the bracket family the one exception (Unicode's own U+239B–U+23AD piece block covers it). That works because CID == GID here, so a glyph ID is shown directly with no `cmap` involvement. Two real consequences follow, both handled rather than left silent: `collectUsedGlyphs` now maps a glyph ID to `number | undefined`, so an unencoded glyph still gets its `/W` width but contributes no ToUnicode entry, and the construction is wrapped in an `/ActualText` marked-content span carrying the operator's own text so it still extracts as `(` rather than as nothing. `MathConstants` (every fraction/radical/script-positioning constant `MathFontMetrics` exposes) and `MathGlyphInfo` (italics correction, top-accent attachment) are genuinely parsed in full too.
+- **What this package draws for a stretchy glyph is decided entirely by its caller.** This package resolves and draws whatever construction it is asked for, on either axis; which operators a document actually stretches, and to what, is a layout-engine decision — `documents.js`'s own `src/mathml/layout.ts` currently stretches vertical fences in an `mrow` and nothing else. See that package's own README for which constructions genuinely stretch today and which still render at a fixed size.
+- **Real per-glyph ink bounds are now measured from the outline, but `ascentPerEm`/`descentPerEm` still exist alongside them and a caller has to choose.** `MathGlyphMetrics.inkAscentPt`/`inkDescentPt` (and `MathFont.glyphInkBounds`, the same thing in design units) carry each glyph's own tight ink extent, computed by walking its Type 2 charstring — a full stop measures 0.12 em tall against the 1.0 em the font's nominal `hhea` metrics claim for every glyph alike. `ascentPerEm`/`descentPerEm` remain what they always were: one uniform figure for the whole face, still the right measure for anything sized against the font rather than against particular characters, and still the fallback for a glyph with no outline to measure (a space) or one `cff-bounds.ts` declines to walk, where both ink fields come back `undefined` together. The consumer that motivated this — `documents.js`'s own MathML `layoutToken` — now uses them: it takes the max ink ascent and max ink descent across a run's glyphs, falling back to the nominal metrics per glyph that carries no bounds.
 - **An ink box is genuinely tight, which for a math font means it is often *larger* than the nominal metrics, not smaller.** The "ink is a fraction of the nominal extent" intuition holds for text-like glyphs (a full stop, a parenthesis, an `x`) and fails for the extension pieces, display-size operators, and pre-built large variants a math font is full of: over a tenth of STIX Two Math's repertoire draws above its own nominal ascent, and another tenth below its nominal descent, reaching 2.6 em up and 1.6 em down at the extremes. Sizing those from `ascentPerEm` under-reports them exactly as badly as it over-reports a full stop, which is the whole reason the per-glyph measurement exists.
 - **A glyph's ink descent is negative where its lowest ink sits above the baseline.** `inkDescentPt` follows `descentPerEm`'s own sign convention (ink below the baseline is a positive descent), so a superscript-height glyph honestly reports a negative descent rather than a clamped zero. A consumer that needs a box which never crosses the baseline clamps at its own layer, where it can see what the box is for.
 - **An embedded `CIDFontType2` program needs no `cmap` table of its own, and `sfnt-subset.ts`'s output doesn't carry one — this is a property of the spec, not an oversight this package works around.** `cmap` maps a character code to a glyph ID for a *simple* font; a `Type0` composite font never asks the embedded font program to do that lookup at all. Character code → CID goes through the `Type0` font's own `/Encoding` (Identity-H here, so CID == character code by construction for the 2-byte codes this package writes), and CID → GID goes through `/CIDToGIDMap` (`/Identity` here, matching `sfnt-subset.ts`'s own GID-preserving design). Both steps happen inside the PDF's own object graph, entirely before the embedded font program is ever consulted — ISO 32000-1 9.7.4.2. This is exactly why the subset output can safely omit `cmap` alongside `name`/`OS/2`/`GSUB`/`GPOS`/`kern` (see Architecture above): none of the five is on the code-path a `CIDFontType2` reader actually walks.
-- **No GPOS/GSUB/kern support: an embedded face's own kerning pairs, ligature substitutions, and other OpenType layout features are never read, subsetted, or applied.** `sfnt-subset.ts` strips `GSUB`/`GPOS`/`kern` from its output entirely, and nothing upstream of that — `measure.ts`'s line-wrapping, `content-write.ts`'s glyph placement — ever consults them either, subset or not. Every embedded run is placed glyph-by-glyph at that glyph's own bare `hmtx` advance width, with no per-pair kerning adjustment. See the acceptance-bar paragraph under [Fidelity](#fidelity) for what this bounds and doesn't bound.
+- **`GPOS` pair kerning is read and applied for an embedded face; no other OpenType layout feature is.** An embedded run's glyphs are placed at their own `hmtx` advances adjusted by the font's own pair kerning, written into the page as a real `TJ` array (see the gotcha below). `GSUB` is a different matter and is genuinely not supported: ligature substitution, contextual alternates, and small caps are never applied, so a face's `fi` ligature is drawn as two separate glyphs. The legacy `kern` table is not read either, and nothing is lost by that for the vendored families — neither Carlito nor Caladea ships one in any face; both carry all of their real pair kerning in `GPOS`.
+- **A kerned run is shown with `TJ`, and the sign of a `TJ` number is the opposite of the adjustment it expresses.** ISO 32000-1 9.4.3 defines a number in a `TJ` array as being SUBTRACTED from the current horizontal coordinate, in thousandths of a unit of text space — so a positive number moves the next glyph closer, and a pair the font tightens by 43.457 glyph-space units is written as `+43.457`, not `-43.457`. `content-write.ts` negates the advance delta at exactly that one point, and `interpret.ts`'s own `TJ` handling is the reader half of the same convention, so a page written here and read back through this package's own parser recovers the positions it was written with (`write-embedded-font.test.ts` asserts that round trip specifically, since it is what settles the direction empirically rather than by argument from the specification alone). A run whose adjacent pairs the face kerns nothing about is still shown as one unsplit hex string with `Tj`, byte for byte what this package emitted before kerning existed — only a genuinely kerned run pays for an array.
+- **Kerning applies to whole shown strings, so a wrap decision does not see a pair straddling the boundary between two separately-measured words.** `text-layout.ts` decides where a line breaks by summing separately-measured word and whitespace atoms, and a pair spanning one of those boundaries (Caladea kerns a comma or a full stop against a following space by -30 design units; Carlito kerns nothing against a space at all) is therefore not counted at that one decision point. Everything downstream of the decision is exact: a fragment's reported width and the glyphs actually drawn for it both come from measuring that whole fragment in one call, so the width a line reports is the width the page draws. Making the wrap decision itself exact would mean widening the `TextMeasurer` port with a cross-string pair-adjustment method — a public API change for a sub-point difference that, for both vendored families, only ever errs towards breaking a line early rather than overrunning a column.
 - **`font-substitutes.ts` maps both `Calibri` and `Calibri Light` onto the same, ordinary-weight Carlito face.** Carlito ships only one weight per style axis (regular/bold/italic/bolditalic) — there is no distinct Light design to embed — so `Calibri Light` substitutes to standard Carlito rather than a genuinely lighter face. An honest, documented approximation (see that file's own top-of-file comment), not a faithful weight match: a caller relying on Calibri Light's visibly thinner strokes will not see them, only its width metrics.
 - **`cff-probe.ts`'s CID-keyed CFF guard exists for a source-embedded-font phase this package hasn't built yet — it is not wired into any write path today, and today's embedding never needs it.** Every face this package currently embeds — the vendored Carlito/Caladea substitutes, and any caller-supplied face via `sourceFonts`/`fonts` — is `glyf`-flavoured TrueType, and `sfnt-subset.ts` already refuses (returns `undefined` for) anything that isn't before `cff-probe.ts` would ever run against it. The guard is what a future phase embedding a real, subsetted CFF program (rather than the whole-table CFF embed `math-font-write.ts` already does for STIX Two Math) will need before it can trust CID == GID against an arbitrary caller-supplied font: a CID-keyed CFF carries its own CID → glyph-index charset, so that identity does not hold for one, and nothing about the file signals the mismatch to a reader — it just renders the wrong glyphs.
 
@@ -247,9 +254,9 @@ Dependency direction is strictly downward and checkable: `math-types`/`formula`/
 
 **Supply a `FontRegistry` (`createFontRegistry()`) and Calibri and Cambria stop being an approximation at all.** The vendored Carlito and Caladea faces are the real, metric-compatible TrueType families those two names substitute for, resolved automatically with no caller configuration needed. Aptos still has no vendored substitute — it falls back to the same width-corrected standard-14 approximation as any other unlisted family, registry or not. The mechanism: a resolved face is measured at its own real `hmtx` advances (never the width-correction table, which is not consulted at all on that path — applying both would silently draw text narrower than it was measured and overrun its column), underlined at its own `post` geometry, subsetted to the glyphs the document actually uses, and embedded as a real `/Type0` + `/CIDFontType2` + `/FontFile2` group. A caller's own `fonts`/`sourceFonts` extend the same resolution to any TrueType-outline face. The honest remaining limits: only TrueType (`glyf`) outlines can be embedded, since `sfnt-subset.ts` rebuilds outline tables rather than re-encoding CFF charstrings (a resolved face with no `glyf` throws rather than silently falling back to a different font than the caller asked for); a character the face has no glyph for is drawn as `.notdef` and reported through `onMissingGlyph` rather than substituted; and which of a font's three competing vertical-metric sets drives line height is a caller-chosen policy, not a settled fact (see `VerticalMetricPolicy` above).
 
-**The acceptance bar for embedded-font fidelity is deliberately "no page-count drift on a real corpus", not "line-identical".** Every glyph in an embedded run is placed at its own bare `hmtx` advance width and nothing else — there is no pair-kerning adjustment anywhere in this package's measurement or content-stream writing path (see [Gotchas](#gotchas-and-quirks)). Reaching genuine line-identical parity with the original authoring application would additionally need a GPOS pair-kerning reader on top of the outline subsetter this package already has, a materially larger, separate undertaking this phase deliberately did not attempt. What the current bar does guarantee: a real document measured and drawn through the same resolved face's own advances will not silently reflow onto a different number of pages the way a width-corrected standard-14 substitute occasionally can.
+**The acceptance bar for embedded-font fidelity is deliberately "no page-count drift on a real corpus", not "line-identical".** An embedded run is placed at the face's own `hmtx` advances adjusted by the face's own `GPOS` pair kerning — measured and drawn from one shared computation, so the two cannot disagree — which is a genuine step towards what the original authoring application would produce rather than an approximation of it. What still separates this from line-identical output is everything else an OpenType shaping engine does: `GSUB` ligatures and contextual alternates are never applied, and kerning is applied within each shown string rather than across the whitespace boundaries a wrap decision measures separately (see [Gotchas](#gotchas-and-quirks) for both). What the bar does guarantee: a real document measured and drawn through the same resolved face's own advances will not silently reflow onto a different number of pages the way a width-corrected standard-14 substitute occasionally can.
 
-**The one exception is math-formula rendering (`WritePdfOptions.formulas`): this genuinely embeds a real, hand-parsed font.** Real box-model glyph runs are shown through the embedded STIX Two Math font with genuine per-glyph metrics (advance width, italic correction, top-accent attachment) and font-wide layout constants (axis height, fraction/radical rule thickness and gaps, script shift amounts) parsed directly from that font's own `MATH` table — not approximated or hand-tuned. See [Gotchas](#gotchas-and-quirks) for the exact boundary of what this package's own font parsing does and doesn't cover (the CFF-full-embed simplification, the parsed-but-not-yet-drawable `MathVariants` stretchy constructions, and the nominal-rather-than-ink vertical metrics).
+**The one exception is math-formula rendering (`WritePdfOptions.formulas`): this genuinely embeds a real, hand-parsed font.** Real box-model glyph runs are shown through the embedded STIX Two Math font with genuine per-glyph metrics (advance width, italic correction, top-accent attachment) and font-wide layout constants (axis height, fraction/radical rule thickness and gaps, script shift amounts) parsed directly from that font's own `MATH` table — not approximated or hand-tuned. Stretchy constructions are real too: a `MathVariants` variant or part assembly is resolved, measured against actual glyph outlines, and drawn by glyph ID. See [Gotchas](#gotchas-and-quirks) for the exact boundary of what this package's own font parsing does and doesn't cover (the CFF-full-embed simplification, and what a stretched construction costs in ToUnicode terms).
 
 **`readPdf(writePdf(doc))` is not guaranteed to reproduce `doc` exactly, and `writePdf(readPdf(bytes))` is not guaranteed to reproduce `bytes` exactly — this package makes no round-trip-losslessness claim in either direction.** A PDF page is fundamentally a stream of positioned drawing operators, not a structured document: a rectangle, an ellipse, and a line are recovered as their own kinds only because each is *always* written as one characteristic operator pattern this package recognises (see the shape-detection gotcha above) — a shape drawn any other way, or rotated off-axis, still collapses to a generic `LayoutPath`, and text is recovered as positioned glyph runs with no guarantee the original run boundaries (which characters were grouped into one `Tj` versus several) survive identically. This is a deliberate, permanent contrast with format-preserving codecs like `ooxml.js`'s own `packageCodec`. `pdfCodec` shares `z.codec()`'s *mechanism* (schema-validated both ways) but not that *guarantee* — wrapping this round trip in `z.codec()` validates the shape of what comes out, not its fidelity to what went in.
 

package/dist/content-write.cjs

@@ -33,27 +33,48 @@ function writeUnderline(writer, item, widthPt, underline) {
 	writer.writeAscii("f\n");
 	writer.writeAscii("Q\n");
 }
-function writeShowTextBlock(writer, item, resourceName, scalePercent, codes) {
+function writeShowTextBlock(writer, item, resourceName, scalePercent, show) {
 	writer.writeAscii("BT\n");
 	writer.writeAscii(`/${resourceName} ${require_serialize.formatNumber(item.sizePt)} Tf\n`);
 	writer.writeAscii(`${require_serialize.formatNumber(scalePercent)} Tz\n`);
 	writeRgbOperator(writer, item.color, "rg");
 	writeMatrixOperator(writer, anchorMatrix(item.xPt, item.yPt, item.rotationDeg), "Tm");
-	require_serialize.writeObject(writer, require_objects.pdfHexString(codes));
-	writer.writeAscii(" Tj\n");
+	require_serialize.writeObject(writer, show.operand);
+	writer.writeAscii(` ${show.operator}\n`);
 	writer.writeAscii("ET\n");
 }
 function writeStandardText(writer, item, standardName, resourceName, measurer, substitutions) {
 	const encoded = require_afm_widths.encodeForShow(item.text, standardName);
 	substitutions.push(...encoded.substitutions);
 	const scale = measurer.horizontalScaleFor(item.font);
-	writeShowTextBlock(writer, item, resourceName, scale * 100, encoded.codes);
+	writeShowTextBlock(writer, item, resourceName, scale * 100, {
+		operand: require_objects.pdfHexString(encoded.codes),
+		operator: "Tj"
+	});
 	if (item.underline === true) writeUnderline(writer, item, item.widthPt ?? encoded.width1000 / GLYPH_SPACE_UNITS_PER_EM * item.sizePt * scale, measurer.underlineAtSize(item.font, item.sizePt));
 }
+function embeddedShowOperand(encoded) {
+	if (encoded.kerns.length === 0) return {
+		operand: require_objects.pdfHexString(encoded.codes),
+		operator: "Tj"
+	};
+	const items = [];
+	let runStart = 0;
+	for (const kern of encoded.kerns) {
+		items.push(require_objects.pdfHexString(encoded.codes.subarray(runStart, kern.codeOffset)));
+		items.push(require_objects.pdfNum(-kern.adjustment1000));
+		runStart = kern.codeOffset;
+	}
+	items.push(require_objects.pdfHexString(encoded.codes.subarray(runStart)));
+	return {
+		operand: require_objects.pdfArray(items),
+		operator: "TJ"
+	};
+}
 function writeEmbeddedText(writer, item, face, resourceName, missingGlyphs) {
 	const encoded = require_embedded_font.encodeForShowEmbedded(item.text, face);
 	missingGlyphs.push(...encoded.substitutions);
-	writeShowTextBlock(writer, item, resourceName, EMBEDDED_HORIZONTAL_SCALE_PERCENT, encoded.codes);
+	writeShowTextBlock(writer, item, resourceName, EMBEDDED_HORIZONTAL_SCALE_PERCENT, embeddedShowOperand(encoded));
 	if (item.underline === true) writeUnderline(writer, item, item.widthPt ?? encoded.width1000 / GLYPH_SPACE_UNITS_PER_EM * item.sizePt, {
 		offsetPt: face.metrics.underlinePositionGlyphSpace / GLYPH_SPACE_UNITS_PER_EM * item.sizePt,
 		thicknessPt: face.metrics.underlineThicknessGlyphSpace / GLYPH_SPACE_UNITS_PER_EM * item.sizePt

package/dist/content-write.d.cts

@@ -1,5 +1,5 @@
 import { r as StandardFontName } from "./afm-widths-DyDq56Ph.cjs";
-import { r as EmbeddedFaceSubstitution, t as EmbeddedFace } from "./embedded-font-CLedn-mT.cjs";
+import { r as EmbeddedFaceSubstitution, t as EmbeddedFace } from "./embedded-font-BU6Jgcof.cjs";
 import { TextMeasurer } from "./measure.cjs";
 import { WinAnsiSubstitution } from "./winansi.cjs";
 import { LayoutFont, LayoutItem } from "document-schema.js";

package/dist/content-write.d.ts

@@ -1,5 +1,5 @@
 import { r as StandardFontName } from "./afm-widths-DyDq56Ph.js";
-import { r as EmbeddedFaceSubstitution, t as EmbeddedFace } from "./embedded-font-CbqkKgBl.js";
+import { r as EmbeddedFaceSubstitution, t as EmbeddedFace } from "./embedded-font-fREdbxnr.js";
 import { TextMeasurer } from "./measure.js";
 import { WinAnsiSubstitution } from "./winansi.js";
 import { LayoutFont, LayoutItem } from "document-schema.js";

package/dist/content-write.js

@@ -1,6 +1,6 @@
 import { o as encodeForShow } from "./afm-widths-Dxucrg7D.js";
 import { ByteWriter } from "./bytes/writer.js";
-import { pdfHexString } from "./objects.js";
+import { pdfArray, pdfHexString, pdfNum } from "./objects.js";
 import { BEZIER_KAPPA, multiplyMatrices, rotationMatrix, scaleMatrix, translationMatrix } from "./matrix.js";
 import { encodeForShowEmbedded } from "./embedded-font.js";
 import { formatNumber, writeObject } from "./serialize.js";
@@ -32,27 +32,48 @@ function writeUnderline(writer, item, widthPt, underline) {
 	writer.writeAscii("f\n");
 	writer.writeAscii("Q\n");
 }
-function writeShowTextBlock(writer, item, resourceName, scalePercent, codes) {
+function writeShowTextBlock(writer, item, resourceName, scalePercent, show) {
 	writer.writeAscii("BT\n");
 	writer.writeAscii(`/${resourceName} ${formatNumber(item.sizePt)} Tf\n`);
 	writer.writeAscii(`${formatNumber(scalePercent)} Tz\n`);
 	writeRgbOperator(writer, item.color, "rg");
 	writeMatrixOperator(writer, anchorMatrix(item.xPt, item.yPt, item.rotationDeg), "Tm");
-	writeObject(writer, pdfHexString(codes));
-	writer.writeAscii(" Tj\n");
+	writeObject(writer, show.operand);
+	writer.writeAscii(` ${show.operator}\n`);
 	writer.writeAscii("ET\n");
 }
 function writeStandardText(writer, item, standardName, resourceName, measurer, substitutions) {
 	const encoded = encodeForShow(item.text, standardName);
 	substitutions.push(...encoded.substitutions);
 	const scale = measurer.horizontalScaleFor(item.font);
-	writeShowTextBlock(writer, item, resourceName, scale * 100, encoded.codes);
+	writeShowTextBlock(writer, item, resourceName, scale * 100, {
+		operand: pdfHexString(encoded.codes),
+		operator: "Tj"
+	});
 	if (item.underline === true) writeUnderline(writer, item, item.widthPt ?? encoded.width1000 / GLYPH_SPACE_UNITS_PER_EM * item.sizePt * scale, measurer.underlineAtSize(item.font, item.sizePt));
 }
+function embeddedShowOperand(encoded) {
+	if (encoded.kerns.length === 0) return {
+		operand: pdfHexString(encoded.codes),
+		operator: "Tj"
+	};
+	const items = [];
+	let runStart = 0;
+	for (const kern of encoded.kerns) {
+		items.push(pdfHexString(encoded.codes.subarray(runStart, kern.codeOffset)));
+		items.push(pdfNum(-kern.adjustment1000));
+		runStart = kern.codeOffset;
+	}
+	items.push(pdfHexString(encoded.codes.subarray(runStart)));
+	return {
+		operand: pdfArray(items),
+		operator: "TJ"
+	};
+}
 function writeEmbeddedText(writer, item, face, resourceName, missingGlyphs) {
 	const encoded = encodeForShowEmbedded(item.text, face);
 	missingGlyphs.push(...encoded.substitutions);
-	writeShowTextBlock(writer, item, resourceName, EMBEDDED_HORIZONTAL_SCALE_PERCENT, encoded.codes);
+	writeShowTextBlock(writer, item, resourceName, EMBEDDED_HORIZONTAL_SCALE_PERCENT, embeddedShowOperand(encoded));
 	if (item.underline === true) writeUnderline(writer, item, item.widthPt ?? encoded.width1000 / GLYPH_SPACE_UNITS_PER_EM * item.sizePt, {
 		offsetPt: face.metrics.underlinePositionGlyphSpace / GLYPH_SPACE_UNITS_PER_EM * item.sizePt,
 		thicknessPt: face.metrics.underlineThicknessGlyphSpace / GLYPH_SPACE_UNITS_PER_EM * item.sizePt

package/dist/{embedded-font-CLedn-mT.d.cts → embedded-font-BU6Jgcof.d.cts}

@@ -26,17 +26,23 @@ interface EmbeddedFace {
   readonly metrics: EmbeddedFaceMetrics;
   glyphId(codePoint: number): number | undefined;
   glyphSpaceWidth(glyphId: number): number;
+  kernGlyphSpace(leftGlyphId: number, rightGlyphId: number): number;
 }
 declare function loadEmbeddedFace(font: SfntFont): EmbeddedFace | undefined;
 interface EmbeddedFaceSubstitution {
   readonly from: string;
 }
+interface EmbeddedKern {
+  readonly codeOffset: number;
+  readonly adjustment1000: number;
+}
 interface EmbeddedShow {
   readonly codes: Uint8Array<ArrayBuffer>;
   readonly width1000: number;
   readonly substitutions: readonly EmbeddedFaceSubstitution[];
+  readonly kerns: readonly EmbeddedKern[];
 }
 declare function encodeForShowEmbedded(text: string, face: EmbeddedFace): EmbeddedShow;
 declare function collectEmbeddedGlyphs(texts: Iterable<string>, face: EmbeddedFace): ReadonlyMap<number, number>;
 //#endregion
-export { NOTDEF_GLYPH_ID as a, loadEmbeddedFace as c, EmbeddedShow as i, EmbeddedFaceMetrics as n, collectEmbeddedGlyphs as o, EmbeddedFaceSubstitution as r, encodeForShowEmbedded as s, EmbeddedFace as t };
+export { EmbeddedShow as a, encodeForShowEmbedded as c, EmbeddedKern as i, loadEmbeddedFace as l, EmbeddedFaceMetrics as n, NOTDEF_GLYPH_ID as o, EmbeddedFaceSubstitution as r, collectEmbeddedGlyphs as s, EmbeddedFace as t };

package/dist/{embedded-font-CbqkKgBl.d.ts → embedded-font-fREdbxnr.d.ts}

@@ -26,17 +26,23 @@ interface EmbeddedFace {
   readonly metrics: EmbeddedFaceMetrics;
   glyphId(codePoint: number): number | undefined;
   glyphSpaceWidth(glyphId: number): number;
+  kernGlyphSpace(leftGlyphId: number, rightGlyphId: number): number;
 }
 declare function loadEmbeddedFace(font: SfntFont): EmbeddedFace | undefined;
 interface EmbeddedFaceSubstitution {
   readonly from: string;
 }
+interface EmbeddedKern {
+  readonly codeOffset: number;
+  readonly adjustment1000: number;
+}
 interface EmbeddedShow {
   readonly codes: Uint8Array<ArrayBuffer>;
   readonly width1000: number;
   readonly substitutions: readonly EmbeddedFaceSubstitution[];
+  readonly kerns: readonly EmbeddedKern[];
 }
 declare function encodeForShowEmbedded(text: string, face: EmbeddedFace): EmbeddedShow;
 declare function collectEmbeddedGlyphs(texts: Iterable<string>, face: EmbeddedFace): ReadonlyMap<number, number>;
 //#endregion
-export { NOTDEF_GLYPH_ID as a, loadEmbeddedFace as c, EmbeddedShow as i, EmbeddedFaceMetrics as n, collectEmbeddedGlyphs as o, EmbeddedFaceSubstitution as r, encodeForShowEmbedded as s, EmbeddedFace as t };
+export { EmbeddedShow as a, encodeForShowEmbedded as c, EmbeddedKern as i, loadEmbeddedFace as l, EmbeddedFaceMetrics as n, NOTDEF_GLYPH_ID as o, EmbeddedFaceSubstitution as r, collectEmbeddedGlyphs as s, EmbeddedFace as t };

package/dist/embedded-font-write.d.cts

@@ -1,5 +1,5 @@
 import { PdfDict, PdfObject } from "./objects.cjs";
-import { t as EmbeddedFace } from "./embedded-font-CLedn-mT.cjs";
+import { t as EmbeddedFace } from "./embedded-font-BU6Jgcof.cjs";
 import { SfntSubsetResult } from "./sfnt-subset.cjs";
 //#region src/embedded-font-write.d.ts
 declare function embeddedSubsetTag(postScriptName: string, glyphIds: readonly number[]): string;

package/dist/embedded-font-write.d.ts

@@ -1,5 +1,5 @@
 import { PdfDict, PdfObject } from "./objects.js";
-import { t as EmbeddedFace } from "./embedded-font-CbqkKgBl.js";
+import { t as EmbeddedFace } from "./embedded-font-fREdbxnr.js";
 import { SfntSubsetResult } from "./sfnt-subset.js";
 //#region src/embedded-font-write.d.ts
 declare function embeddedSubsetTag(postScriptName: string, glyphIds: readonly number[]): string;

package/dist/embedded-font.cjs

@@ -3,6 +3,7 @@ const require_sfnt = require("./sfnt.cjs");
 const require_cmap_table = require("./cmap-table.cjs");
 const require_font_tables = require("./font-tables.cjs");
 const require_glyf = require("./glyf.cjs");
+const require_gpos_table = require("./gpos-table.cjs");
 const require_hmtx_table = require("./hmtx-table.cjs");
 //#region src/embedded-font.ts
 const GLYPH_SPACE_UNITS_PER_EM = 1e3;
@@ -55,6 +56,7 @@ function readEmbeddedFace(font) {
 	const { unitsPerEm } = head;
 	const scale = (designUnits) => scaleToGlyphSpace(designUnits, unitsPerEm);
 	const capHeight = resolveCapHeight(font, cmap, os2?.sCapHeight, hhea.ascent);
+	const kern = require_gpos_table.buildGposKernLookup(font);
 	return {
 		font,
 		postScriptName: name.postScriptName,
@@ -83,7 +85,8 @@ function readEmbeddedFace(font) {
 			serif: isSerifByPanose(os2?.panose)
 		},
 		glyphId: (codePoint) => cmap(codePoint),
-		glyphSpaceWidth: (glyphId) => scale(hmtx.advanceWidth(glyphId))
+		glyphSpaceWidth: (glyphId) => scale(hmtx.advanceWidth(glyphId)),
+		kernGlyphSpace: kern === void 0 ? () => 0 : (leftGlyphId, rightGlyphId) => scale(kern(leftGlyphId, rightGlyphId) ?? 0)
 	};
 }
 const HHEA_TABLE_SIZE = 36;
@@ -104,26 +107,40 @@ function parseHhea(font) {
 		numberOfHMetrics
 	};
 }
+const CID_BYTE_LENGTH = 2;
 function encodeForShowEmbedded(text, face) {
 	const glyphIds = [];
 	const substitutions = [];
+	const kerns = [];
 	let width1000 = 0;
 	for (const character of text) {
 		const glyphId = face.glyphId(character.codePointAt(0));
 		if (glyphId === void 0) substitutions.push({ from: character });
 		const shown = glyphId ?? 0;
+		const previous = glyphIds[glyphIds.length - 1];
+		if (previous !== void 0) {
+			const adjustment1000 = face.kernGlyphSpace(previous, shown);
+			if (adjustment1000 !== 0) {
+				kerns.push({
+					codeOffset: glyphIds.length * CID_BYTE_LENGTH,
+					adjustment1000
+				});
+				width1000 += adjustment1000;
+			}
+		}
 		glyphIds.push(shown);
 		width1000 += face.glyphSpaceWidth(shown);
 	}
-	const codes = new Uint8Array(glyphIds.length * 2);
+	const codes = new Uint8Array(glyphIds.length * CID_BYTE_LENGTH);
 	glyphIds.forEach((glyphId, index) => {
-		codes[index * 2] = glyphId >> 8 & 255;
-		codes[index * 2 + 1] = glyphId & 255;
+		codes[index * CID_BYTE_LENGTH] = glyphId >> 8 & 255;
+		codes[index * CID_BYTE_LENGTH + 1] = glyphId & 255;
 	});
 	return {
 		codes,
 		width1000,
-		substitutions
+		substitutions,
+		kerns
 	};
 }
 function collectEmbeddedGlyphs(texts, face) {

package/dist/embedded-font.d.cts

@@ -1,2 +1,2 @@
-import { a as NOTDEF_GLYPH_ID, c as loadEmbeddedFace, i as EmbeddedShow, n as EmbeddedFaceMetrics, o as collectEmbeddedGlyphs, r as EmbeddedFaceSubstitution, s as encodeForShowEmbedded, t as EmbeddedFace } from "./embedded-font-CLedn-mT.cjs";
-export { EmbeddedFace, EmbeddedFaceMetrics, EmbeddedFaceSubstitution, EmbeddedShow, NOTDEF_GLYPH_ID, collectEmbeddedGlyphs, encodeForShowEmbedded, loadEmbeddedFace };
+import { a as EmbeddedShow, c as encodeForShowEmbedded, i as EmbeddedKern, l as loadEmbeddedFace, n as EmbeddedFaceMetrics, o as NOTDEF_GLYPH_ID, r as EmbeddedFaceSubstitution, s as collectEmbeddedGlyphs, t as EmbeddedFace } from "./embedded-font-BU6Jgcof.cjs";
+export { EmbeddedFace, EmbeddedFaceMetrics, EmbeddedFaceSubstitution, EmbeddedKern, EmbeddedShow, NOTDEF_GLYPH_ID, collectEmbeddedGlyphs, encodeForShowEmbedded, loadEmbeddedFace };

package/dist/embedded-font.d.ts

@@ -1,2 +1,2 @@
-import { a as NOTDEF_GLYPH_ID, c as loadEmbeddedFace, i as EmbeddedShow, n as EmbeddedFaceMetrics, o as collectEmbeddedGlyphs, r as EmbeddedFaceSubstitution, s as encodeForShowEmbedded, t as EmbeddedFace } from "./embedded-font-CbqkKgBl.js";
-export { EmbeddedFace, EmbeddedFaceMetrics, EmbeddedFaceSubstitution, EmbeddedShow, NOTDEF_GLYPH_ID, collectEmbeddedGlyphs, encodeForShowEmbedded, loadEmbeddedFace };
+import { a as EmbeddedShow, c as encodeForShowEmbedded, i as EmbeddedKern, l as loadEmbeddedFace, n as EmbeddedFaceMetrics, o as NOTDEF_GLYPH_ID, r as EmbeddedFaceSubstitution, s as collectEmbeddedGlyphs, t as EmbeddedFace } from "./embedded-font-fREdbxnr.js";
+export { EmbeddedFace, EmbeddedFaceMetrics, EmbeddedFaceSubstitution, EmbeddedKern, EmbeddedShow, NOTDEF_GLYPH_ID, collectEmbeddedGlyphs, encodeForShowEmbedded, loadEmbeddedFace };

package/dist/embedded-font.js

@@ -2,6 +2,7 @@ import { hasBytes, i16, sfntTableBytes, u16 } from "./sfnt.js";
 import { buildCmapLookup } from "./cmap-table.js";
 import { parseHead, parseMaxp, parseName, parseOs2, parsePost } from "./font-tables.js";
 import { parseGlyf } from "./glyf.js";
+import { buildGposKernLookup } from "./gpos-table.js";
 import { parseHmtx } from "./hmtx-table.js";
 //#region src/embedded-font.ts
 const GLYPH_SPACE_UNITS_PER_EM = 1e3;
@@ -54,6 +55,7 @@ function readEmbeddedFace(font) {
 	const { unitsPerEm } = head;
 	const scale = (designUnits) => scaleToGlyphSpace(designUnits, unitsPerEm);
 	const capHeight = resolveCapHeight(font, cmap, os2?.sCapHeight, hhea.ascent);
+	const kern = buildGposKernLookup(font);
 	return {
 		font,
 		postScriptName: name.postScriptName,
@@ -82,7 +84,8 @@ function readEmbeddedFace(font) {
 			serif: isSerifByPanose(os2?.panose)
 		},
 		glyphId: (codePoint) => cmap(codePoint),
-		glyphSpaceWidth: (glyphId) => scale(hmtx.advanceWidth(glyphId))
+		glyphSpaceWidth: (glyphId) => scale(hmtx.advanceWidth(glyphId)),
+		kernGlyphSpace: kern === void 0 ? () => 0 : (leftGlyphId, rightGlyphId) => scale(kern(leftGlyphId, rightGlyphId) ?? 0)
 	};
 }
 const HHEA_TABLE_SIZE = 36;
@@ -103,26 +106,40 @@ function parseHhea(font) {
 		numberOfHMetrics
 	};
 }
+const CID_BYTE_LENGTH = 2;
 function encodeForShowEmbedded(text, face) {
 	const glyphIds = [];
 	const substitutions = [];
+	const kerns = [];
 	let width1000 = 0;
 	for (const character of text) {
 		const glyphId = face.glyphId(character.codePointAt(0));
 		if (glyphId === void 0) substitutions.push({ from: character });
 		const shown = glyphId ?? 0;
+		const previous = glyphIds[glyphIds.length - 1];
+		if (previous !== void 0) {
+			const adjustment1000 = face.kernGlyphSpace(previous, shown);
+			if (adjustment1000 !== 0) {
+				kerns.push({
+					codeOffset: glyphIds.length * CID_BYTE_LENGTH,
+					adjustment1000
+				});
+				width1000 += adjustment1000;
+			}
+		}
 		glyphIds.push(shown);
 		width1000 += face.glyphSpaceWidth(shown);
 	}
-	const codes = new Uint8Array(glyphIds.length * 2);
+	const codes = new Uint8Array(glyphIds.length * CID_BYTE_LENGTH);
 	glyphIds.forEach((glyphId, index) => {
-		codes[index * 2] = glyphId >> 8 & 255;
-		codes[index * 2 + 1] = glyphId & 255;
+		codes[index * CID_BYTE_LENGTH] = glyphId >> 8 & 255;
+		codes[index * CID_BYTE_LENGTH + 1] = glyphId & 255;
 	});
 	return {
 		codes,
 		width1000,
-		substitutions
+		substitutions,
+		kerns
 	};
 }
 function collectEmbeddedGlyphs(texts, face) {

package/dist/{font-registry-yby02snZ.d.cts → font-registry-B5qL0Vi0.d.cts}

@@ -1,5 +1,5 @@
 import { r as StandardFontName } from "./afm-widths-DyDq56Ph.cjs";
-import { t as EmbeddedFace } from "./embedded-font-CLedn-mT.cjs";
+import { t as EmbeddedFace } from "./embedded-font-BU6Jgcof.cjs";
 import { LayoutFont } from "document-schema.js";
 //#region src/font-registry.d.ts
 interface ProvidedFont {

package/dist/{font-registry-Cn7P9lAh.d.ts → font-registry-mgdbNP8_.d.ts}

@@ -1,5 +1,5 @@
 import { r as StandardFontName } from "./afm-widths-DyDq56Ph.js";
-import { t as EmbeddedFace } from "./embedded-font-CbqkKgBl.js";
+import { t as EmbeddedFace } from "./embedded-font-fREdbxnr.js";
 import { LayoutFont } from "document-schema.js";
 //#region src/font-registry.d.ts
 interface ProvidedFont {

package/dist/font-registry.d.cts

@@ -1,2 +1,2 @@
-import { a as ResolvedFace, i as ProvidedFont, n as FontRegistryOptions, o as createFontRegistry, r as FontSubstitution, s as resolveFaceWithRegistry, t as FontRegistry } from "./font-registry-yby02snZ.cjs";
+import { a as ResolvedFace, i as ProvidedFont, n as FontRegistryOptions, o as createFontRegistry, r as FontSubstitution, s as resolveFaceWithRegistry, t as FontRegistry } from "./font-registry-B5qL0Vi0.cjs";
 export { FontRegistry, FontRegistryOptions, FontSubstitution, ProvidedFont, ResolvedFace, createFontRegistry, resolveFaceWithRegistry };

package/dist/font-registry.d.ts

@@ -1,2 +1,2 @@
-import { a as ResolvedFace, i as ProvidedFont, n as FontRegistryOptions, o as createFontRegistry, r as FontSubstitution, s as resolveFaceWithRegistry, t as FontRegistry } from "./font-registry-Cn7P9lAh.js";
+import { a as ResolvedFace, i as ProvidedFont, n as FontRegistryOptions, o as createFontRegistry, r as FontSubstitution, s as resolveFaceWithRegistry, t as FontRegistry } from "./font-registry-mgdbNP8_.js";
 export { FontRegistry, FontRegistryOptions, FontSubstitution, ProvidedFont, ResolvedFace, createFontRegistry, resolveFaceWithRegistry };

package/dist/formula.d.cts

@@ -1,4 +1,4 @@
-import { t as MathBox } from "./math-types-YSQUTviw.cjs";
+import { n as MathBox } from "./math-types-BZkWO5Ow.cjs";
 //#region src/formula.d.ts
 interface PositionedFormula {
   readonly pageIndex: number;

package/dist/formula.d.ts

@@ -1,4 +1,4 @@
-import { t as MathBox } from "./math-types-YSQUTviw.js";
+import { n as MathBox } from "./math-types-Bq7tyV4g.js";
 //#region src/formula.d.ts
 interface PositionedFormula {
   readonly pageIndex: number;