ooxml-ui 0.30.1 → 1.0.0

package/dist/pptx/render/virtualized-list.d.ts

@@ -0,0 +1,16 @@
+/** Framework-neutral virtual-list range used by every thumbnail sidebar. */
+export interface VirtualizedRange {
+    startIndex: number;
+    endIndex: number;
+    totalHeight: number;
+    offsetY: number;
+    visibleRange: {
+        start: number;
+        end: number;
+    };
+}
+export declare const DEFAULT_VIRTUAL_OVERSCAN = 5;
+export declare const SLIDE_VIRTUALIZATION_THRESHOLD = 50;
+/** Compute the rendered item window for fixed-height virtual lists. */
+export declare function computeVirtualRange(totalItems: number, itemHeight: number, scrollTop: number, viewportHeight: number, overscan?: number): VirtualizedRange;
+//# sourceMappingURL=virtualized-list.d.ts.map

package/dist/pptx/render/virtualized-list.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"virtualized-list.d.ts","sourceRoot":"","sources":["../../../src/pptx/render/virtualized-list.ts"],"names":[],"mappings":"AAAA,4EAA4E;AAC5E,MAAM,WAAW,gBAAgB;IAChC,UAAU,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;IACjB,WAAW,EAAE,MAAM,CAAC;IACpB,OAAO,EAAE,MAAM,CAAC;IAChB,YAAY,EAAE;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAA;KAAE,CAAC;CAC7C;AAED,eAAO,MAAM,wBAAwB,IAAI,CAAC;AAC1C,eAAO,MAAM,8BAA8B,KAAK,CAAC;AAEjD,uEAAuE;AACvE,wBAAgB,mBAAmB,CAClC,UAAU,EAAE,MAAM,EAClB,UAAU,EAAE,MAAM,EAClB,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,MAAM,EACtB,QAAQ,SAA2B,GACjC,gBAAgB,CA6BlB"}

package/dist/pptx/render/visual-3d-bevel-light.d.ts

@@ -0,0 +1,92 @@
+/**
+ * `a:lightRig/@dir` -> top-bevel highlight/shadow direction (framework-agnostic).
+ *
+ * COM-measured 2026-09 (real PowerPoint, `Slide.Export`, a mid-grey 2in
+ * square with a wide `a:bevelT` circle profile, `Depth = 0`): sampling
+ * brightness at the top/right/bottom/left edge bands under each of the 8
+ * `a:lightRig/@dir` values shows the highlight snaps to exactly ONE of the 4
+ * cardinal edges, never a blend of two:
+ *
+ * ```
+ * dir   top right bottom left  (brightness, mid-grey centre = 138)
+ * t     163   92    105   120
+ * tr    163  113     90   100  <- same dominant edge (top) as `t`
+ * r     121  159     97   105
+ * br    101  159    117    91  <- same dominant edge (right) as `r`
+ * b     113  120    165    93
+ * bl     96   99    165   114  <- same dominant edge (bottom) as `b`
+ * l      95  106    124   160
+ * tl    115   90    103   160  <- same dominant edge (left) as `l`
+ * ```
+ *
+ * Each diagonal (`tr`/`br`/`bl`/`tl`) reproduces the SAME dominant edge as
+ * the cardinal direction it follows going clockwise (`t`->`tr`, `r`->`br`,
+ * `b`->`bl`, `l`->`tl`), i.e. the dominant edge is the compass direction at
+ * `floor(angle / 90) * 90`, not a diagonal blend the way the pre-existing
+ * (direction-blind) implementation's hardcoded top-left diagonal highlight
+ * implied.
+ *
+ * A second, larger campaign (2026-09) re-ran this exact brightness scan for
+ * ALL 12 `a:bevelT/@prst` profiles (`relaxedInset`, `circle`, `slope`,
+ * `cross`, `angle`, `softRound`, `convex`, `coolSlant`, `divot`, `riblet`,
+ * `hardEdge`, `artDeco`) x all 8 directions at a wide (24pt) depth, plus a
+ * 6pt-vs-24pt depth check for 3 representative profiles:
+ *
+ * - 9 of the 12 profiles (every one above except `softRound`, `slope` and
+ *   `hardEdge`) reproduced the exact same cardinal-snap pattern as `circle`,
+ *   confirming {@link getBevelHighlightDirection}'s direction mapping
+ *   generalises across profile SHAPE, not just `circle`.
+ * - `softRound` measured the OPPOSITE cardinal edge as its highlight for
+ *   every one of the 8 directions (e.g. `dir="t"` lit up the BOTTOM edge,
+ *   not the top): {@link isBevelProfileInverted} flags this so
+ *   `visual-3d.ts`'s `getBevelShadow` negates the resolved vector for this
+ *   one profile. Physically plausible: a "soft round" transition can read as
+ *   a rounded INSET (a shallow groove catching shadow from the light side)
+ *   rather than `circle`'s rounded OUTSET (a dome catching highlight),
+ *   inverting which edge faces the light.
+ * - `slope` and `hardEdge` measured UNIFORM brightness (no directional signal
+ *   at all) at the same 0.15in-from-edge sample point every other profile
+ *   used, and a follow-up fine-grained radial scan (offsets from 0.01in to
+ *   0.3in) found only a universal, direction-INDEPENDENT darkening right at
+ *   the crisp fold (both the "highlight" and "opposite" edges darkened by a
+ *   similar amount within the first ~0.05in for BOTH profiles), consistent
+ *   with a real single-flat-facet self-shadowed seam rather than a smooth
+ *   directional gradient. No sampling depth tested recovered a clean
+ *   cardinal-snap signal for these two, so their direction handling is left
+ *   unverified/inconclusive rather than encoding a guess from noisy data;
+ *   they still render with the shared cardinal-snap direction (a reasonable
+ *   approximation, just not independently confirmed the way the other 10
+ *   profiles now are).
+ * - The highlight/shadow band's on-screen WIDTH scales with the bevel's
+ *   actual size (confirmed for `circle`, `angle` and `softRound` at 6pt vs.
+ *   24pt: the 6pt bevel's directional signal collapsed to background within
+ *   ~0.1in of the edge, the 24pt bevel's extended to ~0.3in, roughly
+ *   matching the 4x depth ratio). This was already the existing behaviour
+ *   (`visual-3d.ts`'s `getBevelShadow` derives its inset-shadow offsets from
+ *   the shape's ACTUAL `bevelTopWidth`/`Height` in px, not a fixed
+ *   constant), so no code change was needed for this finding; it is now
+ *   COM-confirmed rather than assumed.
+ *
+ * @module render/visual-3d-bevel-light
+ */
+/** A highlight direction as a unit-ish (dx, dy) vector in CSS inset-shadow offset space. */
+export interface BevelLightVector {
+    dx: number;
+    dy: number;
+}
+/**
+ * Resolve the TOP bevel's highlight direction from `a:lightRig/@dir`.
+ * Falls back to the pre-existing top-left diagonal default when the
+ * direction is missing/unrecognised, so an authored deck with no light rig
+ * (or an unmapped direction) keeps rendering exactly as before this module
+ * existed.
+ */
+export declare function getBevelHighlightDirection(lightRigDirection: string | undefined): BevelLightVector;
+/**
+ * Whether a `a:bevelT/@prst` profile measured an INVERTED highlight/shadow
+ * relative to the shared cardinal-snap direction (see the module doc
+ * comment): true only for `softRound`, which lit up the edge OPPOSITE the
+ * light-rig direction in every one of the 8 directions tested.
+ */
+export declare function isBevelProfileInverted(bevelType: string): boolean;
+//# sourceMappingURL=visual-3d-bevel-light.d.ts.map

package/dist/pptx/render/visual-3d-bevel-light.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visual-3d-bevel-light.d.ts","sourceRoot":"","sources":["../../../src/pptx/render/visual-3d-bevel-light.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsEG;AAcH,4FAA4F;AAC5F,MAAM,WAAW,gBAAgB;IAChC,EAAE,EAAE,MAAM,CAAC;IACX,EAAE,EAAE,MAAM,CAAC;CACX;AAUD;;;;;;GAMG;AACH,wBAAgB,0BAA0B,CACzC,iBAAiB,EAAE,MAAM,GAAG,SAAS,GACnC,gBAAgB,CAUlB;AAED;;;;;GAKG;AACH,wBAAgB,sBAAsB,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAEjE"}

package/dist/pptx/render/visual-3d-bevel-lighting-layer.d.ts

@@ -0,0 +1,51 @@
+/**
+ * Per-side filter-parameter resolution for the bevel lighting filter.
+ *
+ * Split out of `visual-3d-bevel-lighting.ts` to keep that module under the
+ * repo's ~300 LOC guideline: this file resolves ONE bevel side's numeric
+ * filter-primitive parameters (azimuth/elevation/blur/material response),
+ * `visual-3d-bevel-lighting.ts` turns a resolved layer into `<fe*>` markup.
+ *
+ * @module render/visual-3d-bevel-lighting-layer
+ */
+import type { BevelLightingSceneParams } from './visual-3d-bevel-lighting.js';
+/**
+ * Resolve the SVG `feDistantLight` azimuth (degrees) for one bevel side.
+ * `rigInverted` is `LIGHT_RIG_LIGHTING`'s COM-measured `invertedDirection`
+ * flag (see that table's doc comment): 10 of the 27 `a:lightRig/@rig` tokens
+ * measure their highlight on the edge OPPOSITE `dir`, the same kind of 180deg
+ * flip `isBevelProfileInverted` already applies for `softRound`, so it
+ * combines with (multiplies) the existing profile/bottom-bevel inversions
+ * rather than replacing them.
+ */
+export declare function resolveAzimuthDeg(bevelType: string, lightRigDirection: string | undefined, isBottom: boolean, rigInverted: boolean): number;
+/** One bevel side's resolved filter-primitive parameters. */
+export interface BevelFilterLayer {
+    index: number;
+    blurStdDev: number;
+    morphologyRadius?: number;
+    /**
+     * `feFuncA type="table"` stops reshaping the blur(+erode) height ramp into
+     * a non-monotonic (two-lobe) profile before it is lit, for the 3 profiles
+     * whose COM cross-section needs one (see `BevelProfileHeightMap
+     * .heightTransferTable`'s doc comment). `undefined` for every other
+     * profile, which lights the blur(+erode) ramp directly, unchanged.
+     */
+    heightTransferTable?: readonly number[];
+    surfaceScale: number;
+    azimuthDeg: number;
+    elevationDeg: number;
+    /**
+     * The specular light's OWN elevation, decoupled from `elevationDeg`
+     * (diffuse) when the material carries a `specularElevationCapDeg` (see
+     * `MaterialLighting`'s doc comment). Equal to `elevationDeg` for every
+     * material without a cap, so this is a no-op for all of them.
+     */
+    specularElevationDeg: number;
+    diffuseConstant: number;
+    specularConstant: number;
+    specularExponent: number;
+    lightingColor: string;
+}
+export declare function resolveLayer(index: number, bevelType: string, widthEmu: number | undefined, heightEmu: number | undefined, isBottom: boolean, scene: BevelLightingSceneParams | undefined, material: string | undefined): BevelFilterLayer;
+//# sourceMappingURL=visual-3d-bevel-lighting-layer.d.ts.map

package/dist/pptx/render/visual-3d-bevel-lighting-layer.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visual-3d-bevel-lighting-layer.d.ts","sourceRoot":"","sources":["../../../src/pptx/render/visual-3d-bevel-lighting-layer.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAGH,OAAO,KAAK,EAAE,wBAAwB,EAAE,MAAM,4BAA4B,CAAC;AAU3E;;;;;;;;GAQG;AACH,wBAAgB,iBAAiB,CAChC,SAAS,EAAE,MAAM,EACjB,iBAAiB,EAAE,MAAM,GAAG,SAAS,EACrC,QAAQ,EAAE,OAAO,EACjB,WAAW,EAAE,OAAO,GAClB,MAAM,CAOR;AAED,6DAA6D;AAC7D,MAAM,WAAW,gBAAgB;IAChC,KAAK,EAAE,MAAM,CAAC;IACd,UAAU,EAAE,MAAM,CAAC;IACnB,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B;;;;;;OAMG;IACH,mBAAmB,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;IACxC,YAAY,EAAE,MAAM,CAAC;IACrB,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB;;;;;OAKG;IACH,oBAAoB,EAAE,MAAM,CAAC;IAC7B,eAAe,EAAE,MAAM,CAAC;IACxB,gBAAgB,EAAE,MAAM,CAAC;IACzB,gBAAgB,EAAE,MAAM,CAAC;IACzB,aAAa,EAAE,MAAM,CAAC;CACtB;AAED,wBAAgB,YAAY,CAC3B,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,MAAM,EACjB,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,SAAS,EAAE,MAAM,GAAG,SAAS,EAC7B,QAAQ,EAAE,OAAO,EACjB,KAAK,EAAE,wBAAwB,GAAG,SAAS,EAC3C,QAAQ,EAAE,MAAM,GAAG,SAAS,GAC1B,gBAAgB,CAoClB"}

package/dist/pptx/render/visual-3d-bevel-lighting-material.d.ts

@@ -0,0 +1,92 @@
+/**
+ * Material -> `feDiffuseLighting`/`feSpecularLighting` response table.
+ *
+ * Split out of `visual-3d-bevel-lighting-tables.ts` to keep both files under
+ * the repo's ~300 LOC guideline; see that module's doc comment for the other
+ * two axes (bevel profile height-map shape, light rig elevation).
+ *
+ * @module render/visual-3d-bevel-lighting-material
+ */
+import type { MaterialPresetType } from 'ooxml-core/pptx';
+/** feDiffuseLighting/feSpecularLighting constants for a material preset. */
+export interface MaterialLighting {
+    diffuseConstant: number;
+    specularConstant: number;
+    specularExponent: number;
+    /** `lighting-color` for both primitives; a hex string. */
+    lightingColor: string;
+    /**
+     * Multiplies the profile-derived `surfaceScale` (default 1 = unchanged).
+     * Calibrated per material against the COM highlight/shadow table (see
+     * this module's doc comment): a material whose true shadow-side
+     * reflectance sits far above a fully-shadowed (`N.L <= 0`, clamped to
+     * black) diffuse response needs a SHALLOWER effective height map (a
+     * smaller multiplier) so fewer height-map texels clamp to zero at the
+     * measurement offset, not a differently-shaped one.
+     */
+    surfaceScaleMultiplier: number;
+    /**
+     * Caps the `feSpecularLighting` light's OWN elevation at this value
+     * (degrees), independent of the diffuse `a:lightRig` elevation table.
+     * `undefined` (every material except `metal`) means the specular light
+     * reuses the diffuse elevation unchanged, today's behaviour. See
+     * `visual-3d-bevel-lighting.ts`'s module doc for why this exists: at a
+     * flat (unbevelled) normal, `feSpecularLighting`'s closed-form hot-spot
+     * brightness is `specularConstant * max(0, N.H)^specularExponent`, and
+     * `N.H` -> 1 as the light elevation -> 90deg, so a high-elevation rig
+     * (`flat`, `contrasting`, `threePt`, ...) saturates the ENTIRE shape, not
+     * just its bevel band, for any material with a non-negligible
+     * `specularConstant`. Capping only the SPECULAR light's elevation (never
+     * the diffuse one, so diffuse shading is untouched) bounds `N.H` below 1
+     * for those rigs while leaving already-low-elevation rigs (`morning`,
+     * `sunrise`, ...) unchanged, since `Math.min(rigElevationDeg, cap)` is a
+     * no-op below the cap.
+     */
+    specularElevationCapDeg?: number;
+}
+/**
+ * `a:sp3d/@prstMaterial` -> lighting response. COM-measured (2026-09, real
+ * PowerPoint, `Slide.Export`, 0.15in-from-edge sample) comparing `matte`
+ * against `metal` at `dir="t"`/`"r"`/`"b"`/`"l"` for `circle`/`angle`/
+ * `hardEdge`/`softRound` (32 samples; mean highlight/shadow brightness,
+ * 0-255, averaged over direction): `metal` measured UNIFORMLY BRIGHTER than
+ * `matte` at BOTH the highlight and shadow sample points in every profile
+ * (circle 221/178 vs 137/90, angle 141/86 vs 139/64, hardEdge 137/137 vs
+ * 133/133, softRound 85/141 vs 63/139) - consistent with a higher overall
+ * reflectivity - but did NOT measure a higher highlight-minus-shadow
+ * CONTRAST at this fixed sample distance: contrast was about equal for
+ * `circle` (43 vs 47) and LOWER for `metal` on `angle` (55 vs 75) and
+ * `softRound` (56 vs 76 in magnitude). This does not confirm the "narrower,
+ * sharper specular falloff" story this module's `specularConstant`/
+ * `specularExponent` tuning assumes; a plausible explanation is that a real
+ * metal specular peak sits closer than 0.15in to the edge, so a fixed-offset
+ * sample already reads past it into a brighter but flatter region - but that
+ * is inference from this one campaign, not a second confirmed measurement at
+ * a different offset. A live render-vs-COM check (`visual-3d-bevel-lighting
+ * .ts`'s module doc table) found this module's `metal` numbers give a mixed
+ * result: `matte` improved clearly over the old box-shadow approach (56.3 ->
+ * 34.8 mean error) while `metal` did not (61.2 -> 59.7, and `metal`/`circle`
+ * specifically got WORSE, 54.9 -> 80.1) - the constants below were therefore
+ * flagged UNVALIDATED for `metal`, and `metal`/`circle` was ROUTED to the
+ * legacy box-shadow model (`visual-3d-bevel-lighting-routing.ts`). The other
+ * materials are positioned between/around the `matte`/`metal` anchors by
+ * category (glossy plastics near `metal` but softer, matte/powder variants
+ * near `matte`), not independently COM-measured at all.
+ *
+ * RESOLVED for `metal`/`circle` (2026-09, the bevel-profile cross-section
+ * campaign, `visual-3d-bevel-lighting-tables.ts`'s `BEVEL_PROFILE_HEIGHT_MAP`
+ * doc comment): re-fitting `circle`'s profile-table entry against real COM
+ * cross-section data (unrelated to material tuning) changed
+ * `surfaceScaleFactor` from 1 to 0.65, and with these SAME `metal` constants
+ * (unchanged from the paragraph above) that alone brought `metal`/`circle`'s
+ * mean error to 39.5 against the SAME 54.9 baseline - confirmed against
+ * fresh COM ground truth AND an actual headless-Chromium rasterisation of
+ * the real filter chain (not just the closed-form model this module's own
+ * campaigns otherwise used), so `metal`/`circle` no longer routes; see
+ * `visual-3d-bevel-lighting-routing.ts`'s doc comment for the numbers and a
+ * separate, NOT-landed attempt at fixing the flat-interior specular
+ * saturation defect below.
+ */
+export declare const MATERIAL_LIGHTING: Record<MaterialPresetType, MaterialLighting>;
+export declare function getMaterialLighting(material: string | undefined): MaterialLighting;
+//# sourceMappingURL=visual-3d-bevel-lighting-material.d.ts.map

package/dist/pptx/render/visual-3d-bevel-lighting-material.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visual-3d-bevel-lighting-material.d.ts","sourceRoot":"","sources":["../../../src/pptx/render/visual-3d-bevel-lighting-material.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,iBAAiB,CAAC;AAE1D,4EAA4E;AAC5E,MAAM,WAAW,gBAAgB;IAChC,eAAe,EAAE,MAAM,CAAC;IACxB,gBAAgB,EAAE,MAAM,CAAC;IACzB,gBAAgB,EAAE,MAAM,CAAC;IACzB,0DAA0D;IAC1D,aAAa,EAAE,MAAM,CAAC;IACtB;;;;;;;;OAQG;IACH,sBAAsB,EAAE,MAAM,CAAC;IAC/B;;;;;;;;;;;;;;;;OAgBG;IACH,uBAAuB,CAAC,EAAE,MAAM,CAAC;CACjC;AAID;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0CG;AACH,eAAO,MAAM,iBAAiB,EAAE,MAAM,CAAC,kBAAkB,EAAE,gBAAgB,CA4L1E,CAAC;AAQF,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,MAAM,GAAG,SAAS,GAAG,gBAAgB,CAGlF"}

package/dist/pptx/render/visual-3d-bevel-lighting-profile.d.ts

@@ -0,0 +1,141 @@
+/**
+ * `a:bevelT/@prst` profile -> SVG height-map shape.
+ *
+ * Split out of `visual-3d-bevel-lighting-tables.ts` to keep both files under
+ * the repo's ~300 LOC guideline; see that module's doc comment for the other
+ * two axes (light rig elevation, material response) and the highlight
+ * DIRECTION, which is resolved separately in `visual-3d-bevel-light.ts`.
+ *
+ * @module render/visual-3d-bevel-lighting-profile
+ */
+/** How wide/sharp a bevel profile's SVG height-map ramp is, and how strongly it carries a directional signal. */
+export interface BevelProfileHeightMap {
+    /** `feGaussianBlur` `stdDeviation` factor, multiplied by the bevel's own (width+height)/2 in px. */
+    blurFactor: number;
+    /** `feMorphology` `radius` factor (erode), or `undefined` for a pure-blur (smooth, curved) profile. */
+    morphologyFactor?: number;
+    /** Relief height (`surfaceScale`) factor: 1 = full, less for a shallow/steep-walled profile. */
+    surfaceScaleFactor: number;
+    /**
+     * `true` for the two profiles (`slope`, `hardEdge`) COM-measured (see
+     * `visual-3d-bevel-light`) to show NO clean directional brightness signal
+     * at any sampled depth, only a crisp, near-uniform self-shadowed seam. This
+     * is about which CARDINAL EDGE lights up (or doesn't), independent of the
+     * cross-section ramp SHAPE the factors below now target - see this
+     * module's doc comment. Kept as a flag so callers/tests can assert on it
+     * rather than re-deriving it from the two factors above.
+     */
+    measuredUniform: boolean;
+    /**
+     * Non-monotonic height REMAP for the three profiles (`relaxedInset`,
+     * `slope`, `hardEdge`) whose COM cross-section is a genuine
+     * bright-bump-then-dark-trough double transition (see this module's doc
+     * comment), which the `blurFactor`/`morphologyFactor`/`surfaceScaleFactor`
+     * ramp above cannot reproduce on its own: that ramp only ever builds a
+     * single monotonic height field (alpha blurred, optionally eroded), so its
+     * diffuse/specular response can rise-then-settle but never
+     * rise-then-undershoot-then-settle.
+     *
+     * When present, `visual-3d-bevel-lighting.ts` feeds the monotonic ramp
+     * through an SVG `feComponentTransfer`/`feFuncA type="table"` BEFORE
+     * lighting it: `feFuncA` linearly interpolates between these stops across
+     * the input domain `[0, 1]`, so a table that rises then falls then rises
+     * again reshapes the height field's spatial derivative (and therefore its
+     * surface normal, and therefore its diffuse/specular brightness) into a
+     * genuine two-lobe profile, even though the INPUT ramp it remaps is still
+     * monotonic. This is the "genuinely non-monotonic (two-lobe) height-map"
+     * the pre-2026-09-16 doc comment below flagged as out of scope; it is
+     * cheap to build this way because `feComponentTransfer` remaps a value
+     * pointwise, so it needs no new geometry primitive, just a reshaping stage
+     * between the existing blur/erode step and `feDiffuseLighting`.
+     *
+     * Each profile's table is the profile's own pinned 24pt COM cross-section
+     * curve (`visual-3d-bevel-lighting-tables.test.ts`'s
+     * `MEASURED_24PT_CURVES`, 10 points from the top edge inward), normalised
+     * to `[0, 1]` via `(brightness - min) / (max - min)`. This is a deliberate
+     * choice, not a claim of a rigorously inverted lighting model: for a
+     * gently-curved, primarily-diffuse height field the rendered brightness
+     * tracks the local height fairly directly, so reusing the MEASURED
+     * brightness curve's own shape as the height-remap curve reproduces the
+     * measured peak/trough/recovery POSITIONS closely without solving the
+     * (non-invertible in closed form) diffuse/specular equations backwards.
+     * Verified structurally (`visual-3d-bevel-lighting.test.ts`): each table
+     * is non-monotonic (has an interior local max followed by an interior
+     * local min before recovering), and the generated filter markup carries
+     * the `feComponentTransfer` stage only for these three profiles. NOT
+     * independently re-verified against a fresh COM render (no new
+     * `Slide.Export` measurement was taken for this change; the existing 2026-
+     * 09 pins above are the ground truth reused here), so treat the exact
+     * on-screen brightness as an analytical/geometric fit against already-
+     * measured data, not a newly pixel-verified match.
+     */
+    heightTransferTable?: readonly number[];
+}
+/**
+ * `a:bevelT/@prst` (and `bevelB`, which shares the same profile vocabulary)
+ * -> height-map shape. ECMA-376 20.1.10.9 describes each profile's silhouette
+ * (a "circular", "flat sloped", "crossed", "art-deco stepped" etc.
+ * cross-section); these factors were ORIGINALLY grouped into 3
+ * physically-motivated buckets by that description (curved / faceted /
+ * steep-narrow) rather than 12 independent hand-tuned entries, reasoned from
+ * ECMA-376 alone.
+ *
+ * COM-MEASURED 2026-09 (real PowerPoint `Slide.Export`, mid-grey `matte`
+ * square, `threePt` rig / `dir="t"`, `orthographicFront` camera, both a 6pt
+ * and a 24pt `a:bevelT`, a line of 40 brightness samples from the top edge
+ * inward for all 12 profiles): fitting these SAME 3 factors (grid search,
+ * minimum RMSE against the measured curve, both depths jointly) against real
+ * cross-section data overturned the bucket story for 3 profiles.
+ * `circle`/`convex`/`softRound`/`divot` (curved) and `angle`/`cross`/
+ * `coolSlant`/`riblet`/`artDeco` (faceted) fit closely (RMSE 1-7 brightness
+ * units) with factors in the same rough range as the original reasoning, so
+ * their bucket membership held up. `relaxedInset`, `slope` and `hardEdge`
+ * did NOT: all three measured a genuine BRIGHT-BUMP-THEN-DARK-TROUGH double
+ * transition partway through the ramp (e.g. `hardEdge` at 24pt: baseline 133
+ * -> peaks ~139 -> drops to 67 -> recovers), which this filter's single
+ * monotonic blur(+erode) height map (one bell-shaped slope lobe) cannot
+ * reproduce on its own - the original 3-parameter fit pushed
+ * `surfaceScaleFactor` to the largest tested value trying to reach the
+ * trough depth, landing the LARGEST relief factor of any profile, the
+ * opposite of the pre-2026-09 "slope/hardEdge are low-relief" assumption
+ * (`slope`/`hardEdge` were previously reasoned as "steep/narrow" with
+ * REDUCED relief; `relaxedInset` was previously grouped as "curved" with
+ * full relief and no erode at all), but still only reached RMSE 12-19
+ * against the measured curve (versus 1-7 for the other 9).
+ *
+ * **2026-09-16: closed via a height-remap stage.** These three profiles now
+ * also carry a `heightTransferTable` (see that field's own doc comment
+ * above): an `feComponentTransfer`/`feFuncA type="table"` reshaping stage,
+ * inserted between the existing blur(+erode) ramp and the lighting
+ * primitives, remaps the monotonic ramp through each profile's own measured
+ * bright-bump-then-dark-trough curve shape. The three factors below (blur/
+ * morphology/surfaceScale) are UNCHANGED and still control the underlying
+ * ramp's width and crispness; the new field supplies the genuinely
+ * non-monotonic (two-lobe) height response this doc comment previously
+ * flagged as needing a new primitive chain, without actually needing one.
+ * This was NOT re-verified against a fresh COM render (see
+ * `heightTransferTable`'s doc comment); it is an analytical/geometric fit
+ * against the SAME measured curves pinned below, not a new measurement - see
+ * `docs/guide/limitations.md` and `docs/guide/visual-effects.md` for the
+ * current framing.
+ *
+ * The direction-independence these three still show (`measuredUniform`) is
+ * unaffected: it is a separate, already-COM-confirmed finding (see
+ * `visual-3d-bevel-light.ts`'s module doc comment) about which CARDINAL EDGE
+ * lights up, not about the cross-section ramp shape this campaign measures.
+ * Scripts (scratch, not committed, same convention as `com-acceptance.mjs`):
+ * `scripts/make-bevel-profile-fixture.mjs` (fixture, all 12
+ * profiles x 2 depths), `scripts/measure-bevel-profile-com.ps1`
+ * (COM export + 40-point sampler), `scripts/fit-bevel-profile-com.mjs`
+ * (grid-search fit; a closed-form Gaussian-CDF reimplementation of the
+ * primitive chain, not a headless-browser render - Playwright's Chromium
+ * launch hangs indefinitely via a plain script in this environment, though
+ * `bunx playwright test` itself works fine, used to independently verify the
+ * metal/circle routing conclusion in `visual-3d-bevel-lighting-routing.ts`).
+ * The raw 10-point-per-profile table (24pt depth) is pinned in
+ * `visual-3d-bevel-lighting-tables.test.ts`; the full 40-point x 2-depth
+ * table is in the task report.
+ */
+export declare const BEVEL_PROFILE_HEIGHT_MAP: Record<string, BevelProfileHeightMap>;
+export declare function getBevelProfileHeightMap(bevelType: string): BevelProfileHeightMap;
+//# sourceMappingURL=visual-3d-bevel-lighting-profile.d.ts.map

package/dist/pptx/render/visual-3d-bevel-lighting-profile.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visual-3d-bevel-lighting-profile.d.ts","sourceRoot":"","sources":["../../../src/pptx/render/visual-3d-bevel-lighting-profile.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,iHAAiH;AACjH,MAAM,WAAW,qBAAqB;IACrC,oGAAoG;IACpG,UAAU,EAAE,MAAM,CAAC;IACnB,uGAAuG;IACvG,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,gGAAgG;IAChG,kBAAkB,EAAE,MAAM,CAAC;IAC3B;;;;;;;;OAQG;IACH,eAAe,EAAE,OAAO,CAAC;IACzB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA0CG;IACH,mBAAmB,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;CACxC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AACH,eAAO,MAAM,wBAAwB,EAAE,MAAM,CAAC,MAAM,EAAE,qBAAqB,CAsF1E,CAAC;AAQF,wBAAgB,wBAAwB,CAAC,SAAS,EAAE,MAAM,GAAG,qBAAqB,CAEjF"}

package/dist/pptx/render/visual-3d-bevel-lighting-routing.d.ts

@@ -0,0 +1,15 @@
+/**
+ * Legacy `box-shadow` routing for a `material`/profile combination the SVG
+ * lighting filter cannot beat.
+ *
+ * Split out of `visual-3d-bevel-lighting.ts` to keep that file under the
+ * repo's ~300 LOC guideline.
+ *
+ * @module render/visual-3d-bevel-lighting-routing
+ */
+/**
+ * Whether a `material`/`profile` combination is routed to the legacy
+ * `box-shadow` bevel model instead of the SVG lighting filter.
+ */
+export declare function isRoutedToLegacyBevelShadow(material: string | undefined, profile: string): boolean;
+//# sourceMappingURL=visual-3d-bevel-lighting-routing.d.ts.map

package/dist/pptx/render/visual-3d-bevel-lighting-routing.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visual-3d-bevel-lighting-routing.d.ts","sourceRoot":"","sources":["../../../src/pptx/render/visual-3d-bevel-lighting-routing.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AA2CH;;;GAGG;AACH,wBAAgB,2BAA2B,CAC1C,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,OAAO,EAAE,MAAM,GACb,OAAO,CAET"}

package/dist/pptx/render/visual-3d-bevel-lighting-tables.d.ts

@@ -0,0 +1,140 @@
+/**
+ * Data tables for the real SVG lighting bevel filter (framework-agnostic).
+ *
+ * Split out of `visual-3d-bevel-lighting.ts` to keep that module under the
+ * repo's ~300 LOC guideline. Three independent axes feed the filter this
+ * module's data drives: bevel PROFILE shape (`a:bevelT/@prst`, ECMA-376
+ * 20.1.10.9 `ST_BevelPresetType`, re-exported here but defined in
+ * `visual-3d-bevel-lighting-profile.ts`, itself split out for the same LOC
+ * reason), light rig ELEVATION/specular character (`a:lightRig/@rig`,
+ * ECMA-376 20.1.10.36 `ST_LightRigType`, defined below), and MATERIAL
+ * response (`a:sp3d/@prstMaterial`, ECMA-376 20.1.10.50 `ST_PresetMaterialType`,
+ * re-exported from `visual-3d-bevel-lighting-material.ts`).
+ * The highlight/shadow DIRECTION (azimuth) itself is mostly resolved
+ * elsewhere: `visual-3d-bevel-light`'s already COM-measured cardinal-snap
+ * vector supplies the base azimuth from `a:lightRig/@dir`, and this module's
+ * `LIGHT_RIG_LIGHTING.invertedDirection` (COM-measured, see that export's own
+ * doc comment) supplies the one further correction that vector doesn't
+ * cover: 10 of the 27 rigs flip which cardinal edge lights up.
+ *
+ * An early COM check (2026-09, PowerPoint `Slide.Export`, mid-grey 1.4in
+ * square, `circle`/matte, `dir="t"`, sampled 0.15in from the top and bottom
+ * edges) did NOT confirm the then-assumed "harsh has higher contrast than
+ * threePt" ordering at that sample distance: measured contrast (highlight
+ * brightness minus shadow brightness, 0-255) was `threePt` 47, `soft` 38,
+ * `flat` 0 (exactly, matching `flat`'s intentional no-op design), and `harsh`
+ * only -4. A full 27-rig, two-direction (`dir="t"` and the perpendicular
+ * `dir="r"`) follow-up campaign (see `LIGHT_RIG_LIGHTING`'s doc comment)
+ * resolved this: `harsh`'s -4 was not noise or a narrower falloff band, it
+ * was `harsh` being one of the 10 `invertedDirection` rigs (highlight on the
+ * edge OPPOSITE `dir`, so its small measured value is a near-flat rig with
+ * the "wrong" sign, not a sharp rig sampled past its falloff). See
+ * `visual-3d-bevel-lighting.ts`'s module doc for the (separately real)
+ * profile x material x direction COM comparison table.
+ *
+ * @module render/visual-3d-bevel-lighting-tables
+ */
+export { BEVEL_PROFILE_HEIGHT_MAP, getBevelProfileHeightMap, } from './visual-3d-bevel-lighting-profile.js';
+export type { BevelProfileHeightMap } from './visual-3d-bevel-lighting-profile.js';
+/** Light elevation (degrees, 0 = grazing, 90 = straight-on) and specular sharpness bucket for a light rig. */
+export interface LightRigLighting {
+    elevationDeg: number;
+    /** `feSpecularLighting`'s `specularExponent` multiplier (1 = neutral). */
+    specularSharpness: number;
+    /**
+     * `true` when this rig's measured highlight sits on the edge OPPOSITE
+     * `a:lightRig/@dir` rather than the edge `dir` points at (see this
+     * module's doc comment). Combines with (multiplies) the bevel-profile
+     * inversion `isBevelProfileInverted` already applies, the same way that
+     * flag and the top/bottom-bevel inversion already combine.
+     */
+    invertedDirection?: boolean;
+}
+/**
+ * `a:lightRig/@rig` -> elevation/sharpness/direction. COM-CALIBRATED
+ * (2026-09, real PowerPoint `Slide.Export`, mid-grey #808080 1.4in square,
+ * `matte`/`circle`, 24pt bevel, `orthographicFront`, all 27 `ST_LightRigType`
+ * tokens, sampled 0.15in from edge, Rec.709 luminance): a `dir="t"` campaign
+ * (sampling the top/bottom edges) and an independent `dir="r"` campaign
+ * (sampling left/right) were run for every rig; the two agreed on both sign
+ * and magnitude for all 27 rigs (mean absolute difference under 1 brightness
+ * unit), confirming `a:lightRig/@dir` genuinely rotates each rig's effective
+ * azimuth (not a fixed, `dir`-independent offset) and that the per-rig
+ * finding below is repeatable, not sampling noise. Scripts (scratch, not
+ * committed, same convention as `com-acceptance.mjs`):
+ * `scripts/_scratch-make-lightrig-fixture.mjs` (dir="t" fixture, all 27
+ * rigs), `scripts/_scratch-make-lightrig-fixture-dirR.mjs` (dir="r"
+ * counterpart), `scripts/_scratch-measure-sample.ps1` (generic COM
+ * `Slide.Export` + pixel sampler). Raw per-rig table (brightness 0-255,
+ * `contrast` = highlight edge minus opposite edge, averaged between the two
+ * campaigns):
+ *
+ * ```
+ * rig             contrast  elevationDeg  invertedDirection
+ * legacyHarsh2      49.0        73        false
+ * threePt           47.5        74        false
+ * legacyNormal2      43.0        75        false
+ * soft               38.5        77        false
+ * legacyFlat2        37.0        77        false
+ * flood              15.5        85        false
+ * legacyHarsh1        0.0        90        false
+ * legacyFlat1        -0.5        90        false
+ * legacyFlat3         0.0        90        false
+ * legacyNormal1       0.0        90        false
+ * legacyNormal3       0.0        90        false
+ * legacyHarsh3        0.0        90        false
+ * contrasting         0.0        90        false
+ * flat                0.0        90        false
+ * glow                0.0        90        false
+ * brightRoom          0.0        90        false
+ * harsh               -4.0       89        true
+ * balanced            -6.0       88        true
+ * twoPt              -30.5       79        true
+ * legacyFlat4        -37.0       77        true
+ * legacyNormal4      -43.0       75        true
+ * legacyHarsh4       -49.0       73        true
+ * sunset             -74.0       64        true
+ * freezing           -79.1       62        true
+ * chilly             -80.2       62        true
+ * sunrise            -88.6       59        true
+ * morning           -101.1       54        true
+ * ```
+ *
+ * `elevationDeg` was fit (not guessed) by rendering the ACTUAL production SVG
+ * filter primitive chain (`visual-3d-bevel-lighting.ts`'s
+ * `resolveLayer`/`renderLayerPrimitives`, reusing the SAME `getBevelProfile
+ * HeightMap('circle')`/`getMaterialLighting('matte')` table lookups this
+ * module already exports) for `elevationDeg` swept 5..90 in 5deg steps at the
+ * identical geometry, taking a pure-SVG (no `foreignObject`, so the canvas
+ * read-back isn't tainted) screenshot-equivalent raster via a headless
+ * Chromium `<canvas>` draw, and sampling the SAME 0.15in-from-edge points.
+ * That render-side sweep is monotonically decreasing in contrast across
+ * `elevationDeg` 45..90 (117 down to 0 brightness units), which covers every
+ * measured `|contrast|` above (max 101.1); each rig's `elevationDeg` is the
+ * piecewise-linear inverse of its measured `|contrast|` against that curve
+ * (`scripts/_scratch-lightrig-calibration-gen.mjs` + a canvas sampler
+ * embedded in `scripts/_scratch-sample-host.html`, both scratch/uncommitted).
+ * `specularSharpness` was NOT part of this campaign (only `elevationDeg`/
+ * `invertedDirection` were COM-fit) and keeps its pre-existing REASONED
+ * per-family value.
+ *
+ * The most consequential finding is `invertedDirection`: 10 of the 27 rigs
+ * (`harsh`, `balanced`, `twoPt`, the `*4` legacy variant of each `legacy{Flat,
+ * Normal,Harsh}` family, and all 5 weather rigs `morning`/`sunrise`/`sunset`/
+ * `chilly`/`freezing`) measure their highlight on the edge OPPOSITE
+ * `a:lightRig/@dir`, not the edge `dir` points at - the previous reasoned
+ * table had no way to represent this (a single `elevationDeg` cannot flip
+ * azimuth) and silently got the highlight side backwards for all 10.
+ * `legacyFlat2`/`legacyNormal2`/`legacyHarsh2` and their `*4` mirror twins
+ * are NOT interchangeable within a "legacy family" the way the old table
+ * assumed (both grouped to one shared value): `*1`/`*3` measure a clean
+ * `elevationDeg=90` (no directional signal at that sample offset) while `*2`
+ * is normal-direction and `*4` is its exact `invertedDirection` mirror
+ * (matching magnitude, opposite sign) - each of the 4 numbered variants in a
+ * legacy family is now its own table entry rather than 4 copies of one value.
+ */
+export declare const LIGHT_RIG_LIGHTING: Record<string, LightRigLighting>;
+export declare function getLightRigLighting(rigType: string | undefined): LightRigLighting;
+export { getMaterialLighting, MATERIAL_LIGHTING } from './visual-3d-bevel-lighting-material.js';
+export type { MaterialLighting } from './visual-3d-bevel-lighting-material.js';
+//# sourceMappingURL=visual-3d-bevel-lighting-tables.d.ts.map

package/dist/pptx/render/visual-3d-bevel-lighting-tables.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visual-3d-bevel-lighting-tables.d.ts","sourceRoot":"","sources":["../../../src/pptx/render/visual-3d-bevel-lighting-tables.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AAEH,OAAO,EACN,wBAAwB,EACxB,wBAAwB,GACxB,MAAM,oCAAoC,CAAC;AAC5C,YAAY,EAAE,qBAAqB,EAAE,MAAM,oCAAoC,CAAC;AAEhF,8GAA8G;AAC9G,MAAM,WAAW,gBAAgB;IAChC,YAAY,EAAE,MAAM,CAAC;IACrB,0EAA0E;IAC1E,iBAAiB,EAAE,MAAM,CAAC;IAC1B;;;;;;OAMG;IACH,iBAAiB,CAAC,EAAE,OAAO,CAAC;CAC5B;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkFG;AACH,eAAO,MAAM,kBAAkB,EAAE,MAAM,CAAC,MAAM,EAAE,gBAAgB,CA4B/D,CAAC;AAIF,wBAAgB,mBAAmB,CAAC,OAAO,EAAE,MAAM,GAAG,SAAS,GAAG,gBAAgB,CAKjF;AAED,OAAO,EAAE,mBAAmB,EAAE,iBAAiB,EAAE,MAAM,qCAAqC,CAAC;AAC7F,YAAY,EAAE,gBAAgB,EAAE,MAAM,qCAAqC,CAAC"}