ooxml-core 1.1.0 → 1.2.1

package/dist/diagram/layout/smartart-layout-item-font-size.d.ts

@@ -0,0 +1,129 @@
+/**
+ * SmartArt DiagramML interpreter - shared item `primFontSz` resolution.
+ *
+ * ECMA-376 21.4.2.x: a `dgm:ruleLst` shrink rule governs every point that
+ * shares it, so a `lin`/`snake` item template's font size is ONE size for
+ * the WHOLE arranged set (the diagram picks the size that makes the
+ * worst-fitting item's text fit, and every item - even a short one - renders
+ * at that SAME size), never each box's own independent best fit. Confirmed
+ * against `smartart-gallery/basic-process--hier5.pptx`'s cached drawing: all
+ * three item boxes share one font size regardless of their own text length.
+ * That sharing is scoped to points arranged through the SAME item role -
+ * see `resolveRoleFontSize`'s doc comment for why a DIFFERENT declared role
+ * of the same item template (a numbered badge alongside its body text) gets
+ * its own independent size instead.
+ *
+ * This resolves that shared size from DiagramML-declared bounds instead of a
+ * hardcoded guess (bounds resolution itself lives in
+ * `smartart-layout-item-font-role.ts`, split out for the file-size budget):
+ *  - the CEILING: the arranger's own `dgm:constr type="primFontSz"` starting
+ *    value declared for the item role (an absolute `val`, e.g. `65`), read
+ *    via the constraint index.
+ *  - the FLOOR: the item layoutNode's own `dgm:ruleLst` minimum `primFontSz`
+ *    `val` (the most aggressive of its shrink stages).
+ * A layoutDef that declares neither keeps the interpreter's pre-existing
+ * heuristic bounds, so a layout with no such constraint renders as before.
+ *
+ * NO DISCRETE SHRINK-STEP SEQUENCE: cross-referencing every gallery fixture's
+ * cached `a:rPr/@sz` against its declared `primFontSz` ceiling found no
+ * common ratio or percentage-step pattern (values ranged continuously from
+ * ~29% to 134% of the declared ceiling) - the ONLY consistent regularity is
+ * that every observed cached size is an EXACT WHOLE POINT (never e.g. a
+ * half-point), confirming PowerPoint solves this continuously (by real text
+ * measurement) rather than by walking a fixed percentage table, then rounds
+ * the result to a whole point. Re-confirmed by dumping every cached `a:rPr/
+ * @sz` across all 227 gallery fixtures: the distinct set is 5-43 (nearly
+ * every whole point) plus 45-52/55/60/65 - no half points anywhere, and no
+ * small fixed ladder (unlike `normAutofit`'s ~10-step fontScale table) -
+ * `resolveSharedItemFontSize` reproduces that granularity by snapping its
+ * own continuous fit to the nearest whole point.
+ *
+ * Units: `dgm:constr`/`dgm:rule` numeric values for `primFontSz`/margins are
+ * in POINTS (ECMA-376's own unit for CT_Constraint numeric attributes), but
+ * every element/box dimension elsewhere in this codebase - and the cached
+ * ground truth's OWN `textStyle.fontSize` (see
+ * `PptxHandlerRuntimeSmartArtParsing.ts`'s `extractDrawingShapeTextStyle`,
+ * `fontSize = (szRaw / 100) * (96 / 72)`) - is in CSS PIXELS. Everything here
+ * converts to pixels immediately so it composes with the pixel-based box
+ * geometry `arrangeLinear`/`arrangeSnake` already work in.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import { resolveFontTable } from './smartart-font-table.js';
+import type { FontAdvanceTable } from '../../text/font-metrics/font-advance-widths.generated';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { ArrangementPlan } from './smartart-layout-interpreter-model.js';
+export { primFontSzCeilingPx, resolveItemSelfAspect } from './smartart-layout-item-font-role.js';
+export { resolveFontTable };
+/** One arranged item's text plus the box (in pixels) it will render into. */
+export interface FontFitItem {
+    text: string;
+    width: number;
+    height: number;
+}
+/**
+ * Resolve the item's own text-frame insets (`dgm:constr type="lMarg"/
+ * "rMarg"/"tMarg"/"bMarg"`, most commonly declared as a `fact` of the item's
+ * own `primFontSz`), in PIXELS, falling back to `table`'s measured default
+ * `a:bodyPr` insets (PowerPoint's own plain-textbox default: 0.1in
+ * left/right, 0.05in top/bottom) when the layoutDef declares none.
+ */
+export declare function itemMarginsPx(index: ConstraintIndex, role: string, table: FontAdvanceTable): {
+    horizontal: number;
+    vertical: number;
+};
+/**
+ * Per-axis margin fraction of a CANDIDATE font size, when the layoutDef
+ * declares `lMarg`/`rMarg`/`tMarg`/`bMarg` as a fraction of `primFontSz`
+ * (`<dgm:constr type="lMarg" refType="primFontSz" fact="0.3"/>`, the pattern
+ * "Basic Process"/"Basic Block List"/"Vertical Bullet List" ALL use).
+ * `itemMarginsPx` resolves this ONCE against the declared CEILING (no
+ * notion of "the font size after shrinking"), UNDER-estimating real
+ * available text space once the fit shrinks below that ceiling - real
+ * margins shrink WITH the font. `undefined` per axis when that axis's
+ * margin is not `primFontSz`-proportional and not entirely absent (a
+ * literal point value), so the caller keeps `itemMarginsPx`'s fixed
+ * default for that axis.
+ */
+export declare function proportionalMarginFraction(index: ConstraintIndex, role: string): {
+    horizontal: number;
+    vertical: number;
+} | undefined;
+/**
+ * Snap `sizePx` to the nearest WHOLE POINT: see the module doc comment's "no
+ * discrete shrink-step sequence" finding - every cached `a:rPr/@sz` across
+ * the gallery corpus is an exact whole point, so the fit result should be
+ * too.
+ */
+export declare function snapToWholePoint(sizePx: number): number;
+/**
+ * Resolve ONE shared font size (in pixels) for `items`: the item role's
+ * declared `primFontSz` is the ceiling, its `dgm:ruleLst` minimum `val` is
+ * the floor, each item's box is measured net of its own text-frame insets,
+ * and the diagram-wide MINIMUM best-fit candidate across every item wins -
+ * see the module doc comment for why no item gets its own independent size.
+ * The result is snapped to the nearest whole point.
+ *
+ * @param naturalAspect - The item template's own self-scoped `h`/`w` aspect
+ *   (`resolveItemSelfAspect`), when the caller's arranger declines to apply
+ *   it to DISPLAY geometry (see that function's doc comment). When present,
+ *   each candidate's fit height is capped at `width * naturalAspect` before
+ *   subtracting margins, so font-fit is solved against the diagram's own
+ *   natural box size even when the displayed box is later stretched taller.
+ */
+export declare function resolveSharedItemFontSize(plan: ArrangementPlan, index: ConstraintIndex, items: readonly FontFitItem[], fontName?: string, naturalAspect?: number): number;
+/**
+ * Resolve a SINGLE per-item-ROLE's own font size (in pixels), independent of
+ * any OTHER role sharing the same arranged point's box. The module doc
+ * comment's "one size for the whole arranged set" sharing is scoped to
+ * points arranged through the SAME role/forEach - it does NOT extend across
+ * DIFFERENT declared roles of the same item template. Measured against
+ * "Numbered Card List": its `sibTransNodeRect` role (the numbered badge,
+ * `<dgm:constr type="primFontSz" val="66"/>`) and `nodeRect` role (the body
+ * text, `val="26"`) are two INDEPENDENT `primFontSz` declarations sharing
+ * nothing - `smartart-layout-interpreter-item-role-stack.ts`'s `stackAsRect`
+ * previously copied the OUTER arranger's single resolved size onto every
+ * split role, putting the badge number at the body text's 26pt ceiling
+ * (cached: 26px/19.5pt) instead of its own, cached 65pt.
+ */
+export declare function resolveRoleFontSize(roleNode: DiagramLayoutNode, index: ConstraintIndex, items: readonly FontFitItem[], fontName?: string): number;
+//# sourceMappingURL=smartart-layout-item-font-size.d.ts.map

package/dist/diagram/layout/smartart-layout-item-font-size.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-item-font-size.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-item-font-size.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClD,OAAO,EAAE,gBAAgB,EAAE,MAAM,uBAAuB,CAAC;AACzD,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,uDAAuD,CAAC;AAE9F,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AACpE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAK3E,OAAO,EAAE,mBAAmB,EAAE,qBAAqB,EAAE,MAAM,kCAAkC,CAAC;AAC9F,OAAO,EAAE,gBAAgB,EAAE,CAAC;AAK5B,6EAA6E;AAC7E,MAAM,WAAW,WAAW;IAC3B,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;CACf;AAED;;;;;;GAMG;AACH,wBAAgB,aAAa,CAC5B,KAAK,EAAE,eAAe,EACtB,IAAI,EAAE,MAAM,EACZ,KAAK,EAAE,gBAAgB,GACrB;IAAE,UAAU,EAAE,MAAM,CAAC;IAAC,QAAQ,EAAE,MAAM,CAAA;CAAE,CAa1C;AAkBD;;;;;;;;;;;;GAYG;AAEH,wBAAgB,0BAA0B,CACzC,KAAK,EAAE,eAAe,EACtB,IAAI,EAAE,MAAM,GACV;IAAE,UAAU,EAAE,MAAM,CAAC;IAAC,QAAQ,EAAE,MAAM,CAAA;CAAE,GAAG,SAAS,CAiCtD;AAED;;;;;GAKG;AACH,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM,CAEvD;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,yBAAyB,CACxC,IAAI,EAAE,eAAe,EACrB,KAAK,EAAE,eAAe,EACtB,KAAK,EAAE,SAAS,WAAW,EAAE,EAC7B,QAAQ,CAAC,EAAE,MAAM,EACjB,aAAa,CAAC,EAAE,MAAM,GACpB,MAAM,CAER;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,mBAAmB,CAClC,QAAQ,EAAE,iBAAiB,EAC3B,KAAK,EAAE,eAAe,EACtB,KAAK,EAAE,SAAS,WAAW,EAAE,EAC7B,QAAQ,CAAC,EAAE,MAAM,GACf,MAAM,CAQR"}

package/dist/diagram/layout/smartart-layout-item-font-tier-fit.d.ts

@@ -0,0 +1,70 @@
+/**
+ * Split out of `smartart-layout-item-font-tier.ts` (the file-size budget):
+ * the pure per-item fit check `resolveTieredItemFontSize`'s binary search
+ * calls at every candidate size - whether a folded item's root paragraph
+ * plus its descendant paragraph(s) together fit a given available box, per
+ * that module's own doc comment (the joint search, per-level `spcAft`, and
+ * the `SMARTART_DESCENDANT_FONT_SCALE` derivation all live there).
+ *
+ * Round 15: a `indent + widestDescendantLine <= availWidthPx` check (the
+ * descendant's cached `a:pPr marL` hanging indent) was tried as an
+ * INDEPENDENT width criterion BOLTED ON to a wrap that still ran against
+ * the FULL `availWidthPx`. It reproduced `basic-process--hier5.pptx`/`--
+ * hier8.pptx`'s cached boundaries but REGRESSED `basic-block-list--
+ * hier5.pptx` and `vertical-process--hier5.pptx`: adding `indent` on top
+ * of a width already computed WITHOUT room for it spuriously rejected
+ * candidates that really do fit. REVERTED.
+ *
+ * **Round 16: the fix is geometric, not a bolted-on check.** A folded
+ * descendant is really laid out by PowerPoint in a NARROWER column -
+ * `availWidthPx - descendantIndentPx(descendantPx)` - not the item's full
+ * width; wrapping the descendant text directly at that narrower column
+ * (rather than wrapping at the full width first) keeps the resulting LINE
+ * COUNT self-consistent with the height budget below, so a text that only
+ * needs one extra wrapped line to clear the indent costs exactly one
+ * extra line of height, never an unconditional hard reject. This is what
+ * fixes round 15's regression: `basic-block-list--hier5.pptx`'s and
+ * `vertical-process--hier5.pptx`'s descendant texts already wrap onto an
+ * extra line inside the narrower column at the SAME candidate size their
+ * root paragraph needs, so the height budget (which already accounts for
+ * per-line height) absorbs the indent correctly instead of a separate
+ * width gate rejecting them outright.
+ *
+ * `descendantIndentPt` (below) is the corpus-derived indent-vs-size rule:
+ * scanned every folded `lin`/`snake` gallery fixture's cached
+ * `drawing1.xml` (not just the 2-3 fixtures round 14/15 used), see its own
+ * doc comment for the full derivation and the 30+ fixtures checked.
+ *
+ * @module smartart-layout-item-font-tier-fit
+ */
+import type { FontAdvanceTable } from '../../text/font-metrics/font-advance-widths.generated';
+/** A folded item's own top-level text plus its descendant paragraphs, kept SEPARATE (see module doc comment). */
+export interface TieredFontFitItem {
+    rootText: string;
+    descendantTexts: readonly string[];
+    width: number;
+    height: number;
+    /**
+     * Round 23: true when `descendantTexts` render as their OWN SEPARATE box
+     * (a role-split item template - "Vertical Bullet List"'s `childText` -
+     * not a paragraph stacked below the root's own in the SAME box, as
+     * `basic-process`'s folded bullet text is). The root then never gets a
+     * trailing `spcAft` for a descendant it is not adjacent to: measured,
+     * removing this spurious term alone closes `vertical-bullet-list--
+     * hier5.pptx`'s "Node One" from 39pt to cached 46pt exactly. Omitted:
+     * unchanged behaviour (every fold-into-the-same-box fixture unaffected).
+     */
+    separateDescendantBox?: boolean;
+}
+/** See {@link DESCENDANT_INDENT_STEPS_PT}'s doc comment. */
+export declare function descendantIndentPt(descendantSizePt: number): number;
+/**
+ * Whether `item`'s root paragraph at `rootPx` (laid out in the full
+ * `availWidthPx` column) plus its descendants at `descendantPx` (each laid
+ * out in the narrower `availWidthPx - descendantIndentPt(...)` column, see
+ * the module doc comment) together fit `availHeightPx`. Also rejects a
+ * candidate outright when any single word - root or descendant - cannot
+ * fit its own column at all (a real overflow, not a wrap boundary).
+ */
+export declare function itemFits(item: TieredFontFitItem, availWidthPx: number, availHeightPx: number, rootPx: number, descendantPx: number, table: FontAdvanceTable, lineSpacingFactor: number): boolean;
+//# sourceMappingURL=smartart-layout-item-font-tier-fit.d.ts.map

package/dist/diagram/layout/smartart-layout-item-font-tier-fit.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-item-font-tier-fit.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-item-font-tier-fit.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AAEH,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,uDAAuD,CAAC;AAI9F,iHAAiH;AACjH,MAAM,WAAW,iBAAiB;IACjC,QAAQ,EAAE,MAAM,CAAC;IACjB,eAAe,EAAE,SAAS,MAAM,EAAE,CAAC;IACnC,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf;;;;;;;;;OASG;IACH,qBAAqB,CAAC,EAAE,OAAO,CAAC;CAChC;AAuDD,4DAA4D;AAC5D,wBAAgB,kBAAkB,CAAC,gBAAgB,EAAE,MAAM,GAAG,MAAM,CAOnE;AAeD;;;;;;;GAOG;AACH,wBAAgB,QAAQ,CACvB,IAAI,EAAE,iBAAiB,EACvB,YAAY,EAAE,MAAM,EACpB,aAAa,EAAE,MAAM,EACrB,MAAM,EAAE,MAAM,EACd,YAAY,EAAE,MAAM,EACpB,KAAK,EAAE,gBAAgB,EACvB,iBAAiB,EAAE,MAAM,GACvB,OAAO,CAsCT"}

package/dist/diagram/layout/smartart-layout-item-font-tier.d.ts

@@ -0,0 +1,139 @@
+/**
+ * SmartArt DiagramML interpreter - two-tier font size for a folded item's own
+ * text vs. its folded descendant paragraph(s).
+ *
+ * `smartart-layout-item-font-size.ts`'s `resolveSharedItemFontSize` (and the
+ * `foldedItemText` it is fed) treats a folded item's WHOLE text - the node's
+ * own top-level paragraph plus every folded descendant paragraph
+ * (`collectFoldedDescendants`, added a level deeper via the text pane's
+ * Tab/"Add Bullet") - as ONE string rendered at ONE uniform font size. Real
+ * PowerPoint does not: every gallery fixture with a folded descendant
+ * paragraph renders that descendant at a SMALLER, INDEPENDENTLY-shrunk size
+ * than the item's own top-level text, in the SAME box - confirmed directly
+ * from the cached `dsp:sp`'s own `txBody`: `basic-block-list--hier5.pptx`'s
+ * "Node One" run carries `sz="4800"` (48pt) while its folded child "Node
+ * Two has a longer label" carries `sz="3700"` (37pt) in the SAME shape - a
+ * uniform-size fit can only ever report ONE of these two numbers.
+ *
+ * A corpus-wide scan (`smartart-gallery/*.pptx`'s cached `drawing1.xml`,
+ * every `<dsp:sp>` with more than one distinct run `sz` across its
+ * paragraphs) found this same two-tier pattern in **53 of the 134** `lin`/
+ * `snake` gallery fixtures - not a `basic-block-list`-specific quirk.
+ *
+ * **The descendant/root ratio is a FIXED constant, not text- or geometry-
+ * dependent** (model (a), "descendant independently fit to its own width/
+ * height", is DISPROVEN; model (b), "fixed per-level ratio", is confirmed).
+ * Across every unique (rootSz, descSz) whole-point pair in a corpus-wide scan
+ * (34 pairs, excluding `numbered-linear-arrow-process`/`numbered-card-list`/
+ * `numbered-title-list` - independent-role composites per `smartart-layout-
+ * item-font-role.ts`'s `resolveRoleFontSize`, a different mechanism - and
+ * `small-dots-horizontal--hier8` - ratio > 1, not a real demotion), the set
+ * of `K` satisfying `round(rootSz * K) === descSz` for EVERY pair
+ * simultaneously is `[0.78, 0.78125]` - non-empty, reproducing 54/56 rows
+ * exactly (full derivation, incl. the width-independence proof: `smartart-
+ * track-l-successor.md`, round 6 section). `data1.xml` carries NO paragraph
+ * properties for either paragraph - the split is a rendering-time DEFAULT,
+ * not authored data this codebase could read instead.
+ *
+ * `SMARTART_DESCENDANT_FONT_SCALE = 0.78` feeds a JOINT search (not two
+ * independent fits): the folded item's own paragraph and its descendant
+ * paragraph(s) are laid out top-to-bottom in the SAME box, so the search
+ * variable is the item's own top-level size `R`; a candidate `R` "fits"
+ * only when the ROOT paragraph's own block (with the REAL per-level
+ * paragraph spacing below) PLUS every descendant paragraph's block, each
+ * wrapped and measured at `R * SMARTART_DESCENDANT_FONT_SCALE`, together fit
+ * the available height - never independently. Reproduces
+ * `basic-block-list--hier5.pptx`'s cached 48pt EXACTLY.
+ *
+ * **`basic-process--hier5.pptx`/`--hier8.pptx` now EXACT (round 8)**: the
+ * round-6/7 1pt-over residual was a HEIGHT-BUDGET problem, not a `K`-ratio
+ * one (`resolveTieredItemFontSize`'s own doc comment has the derivation) -
+ * 0.78 is kept because it is DERIVED (no single `K` in [0.70, 0.95]
+ * satisfies hier5/hier8/both basic-process fixtures at once), not re-tuned
+ * to chase a height-budget residual.
+ *
+ * **Still a known residual**: `basic-block-list--flat3.pptx` (36pt cached,
+ * gives 37pt: no fold, plain `rect`) - COM-verified NOT a wrap-line-count
+ * bug, a genuine sub-point greedy-advance-sum-vs-real-text-shaping
+ * precision ceiling. `basic-block-list--hier8.pptx` carried the SAME
+ * diagnosis through round 15 but is EXACT since round 16 (the real cause
+ * there was the descendant indent, not this precision ceiling).
+ *
+ * Per-level paragraph spacing (`ROOT_SPCAFT_FACTOR`/`DESCENDANT_SPCAFT_FACTOR`
+ * in `smartart-layout-item-font-tier-fit.ts`) is likewise a rendering default
+ * absent from `data1.xml`: every cached `dsp:sp` with a folded descendant
+ * carries `spcAft` 35% on the top-level paragraph and 15% on every
+ * descendant, applied additively (not scaled by `SMARTART_LINE_SPACING_FACTOR`)
+ * except after the box's LAST paragraph (`spcFirstLastPara="0"` skips it
+ * there).
+ *
+ * **Round 13: both special-case branches DELETED, replaced by the single
+ * COM-derived formula above** (`margins.vertical + 2 * cornerInsetPx`,
+ * `lineSpacingFactor` unconditional) - double-corner-inset on BOTH axes is
+ * the correct term (round 12 only ever tried single). Fixes `vertical-
+ * process--hier5.pptx` (exact at 24pt). **Residual, `--hier8.pptx` closed
+ * in round 16, `--hier5.pptx` still open**: both moved from exact to 1pt
+ * OVER (25 vs 24, 20 vs 19), WIDTH-bound - `itemFits` was wrapping the
+ * folded DESCENDANT at the item's FULL width instead of the narrower
+ * column PowerPoint uses (the descendant's cached `a:pPr marL` hanging
+ * indent - `smartart-layout-item-font-tier-fit.ts`'s `descendantIndentPt`).
+ * Round 16's fix closes `--hier8.pptx` exactly; `--hier5.pptx` stays 1pt
+ * over - its real `BoundWidth` gap is ~3x `--hier8.pptx`'s.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { ArrangementPlan } from './smartart-layout-interpreter-model.js';
+import type { TieredFontFitItem } from './smartart-layout-item-font-tier-fit.js';
+export type { TieredFontFitItem };
+/**
+ * See the module doc comment: the data-derived, FIXED top-level/descendant
+ * size ratio (not text- or geometry-dependent). Any value in `[0.78,
+ * 0.78125]` reproduces the corpus equally well; 0.78 is the round number in
+ * that range.
+ */
+export declare const SMARTART_DESCENDANT_FONT_SCALE = 0.78;
+/**
+ * Resolve the shared TOP-LEVEL font size (in pixels) for a group of `items`
+ * that may each carry folded descendant paragraphs, plus the shared
+ * DESCENDANT font size those paragraphs render at - see the module doc
+ * comment for the joint search this runs and why it cannot be two
+ * independent fits. Items with no descendants behave exactly like
+ * `resolveSharedItemFontSize`'s existing single-paragraph fit (the
+ * descendant term drops out entirely).
+ *
+ * @param cornerInsetPx - Extra per-side inset (pixels) beyond the item
+ *   role's own margins, for a `roundRect`-family item shape (see
+ *   `roundRectCornerInsetPx`'s doc comment). Applied AFTER the
+ *   `naturalAspect` height cap (not folded into the caller's `item.width`/
+ *   `item.height`), so it does not distort that cap's own `width * aspect`
+ *   multiplication. Zero for a plain `rect`/other preset, where none of this
+ *   applies.
+ *
+ *   **The real vertical budget, round 13 - derived from live COM, not
+ *   inferred:** `avail = dimension - margins(that axis, REAL) - 2 *
+ *   cornerInsetPx`, the SAME formula on BOTH axes, no special-casing by
+ *   fold status - verified against `basic-process--flat3.pptx` (HEIGHT-
+ *   bound) and `--hier5.pptx` (WIDTH-bound), each fixture's real
+ *   `BoundWidth`/`BoundHeight` checked at the cached size and one size up.
+ *   `SMARTART_LINE_SPACING_FACTOR` applies unconditionally (no
+ *   `naturalAspect`-gated special case).
+ *
+ *   **A second, independent bug (round 8)**: the final
+ *   `snapToWholePoint(rootPx)` can round a CONTINUOUS value that fits (e.g.
+ *   19.9pt) UP to the next whole point (20pt) even when that whole point
+ *   does NOT itself fit. Fixed generally: after rounding, re-verify the
+ *   rounded-UP candidate against the same per-item fit check; fall back to
+ *   the next point DOWN when it does not.
+ *
+ * @param fontRoleNode - Round 18: the item-bearing layoutNode to resolve
+ *   `primFontSz`/margins/rules against, when the caller already knows it
+ *   and `itemFontBoundsPx`'s own `itemNode(plan.node)` first-child
+ *   heuristic would pick the wrong one (a `composite` arranger's item
+ *   slot is not always `plan.node`'s first child). Omitted: falls back to
+ *   `itemFontBoundsPx(plan, index)` exactly as before.
+ */
+export declare function resolveTieredItemFontSize(plan: ArrangementPlan, index: ConstraintIndex, items: readonly TieredFontFitItem[], fontName: string | undefined, naturalAspect: number | undefined, cornerInsetPx?: number, fontRoleNode?: DiagramLayoutNode): {
+    rootSizePx: number;
+    descendantSizePx: number;
+};
+//# sourceMappingURL=smartart-layout-item-font-tier.d.ts.map

package/dist/diagram/layout/smartart-layout-item-font-tier.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-item-font-tier.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-item-font-tier.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiFG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AACpE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAS3E,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,sCAAsC,CAAC;AAE9E,YAAY,EAAE,iBAAiB,EAAE,CAAC;AAGlC;;;;;GAKG;AACH,eAAO,MAAM,8BAA8B,OAAO,CAAC;AAkBnD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AACH,wBAAgB,yBAAyB,CACxC,IAAI,EAAE,eAAe,EACrB,KAAK,EAAE,eAAe,EACtB,KAAK,EAAE,SAAS,iBAAiB,EAAE,EACnC,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,aAAa,EAAE,MAAM,GAAG,SAAS,EACjC,aAAa,SAAI,EACjB,YAAY,CAAC,EAAE,iBAAiB,GAC9B;IAAE,UAAU,EAAE,MAAM,CAAC;IAAC,gBAAgB,EAAE,MAAM,CAAA;CAAE,CAgElD"}

package/dist/diagram/layout/smartart-layout-item-tx-anchor.d.ts

@@ -0,0 +1,105 @@
+/**
+ * SmartArt DiagramML interpreter - per-item text-anchor resolution
+ * (`dgm:alg type="tx"`'s `txAnchorVert`/`txAnchorVertCh` parameters).
+ *
+ * **Round 18: NOT currently wired to anything** (`arrangeLinear`/
+ * `arrangeSnake` reverted their round-17 use of this module) - see
+ * `smartart-layout-item-font-tier.ts`'s module doc comment: the
+ * font-size fit problem this was built to solve turned out to have a
+ * different cause (a wrong `lineHeightRatio`, not a per-anchor line-height
+ * difference - direct COM proof: `VerticalAnchor` does not change
+ * `BoundHeight/Lines/fontSize` at all). The resolver itself is unaffected
+ * by that finding and remains correct/tested - kept as validated,
+ * corpus-verified infrastructure for a genuine `dgm:alg type="tx"` need
+ * (e.g. actually positioning text vertically within a shape to match
+ * PowerPoint's real anchor, a real, separate, NOT-yet-addressed gap this
+ * track has not investigated) rather than deleted.
+ *
+ * Round 17: `smartart-gallery-ground-truth.test.ts`'s cached `drawing1.xml`
+ * shows a folded item's overall `a:bodyPr/@anchor` is NOT a fixed constant
+ * (round 15/16 assumed folded=top, non-folded=center) - a full corpus scan
+ * (`FOLDED` items get `ctr` 50x/`t` 124x/`b` 20x; `SINGLE` items get `ctr`
+ * 550x/`t` 126x/`b` 69x, pooled across the whole gallery) disproves that.
+ * ECMA-376 21.4.7.11 names the real mechanism: the `tx` algorithm's
+ * `txAnchorVert` parameter governs a node's OWN paragraph anchor (default
+ * `mid`), while `txAnchorVertCh` governs the anchor used when a folded
+ * CHILD paragraph is pulled into the same box (default `t`) - so a folded
+ * item's overall anchor is `txAnchorVertCh`, a non-folded item's is
+ * `txAnchorVert`, and BOTH commonly go undeclared (falling to their
+ * different defaults), which is exactly what produces `basic-process--
+ * hier5.pptx`'s mixed `t` (folded)/`ctr` (non-folded) split on ONE preset
+ * family, and `vertical-process--hier5.pptx`'s explicit
+ * `<dgm:param type="txAnchorVertCh" val="mid"/>` override producing a
+ * uniform `ctr` for both.
+ *
+ * `dgm:alg type="tx"` is very often wrapped in a `dgm:choose` (the SAME
+ * idiom the arrangement algorithms use - `smartart-layout-interpreter-
+ * choose-algorithm.ts`), so a real resolution needs the same
+ * `activeBranch`/`nestedChooseBranch` machinery THAT module already uses
+ * for `lin`/`cycle`/`pyra`/`snake`/`hierChild`/`hierRoot` - but `tx` is
+ * deliberately NOT added to that module's own `CHOOSE_ALG_TYPES` (used for
+ * ARRANGER discovery, a different, blind recursive search that must not
+ * accidentally match an unrelated per-item `tx` alg nested somewhere inside
+ * the tree it walks). This module is a separate, narrowly-scoped resolver:
+ * given the item template layoutNode directly (`itemNode(plan.node)`,
+ * already resolved by the caller), find ITS OWN `tx` alg - direct child or
+ * inside ITS OWN `choose` - never searching past it into unrelated nodes.
+ *
+ * `vertical-process--hier5.pptx`'s override condition
+ * (`func="maxDepth" axis="root des" ptType="all node" op="gt" val="1"`)
+ * queries the DATA model's own tree depth, not the layout definition's -
+ * unrelated to `smartart-layout-interpreter-model.ts`'s `treeMaxDepth`
+ * (which walks the LAYOUT node tree for arranger `choose` resolution, a
+ * different tree entirely). `evaluateWhen`'s `maxDepth` case does not
+ * itself inspect `axis`/`ptType` (see its own doc comment), so supplying
+ * `diagramHasFold ? 2 : 1` as `WhenContext.maxDepth` is sufficient: a
+ * user-authored deck's DATA tree only ever gets deeper than 1 through the
+ * text pane's Tab/"Add Bullet" (the SAME folding `collectFoldedDescendants`
+ * already detects), so "does maxDepth exceed 1" and "does ANY item fold a
+ * descendant anywhere in the diagram" are the same question for this
+ * corpus - verified directly (`scan-txanchor.ts`, not merely assumed).
+ *
+ * Corpus coverage (round 17, `scan-txanchor.ts` against all 134 `lin`/
+ * `snake` fixtures): resolves for the common single-role `lin`/`snake`
+ * families (`basic-process`, `vertical-process`, `basic-block-list`, and
+ * others sharing that shape) with ZERO mismatches against the cached
+ * anchor. Returns `undefined` (the caller then falls back to the existing,
+ * unconditional line-spacing behaviour) for the ~107/134 fixtures whose
+ * item template is a COMPOSITE (an image+caption composite, or a
+ * multi-role list layout with a separate `parentText`/`childText`
+ * sub-role) - `itemNode()` returns the composite/role wrapper, not the
+ * sub-node that actually carries the `tx` alg, a materially different,
+ * NOT-yet-solved problem (see the round 17 successor doc section).
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/** ECMA-376 `ST_VerticalAlignment`. */
+export type TxAnchorVert = 't' | 'mid' | 'b';
+/** The two `tx`-alg parameters this module resolves. */
+export interface ItemTxAnchor {
+    /** This item's OWN paragraph anchor, when it does NOT fold a descendant. */
+    anchorVert: TxAnchorVert;
+    /** This item's overall anchor when it DOES fold a descendant paragraph into the same box. */
+    anchorVertCh: TxAnchorVert;
+}
+/**
+ * Resolve `itemTemplate`'s effective `txAnchorVert`/`txAnchorVertCh`, or
+ * `undefined` when its `tx` algorithm cannot be found at all (a composite
+ * or multi-role item template - see the module doc comment) or its
+ * `choose` is not decidable with the given `context`.
+ *
+ * @param diagramHasFold - Whether ANY item in the whole diagram folds a
+ *   descendant paragraph into its own box (the DATA tree's own maxDepth
+ *   exceeding 1 - see the module doc comment for why this is the correct
+ *   value to feed `WhenContext.maxDepth` for a `tx` alg's `choose`).
+ */
+export declare function resolveItemTxAnchor(view: RawXmlView<unknown>, itemTemplate: DiagramLayoutNode | undefined, nodeCount: number, diagramHasFold: boolean): ItemTxAnchor | undefined;
+/**
+ * Whether ONE item is top-anchored, given the diagram's resolved
+ * {@link ItemTxAnchor} (`undefined` when unresolved - the common case for
+ * composite/multi-role item templates) and whether THIS item folds a
+ * descendant paragraph into its own box (selects `anchorVertCh` over
+ * `anchorVert` - see the module doc comment).
+ */
+export declare function isItemTopAnchored(anchor: ItemTxAnchor | undefined, hasDescendants: boolean): boolean;
+//# sourceMappingURL=smartart-layout-item-tx-anchor.d.ts.map

package/dist/diagram/layout/smartart-layout-item-tx-anchor.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-item-tx-anchor.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-item-tx-anchor.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwEG;AAMH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD,uCAAuC;AACvC,MAAM,MAAM,YAAY,GAAG,GAAG,GAAG,KAAK,GAAG,GAAG,CAAC;AAO7C,wDAAwD;AACxD,MAAM,WAAW,YAAY;IAC5B,4EAA4E;IAC5E,UAAU,EAAE,YAAY,CAAC;IACzB,6FAA6F;IAC7F,YAAY,EAAE,YAAY,CAAC;CAC3B;AA0DD;;;;;;;;;;GAUG;AACH,wBAAgB,mBAAmB,CAClC,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,YAAY,EAAE,iBAAiB,GAAG,SAAS,EAC3C,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,OAAO,GACrB,YAAY,GAAG,SAAS,CAe1B;AAED;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAChC,MAAM,EAAE,YAAY,GAAG,SAAS,EAChC,cAAc,EAAE,OAAO,GACrB,OAAO,CAKT"}

package/dist/diagram/layout/smartart-layout-shape-polygon.d.ts

@@ -0,0 +1,17 @@
+/**
+ * Split out of `smartart-layout-shape-preset.ts` (which was pushing past the
+ * repo's per-file line budget once `roundRectCornerInsetPx` landed): SVG
+ * polygon point-list construction for the interpreter's `polygon`-kind
+ * preset shapes. Re-exported from the split-from file so no caller's import
+ * path changes.
+ *
+ * @module smartart-layout-shape-polygon
+ */
+/**
+ * Build SVG polygon `points` for a preset geometry inscribed in the box
+ * `[x, y, w, h]`. Falls back to a plain rectangle outline (4 corners) for an
+ * unrecognised polygon preset, so the item still renders something
+ * reasonable rather than nothing.
+ */
+export declare function presetPolygonPoints(preset: string | undefined, x: number, y: number, w: number, h: number): string;
+//# sourceMappingURL=smartart-layout-shape-polygon.d.ts.map

package/dist/diagram/layout/smartart-layout-shape-polygon.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-shape-polygon.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-shape-polygon.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAIH;;;;;GAKG;AACH,wBAAgB,mBAAmB,CAClC,MAAM,EAAE,MAAM,GAAG,SAAS,EAC1B,CAAC,EAAE,MAAM,EACT,CAAC,EAAE,MAAM,EACT,CAAC,EAAE,MAAM,EACT,CAAC,EAAE,MAAM,GACP,MAAM,CA4CR"}

package/dist/diagram/layout/smartart-layout-shape-preset.d.ts

@@ -0,0 +1,127 @@
+/**
+ * Map a layoutNode's `dgm:shape` preset geometry
+ * (`DiagramLayoutNodeShape.presetGeometry`) to the coarse render kind
+ * (rect/circle/polygon) an arranger's per-point item builder should use,
+ * instead of the arranger hardcoding one shape for its whole family.
+ *
+ * Scope: this is a coarse mapping onto the interpreter's three existing
+ * `RenderedNode` kinds, not a full DrawingML preset-geometry renderer.
+ * Preset names outside the recognised sets fall back to the arranger's own
+ * default, so an unmapped preset degrades to the pre-existing behaviour
+ * rather than rendering something wrong.
+ *
+ * @module smartart-layout-shape-preset
+ */
+import type { DiagramLayoutNode, DiagramLayoutNodeShape } from '../model/index.js';
+export { presetPolygonPoints } from './smartart-layout-shape-polygon.js';
+export type PresetRenderKind = 'rect' | 'circle' | 'polygon';
+/**
+ * Resolve which coarse kind a layoutNode's own `dgm:shape` override should
+ * render as. Returns `fallback` (the arranger's hardcoded family default)
+ * when the node carries no shape override, or an unrecognised preset name.
+ */
+export declare function resolvePresetRenderKind(shape: DiagramLayoutNodeShape | undefined, fallback: PresetRenderKind): PresetRenderKind;
+/**
+ * Depth-first search through an item template's subtree for the shape a
+ * merged per-item COMPOSITE box should carry, when the top-level item
+ * itself declares no `dgm:shape` of its own (a bare `composite`/`tx`
+ * wrapper - e.g. "Basic Chevron Process"'s item template is a `composite`
+ * with no shape, whose CHILDREN are a decorative background node plus
+ * separate text sub-nodes).
+ *
+ * Three candidates are tracked in ONE walk, in priority order:
+ *
+ * 1. **The first PRESENTED (`presOf` non-empty) node's own VISIBLE shape**
+ *    (`isTextRoleNode`; a `dgm:shape` that is not `hideGeom` - a hidden shape
+ *    exists only to size text, never to be painted, so it can never be the
+ *    merged box's real preset). Measured against "Icon Circle Label List"
+ *    and "Meet the Team Card": both wrap a `composite` item template around
+ *    TWO decorative `sp`-alg accents with EMPTY `presOf` (a circular
+ *    icon/photo backdrop, e.g. `iconBgRect`/`bgPill`, BOTH `ellipse`/
+ *    `roundRect`) plus the REAL text role (`textRect`/`nameText`, `alg="tx"`,
+ *    `presOf axis="self"`) which declares its OWN, DIFFERENT `dgm:shape
+ *    type="rect"` - the cached drawing's merged shape is `rect` (the text
+ *    role's own shape), not the decorative accent's `ellipse`/`roundRect`.
+ *    Preferring the accent unconditionally (the pre-existing rule below)
+ *    mismatched both. Also covers "Basic Chevron Process" (`parTx`, `alg=
+ *    "tx"`, `chevron`), "Detailed Process" (`bgRect`, `alg="sp"` but `presOf
+ *    axis="self"` - a genuinely presented DECORATIVE node, `roundRect`), and
+ *    "Process Arrows" (`childTextVisible`, `alg="sp"` with `presOf
+ *    axis="des"`, `rightArrow`/`leftArrow`): an `sp`-alg node CAN carry real
+ *    presented text when PowerPoint merges an accent shape with a point's
+ *    text into one visual, so `isTextRoleNode` does NOT exclude `sp` by
+ *    algorithm type the way `smartart-layout-item-font-role.ts`'s font-role
+ *    search does - excluding it here regressed "Process Arrows" from a
+ *    correct 5-box per-role split to a folded 3-box merge, because its
+ *    per-role split code (`smartart-layout-interpreter-item-role-stack.ts`,
+ *    Track S) keys off the MERGED kind this function feeds and only
+ *    recognises `rect`(-mapped) kinds, not the `circle` kind `parentText`'s
+ *    own (correctly self-presented, but geometrically nested INSIDE the
+ *    `rightArrow`, not the item's outer box) `ellipse` would otherwise win.
+ * 2. **The first `sp`-alg shape** (a decorative background/accent with EMPTY
+ *    `presOf`, e.g. a chevron/round2SameRect/roundRect card). Measured
+ *    against "Vertical Action List" (`round2SameRect`) - rule 1 only ever
+ *    pre-empts this when a DIFFERENT, presented node's shape disagrees; here
+ *    `bgOutline`'s own `presOf` is empty and `parentText`'s self-presented
+ *    shape happens to already agree (`round2SameRect` too), so which rule
+ *    matches is unobservable, but rule 1 is not guaranteed to fire when
+ *    nothing in the subtree is presented at all (a defensive fallback).
+ * 3. **The first ANY declared shape** (e.g. a hierarchy item's `rootText`,
+ *    `alg="tx"`, which has no separate decorative sibling at all, and whose
+ *    own shape is not `hideGeom` either - rule 1 already covers the visible
+ *    case, so this only ever adds a `hideGeom` shape back in as an
+ *    absolute last resort, keeping the pre-existing "return SOMETHING
+ *    rather than the arranger's generic fallback" behaviour for a subtree
+ *    where every declared shape happens to be `hideGeom`).
+ *
+ * `undefined` when nothing in the subtree declares a shape at all.
+ *
+ * `alg="conn"` nodes are EXCLUDED from every search - measured against
+ * "Text Cycle": its `cycle` arranger's children parse in the order `dummy`
+ * (`alg="sp"`, no shape), `sibTrans` (`alg="conn"`, `dgm:shape type="conn"` -
+ * a transition-point marker, not a real DrawingML preset), THEN `node`
+ * (`alg="tx"`, the real `dgm:shape type="rect"`): `dgm:forEach`-wrapped
+ * siblings do not always parse back in raw-XML text order, so a plain
+ * "first declared shape" walk can reach the connector's marker before the
+ * genuine item preset. PowerPoint reconstructs `dsp:cxn` connector shapes
+ * separately from the data-model's own connections (see
+ * `smartart-interpreter-drawing-bridge.ts`'s module doc comment) and never
+ * merges a connector's marker into a per-item box, so `conn` can never
+ * legitimately be the answer here.
+ *
+ * Deliberately does NOT walk past a nested `composite`'s own children when
+ * that nested composite already resolved a shape at its own level (early
+ * return above for the item passed in), so a genuinely nested per-item
+ * composite-of-composites still resolves outside-in.
+ */
+export declare function findCompositeItemShape(item: DiagramLayoutNode | undefined): DiagramLayoutNodeShape | undefined;
+/**
+ * Resolve a `roundRect`-family preset's corner-radius fraction (0..1 of the
+ * shorter side) from its first (`idx=1`) `dgm:adjLst` value, or `roundRect`'s
+ * own OOXML preset-geometry default (see {@link DEFAULT_ROUND_RECT_ADJ_FRACTION})
+ * when the preset is round-rect-family but carries no adjustment, or
+ * `undefined` for a plain `rect`/other preset (no override).
+ */
+export declare function presetCornerRadiusFraction(shape: DiagramLayoutNodeShape | undefined): number | undefined;
+/**
+ * A `roundRect`-family item's TEXT box is inset from its own straight-edge
+ * `w`/`h` by more than `bodyPr`'s margins alone: PowerPoint additionally
+ * pulls the usable text rectangle in from each side by the rounded corner's
+ * own radius, scaled by `1 - cos(45deg)` (the distance from the straight
+ * edge to the 45-degree point of the corner arc) - the geometry that keeps
+ * text from being clipped by the curve. Confirmed directly from the cached
+ * `dsp:txXfrm` (the real per-shape text frame) against `dsp:spPr`'s own
+ * `a:xfrm` (the shape's straight-edge box) across the `lin`/`snake` gallery
+ * corpus: every `roundRect`-family item's txXfrm is inset by EXACTLY
+ * `presetCornerRadiusFraction(shape) * min(w, h) * CORNER_ARC_INSET_FACTOR`
+ * on all four sides (e.g. `basic-process--hier5.pptx`'s 170.75x102.45pt
+ * roundRect, adj=10%: radius = 0.10 * 102.45 = 10.245pt, inset = 10.245 *
+ * 0.292893 = 3.00pt, matching the cached txXfrm's own 3.00pt inset exactly;
+ * reproduced across a dozen other differently-sized roundRect fixtures with
+ * zero deviation beyond rounding). A plain `rect` (no corner radius) needs
+ * no such inset, confirmed by the SAME corpus showing an EXACT ZERO
+ * txXfrm/spPr difference for every `rect`-preset item. Returns 0 for a
+ * non-round-rect preset (undefined `presetCornerRadiusFraction`).
+ */
+export declare function roundRectCornerInsetPx(shape: DiagramLayoutNodeShape | undefined, widthPx: number, heightPx: number): number;
+//# sourceMappingURL=smartart-layout-shape-preset.d.ts.map

package/dist/diagram/layout/smartart-layout-shape-preset.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-shape-preset.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-shape-preset.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,sBAAsB,EAAE,MAAM,UAAU,CAAC;AAE1E,OAAO,EAAE,mBAAmB,EAAE,MAAM,iCAAiC,CAAC;AAEtE,MAAM,MAAM,gBAAgB,GAAG,MAAM,GAAG,QAAQ,GAAG,SAAS,CAAC;AA6B7D;;;;GAIG;AACH,wBAAgB,uBAAuB,CACtC,KAAK,EAAE,sBAAsB,GAAG,SAAS,EACzC,QAAQ,EAAE,gBAAgB,GACxB,gBAAgB,CAelB;AAsBD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwEG;AACH,wBAAgB,sBAAsB,CACrC,IAAI,EAAE,iBAAiB,GAAG,SAAS,GACjC,sBAAsB,GAAG,SAAS,CAqCpC;AAuBD;;;;;;GAMG;AACH,wBAAgB,0BAA0B,CACzC,KAAK,EAAE,sBAAsB,GAAG,SAAS,GACvC,MAAM,GAAG,SAAS,CAcpB;AAKD;;;;;;;;;;;;;;;;;;;GAmBG;AACH,wBAAgB,sBAAsB,CACrC,KAAK,EAAE,sBAAsB,GAAG,SAAS,EACzC,OAAO,EAAE,MAAM,EACf,QAAQ,EAAE,MAAM,GACd,MAAM,CAMR"}