ooxml-core 1.1.0 → 1.2.1

package/dist/diagram/layout/smartart-layout-interpreter-linear-content-size.d.ts

@@ -0,0 +1,42 @@
+/**
+ * SmartArt DiagramML interpreter - content-sized main-axis extents for `lin`.
+ *
+ * ECMA-376 21.4.7.6: a `dgm:constr type="h"/"w"` declaring `val="INF"` (no
+ * limit) means the item's own extent along that axis comes from its
+ * CONTENT, not a declared/divided slot - the one place `arrangeLinear`'s
+ * otherwise-uniform per-item `mainExtent` is genuinely DATA-DEPENDENT.
+ * "Vertical Box List"'s own item template (`parentLin`) declares exactly
+ * this: `<dgm:constr type="h" for="ch" forName="parentLin" val="INF"/>`
+ * (round 24 - `smartart-constraint-rules.ts` already parses `val="INF"` to
+ * `Number.POSITIVE_INFINITY`, but `resolveConstraint`'s own `finite()` guard
+ * silently drops it, so this needs its OWN raw-constraint detection, not a
+ * `resolveConstraint` call).
+ *
+ * Scoped to VERTICAL flow only this round (the one fixture that declares
+ * this pattern is a vertical list) - `arrangeLinear` guards the call with
+ * `!horizontal`, so a future horizontal fixture using this same pattern
+ * falls back to the existing uniform-slot behaviour rather than reaching
+ * unverified code.
+ */
+import type { FontAdvanceTable } from '../../text/font-metrics/font-advance-widths.generated';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+/**
+ * True when the arranger declares `itemRole`'s own `mainAxisType` extent as
+ * a LITERAL `val="INF"` (no reference at all - a genuine "no limit, size to
+ * content" declaration). `undefined` when nothing is declared at all (the
+ * far more common case) is a DIFFERENT, unrelated situation the caller's
+ * existing uniform-slot fallback already handles correctly - only an
+ * EXPLICIT `INF` engages this module.
+ */
+export declare function isMainAxisContentSized(index: ConstraintIndex, arrangerRole: string, itemRole: string, mainAxisType: 'w' | 'h'): boolean;
+/**
+ * Each item's own natural main-axis (vertical) extent, in pixels: a single
+ * wrapped text block at `fontSizePx` within `crossExtentPx` (the item's own,
+ * still-uniform cross-axis width), plus its role's own real margins and any
+ * `roundRect`-family corner inset. When the summed extents (plus
+ * `(n-1)*gap`) exceed `usableMain`, ECMA's own fallback applies: scale EVERY
+ * extent down by the SAME factor so the set exactly fills `usableMain` -
+ * "the declared/content extent wins unless it would overflow the box."
+ */
+export declare function resolveContentSizedExtents(texts: readonly string[], crossExtentPx: number, fontSizePx: number, table: FontAdvanceTable, lineSpacingFactor: number, fontRole: string, index: ConstraintIndex, cornerInsetPx: number, usableMain: number, gap: number): number[];
+//# sourceMappingURL=smartart-layout-interpreter-linear-content-size.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-linear-content-size.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-linear-content-size.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-linear-content-size.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,uDAAuD,CAAC;AAE9F,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAMpE;;;;;;;GAOG;AACH,wBAAgB,sBAAsB,CACrC,KAAK,EAAE,eAAe,EACtB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,MAAM,EAChB,YAAY,EAAE,GAAG,GAAG,GAAG,GACrB,OAAO,CAGT;AAED;;;;;;;;GAQG;AACH,wBAAgB,0BAA0B,CACzC,KAAK,EAAE,SAAS,MAAM,EAAE,EACxB,aAAa,EAAE,MAAM,EACrB,UAAU,EAAE,MAAM,EAClB,KAAK,EAAE,gBAAgB,EACvB,iBAAiB,EAAE,MAAM,EACzB,QAAQ,EAAE,MAAM,EAChB,KAAK,EAAE,eAAe,EACtB,aAAa,EAAE,MAAM,EACrB,UAAU,EAAE,MAAM,EAClB,GAAG,EAAE,MAAM,GACT,MAAM,EAAE,CAuBV"}

package/dist/diagram/layout/smartart-layout-interpreter-linear-item-aspect.d.ts

@@ -0,0 +1,94 @@
+/**
+ * SmartArt DiagramML interpreter - `lin` arranger item aspect resolution.
+ *
+ * Split out of `smartart-layout-interpreter-linear.ts` (the repo's per-file
+ * line budget): `itemAspect`, the item's own height/width ratio as declared
+ * by the OUTER arranger (as opposed to the item's own self-scoped `h`/`w`,
+ * a separate fallback `arrangeLinear` applies itself).
+ */
+import type { DiagramNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { ArrangementPlan, FlowDirection } from './smartart-layout-interpreter-model.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/**
+ * Item aspect (height / width), resolved ONLY from the ARRANGER's own
+ * `constrLst` (`for="ch" forName="<item role>"` / `ptType="<item ptType>"`),
+ * via {@link resolveConstraintDeclaredBy} - the item's OWN self-scoped
+ * `h`/`w` is a SEPARATE fallback the caller applies itself (`naturalAspect`
+ * in `arrangeLinear`), not considered here.
+ *
+ * Round 25: a same-axis "inherit the arranger's own dimension" declaration
+ * (`<dgm:constr type="h" for="ch" forName="linNode" refType="h"/>`, no
+ * cross-axis reference or literal factor of its own - "Vertical Bracket
+ * List"'s `linNode`) resolves to a spurious 1:1 "aspect" via this same
+ * code path (both axes bottom out at the root's own implicit `w=h=1`) and
+ * squashes a genuinely WIDE item template into a narrow square. A dedicated
+ * fix EXCLUDING that pattern (unconditionally, for EVERY item) was
+ * implemented, measured against the full 227-fixture corpus, and found to
+ * REGRESS WIDELY (dozens of OTHER fixtures' FONT/GEOM values moved
+ * measurably further from cached - e.g. `alternating-flow--hier5.pptx`
+ * 44.0px->74.7px against a 37.3px cached target, `bullet-timeline--
+ * hier5.pptx`'s `maxGeomDelta` 34%->88% - the SAME degenerate 1:1
+ * resolution this fix targeted is, empirically, load-bearing for many
+ * OTHER fixtures' correct box shape, not merely "coincidentally correct"
+ * for them). REVERTED - see the round-25 successor doc's own section for
+ * the measured regression numbers and the `smartart-layout-interpreter-
+ * linear-item-aspect.ts` file that attempt added (deleted along with the
+ * revert - this file is a DIFFERENT, round-27 extraction, not a resurrection
+ * of that one). Round 25's own doc comment asked for a NARROWER trigger,
+ * "possibly conditioned on the item template's own nested arranger being a
+ * DIFFERENT-orientation `lin`" - round 27 built exactly that signal for the
+ * SIBLING column-role-split mechanism (`smartart-layout-interpreter-item-
+ * role-orientation.ts`'s `isColumnWrapper`: an EXPLICIT `linDir="fromL"|
+ * "fromR"` wrapper, 2+ text roles, every one a genuinely plain rect - see
+ * that function's own doc comment for why the plain-rect guard is load-
+ * bearing here too, not just for the role-split geometry: "Vertical Block
+ * List" shares "Vertical Bracket List"'s exact wrapper shape but its
+ * descendant role is a rotated decorative connector, not a real column, and
+ * WOULD have wrongly widened this item's own box under a check that only
+ * looked at `linDir`) and reuses it here: the exemption now applies ONLY
+ * when `item` itself is a genuine column wrapper (measured corpus-wide:
+ * `vertical-bracket-list` is the ONLY fixture in the gallery whose item
+ * template is BOTH a same-axis-inherit candidate AND a genuine column
+ * wrapper - the intersection that regressed 25 fixtures under round 25's
+ * unconditional exclusion is empty here).
+ */
+export declare function itemAspect(view: RawXmlView<unknown>, plan: ArrangementPlan, index: ConstraintIndex, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): number | undefined;
+/**
+ * The item's CROSS-axis extent, as a literal fraction of the diagram's own
+ * width, for a VERTICAL `lin` arranger only - the counterpart to
+ * {@link itemAspect} for the "Basic Block List"/"Vertical Block List"/
+ * "Pyramid List" family of writer-fabricated (and matching genuine
+ * PowerPoint `list1.xml`-style) definitions:
+ *
+ * ```xml
+ * <dgm:constr type="w" for="ch" forName="node" refType="w"/>
+ * <dgm:constr type="h" for="ch" forName="node" refType="w" refFor="ch" refForName="node" fact="0.3"/>
+ * ```
+ *
+ * i.e. the item's width is declared OUTRIGHT as a fraction of the diagram's
+ * own width (here 1, the whole box), and height is a further fraction OF
+ * that same width. `itemAspect` resolves this same pair down to a single
+ * `h/w` RATIO (0.3) and `arrangeLinear` applies it as `mainExtent * aspect`
+ * - correct for a HORIZONTAL arranger (main axis `w`, cross axis `h`: cross
+ * = main * (h/w)), but wrong for a VERTICAL one: there `mainExtent` is
+ * already the (fitted) HEIGHT, so multiplying it by the SAME h/w fraction
+ * again compounds it, producing a box narrower than tall (measured: a
+ * 600x340 box, 3 nodes, this exact writer definition, gave 29x97 boxes
+ * instead of near-full-width ~584-600 x ~97-104 rows). The item's width was
+ * never meant to be DERIVED from the fitted main-axis height at all - it is
+ * an independent, literal fraction of the box's own width, which this
+ * resolves directly instead.
+ *
+ * Gated on the RAW `h` declaration's own `referenceType` being exactly `w`
+ * (a genuine geometric "height is a fraction of width" relationship) so this
+ * never engages for a role whose "aspect" is actually a `primFontSz`-derived
+ * ratio with no real geometric meaning (`itemAspect`'s own doc comment: e.g.
+ * `vertical-bullet-list--hier5.pptx`'s `parentText`, where the existing
+ * always-multiply-then-clamp-to-`usableCross` behaviour is load-bearing and
+ * must be left alone).
+ */
+export declare function itemCrossAxisFraction(plan: ArrangementPlan, index: ConstraintIndex): number | undefined;
+/** Order the data nodes for the resolved flow direction. */
+export declare function ordered(nodes: DiagramNode[], flow: FlowDirection): DiagramNode[];
+//# sourceMappingURL=smartart-layout-interpreter-linear-item-aspect.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-linear-item-aspect.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-linear-item-aspect.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-linear-item-aspect.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AAKnE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAGpE,OAAO,KAAK,EAAE,eAAe,EAAE,aAAa,EAAE,MAAM,qCAAqC,CAAC;AAE1F,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0CG;AACH,wBAAgB,UAAU,CACzB,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,eAAe,EACrB,KAAK,EAAE,eAAe,EACtB,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,MAAM,GAAG,SAAS,CAgBpB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,wBAAgB,qBAAqB,CACpC,IAAI,EAAE,eAAe,EACrB,KAAK,EAAE,eAAe,GACpB,MAAM,GAAG,SAAS,CAapB;AAED,4DAA4D;AAC5D,wBAAgB,OAAO,CAAC,KAAK,EAAE,WAAW,EAAE,EAAE,IAAI,EAAE,aAAa,GAAG,WAAW,EAAE,CAEhF"}

package/dist/diagram/layout/smartart-layout-interpreter-linear-main-axis.d.ts

@@ -0,0 +1,17 @@
+/**
+ * SmartArt DiagramML interpreter - `lin` main-axis extent/gap resolution.
+ *
+ * Split out of `smartart-layout-interpreter-linear.ts` (the file-size
+ * budget): resolves the UNIFORM per-item main-axis extent and the gap
+ * between consecutive items that `arrangeLinear` divides `usableMain` into,
+ * before any per-item (content-sized) override applies - see
+ * `smartart-layout-interpreter-linear-content-size.ts` for that.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+/** Resolved main-axis item extent plus the gap between consecutive items. */
+export declare function resolveMainAxisLayout(constraints: DiagramLayoutNode['constraints'], index: ConstraintIndex, role: string, mainAxisType: 'w' | 'h', ceilingPx: number, usableMain: number, begPad: number, endPad: number, n: number, clampRatio: (value: number) => number): {
+    mainExtent: number;
+    gap: number;
+};
+//# sourceMappingURL=smartart-layout-interpreter-linear-main-axis.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-linear-main-axis.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-linear-main-axis.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-linear-main-axis.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAGlD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AA2CpE,6EAA6E;AAC7E,wBAAgB,qBAAqB,CACpC,WAAW,EAAE,iBAAiB,CAAC,aAAa,CAAC,EAC7C,KAAK,EAAE,eAAe,EACtB,IAAI,EAAE,MAAM,EACZ,YAAY,EAAE,GAAG,GAAG,GAAG,EACvB,SAAS,EAAE,MAAM,EACjB,UAAU,EAAE,MAAM,EAClB,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,CAAC,EAAE,MAAM,EACT,UAAU,EAAE,CAAC,KAAK,EAAE,MAAM,KAAK,MAAM,GACnC;IAAE,UAAU,EAAE,MAAM,CAAC;IAAC,GAAG,EAAE,MAAM,CAAA;CAAE,CAwBrC"}

package/dist/diagram/layout/smartart-layout-interpreter-linear-shared.d.ts

@@ -0,0 +1,21 @@
+/**
+ * SmartArt DiagramML interpreter - constant shared by the `lin` (
+ * `smartart-layout-interpreter-linear.ts`) and `snake` (
+ * `smartart-layout-interpreter-snake.ts`) arrangers. Split into its own module
+ * purely to avoid a circular import between the two (both need it; neither
+ * should import the other).
+ */
+/**
+ * No margin around the arrangement's outer edge by default: measured against
+ * TWO independent gallery fixtures with no declared `begPad`/`endPad` (
+ * `basic-process--flat3.pptx`: item x=0/main-axis-flush against a 0-local-x
+ * container edge; `basic-block-list--flat3.pptx`, a `snake` arrangement: the
+ * whole grid's bounding box spans 0.3%-0.2% of the frame from every edge,
+ * i.e. touching it), PowerPoint's cached drawing reserves NO fixed-pixel
+ * margin around a `lin`/`snake` arrangement's own bounding box. A previous
+ * hardcoded `INSET = 6` was an unmeasured guess that this fixture evidence
+ * disproves; `begPad`/`endPad`/`sibSp` are the ONLY real DiagramML sources of
+ * spacing, and they default to `0` on their own.
+ */
+export declare const INSET = 0;
+//# sourceMappingURL=smartart-layout-interpreter-linear-shared.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-linear-shared.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-linear-shared.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-linear-shared.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,KAAK,IAAI,CAAC"}

package/dist/diagram/layout/smartart-layout-interpreter-linear-table.d.ts

@@ -0,0 +1,76 @@
+/**
+ * SmartArt DiagramML interpreter - recursive `lin`-in-`lin` "table" item
+ * template ("Table Hierarchy"/"Architecture Layout").
+ *
+ * Both built-in layouts share one construct (COM-verified: their `layout1
+ * .xml`s differ only by `uniqueId`/title and `vertOne`'s own direction
+ * choose gaining a third `fromB` branch): a per-top-level-point item
+ * template (`vertOne`, reached through a genuine `axis="ch" ptType="node"`
+ * `dgm:forEach`) that is ITSELF a vertical `lin` wrapping a text label
+ * (`txOne`) plus a horizontal `lin` (`horzOne`) which `forEach`-wraps the
+ * SAME shape one generation deeper (`vertTwo`, then `vertThree`, then
+ * `vertFour`, which self-recurses via a `forEach ref="repeat"` back onto
+ * its own shape for any depth beyond 4 - the parsed layout tree does not
+ * expand that self-reference, so the STATIC template caps at 4 named
+ * generations, but the REAL data-driven recursion here is unbounded,
+ * walking `childrenOf` instead of the template).
+ *
+ * `discoverArrangement` (`smartart-layout-interpreter-model.ts`) resolves
+ * `plan.node` directly to `vertOne` - not a wrapping top-level arranger -
+ * so `selectArrangedNodes` hands `arrangeLinear` the WHOLE flattened tree
+ * (every generation) as one list, with no signal left about which node is
+ * whose parent or how deep it sits. The standard `arrangeLinear` body
+ * (single row/column, one uniform per-item slot) cannot render that: this
+ * module replaces it for exactly this construct, using `childrenOf` (an
+ * arranger-level input already threaded in for text-folding, see
+ * `arrangeLinear`'s own `descendantTextsFor`) to rebuild the tree and lay
+ * out a real generation grid instead.
+ *
+ * Ground truth (`table-hierarchy--{flat3,hier5,hier8}.pptx`'s cached
+ * `dsp:drawing`): every "node"-type box across the WHOLE tree shares ONE
+ * row height (`<dgm:constr type="h" for="des" ptType="node" op="equ"/>`);
+ * a node's own children split ITS OWN column width, never the full
+ * diagram width again (an only-child stays exactly as wide as its
+ * parent's column). Neither the row gap (`parTransN`, sized via a
+ * cross-axis `w`-referencing `fact`, not a `sibSp`/`sp` constraint type)
+ * nor the column gap (`sibSpaceN`, a `fact`-chained but NOT
+ * `sibSp`/`sp`-typed reference either) resolves to a clean closed-form
+ * ratio from the declared constraints alone (measured against all three
+ * fixtures: the implied gap/extent ratio varies 0.04-0.10 depending on
+ * generation/column count, not a single constant) - both fall back to
+ * this interpreter's own existing generic default
+ * ({@link DEFAULT_GAP_RATIO}, `smartart-layout-interpreter-linear-main-
+ * axis.ts`'s `resolveMainAxisLayout` uses the identical `0.25` when no
+ * `sibSp`/decorative-role signal is found), rather than a construct-
+ * specific number invented from a single COM sample - the failure mode a
+ * previous attempt at this exact construct measured as a regression.
+ */
+import type { DiagramLayoutNode, DiagramNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { ArrangementPlan } from './smartart-layout-interpreter-model.js';
+import type { BoundingBox, SmartArtLayoutResult } from './smartart-layout-types.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/**
+ * Detect the recursive lin-in-lin table item template rooted at `node` - see
+ * this module's doc comment for the exact shape. Deliberately narrow (every
+ * one of these checks must hold): `node` itself must be a genuine per-point
+ * item template (reached through an `axis="ch" ptType="node"` `dgm:forEach`),
+ * must be a `lin`, must carry a self-presenting text label child, AND must
+ * carry a nested `lin` "row" child whose OWN child is reached through the
+ * SAME `axis="ch" ptType="node"` shape one generation deeper. Measured to
+ * correctly exclude `sub-step-process--hier5.pptx` (a superficially similar
+ * `lin`-wrapping-`lin` shape whose nested `lin`'s `forEachOrigin.axis` is
+ * `self`, not `ch` - a once-per-point decoration, not a recursive template).
+ */
+export declare function isRecursiveTableItemTemplate(view: RawXmlView<unknown>, node: DiagramLayoutNode, presLayoutVars: DiagramPresLayoutVars | undefined): boolean;
+/**
+ * Lay out the recursive table construct: one row PER GENERATION present in
+ * the real data tree (uniform height, a shared gap ratio between rows), each
+ * node's own real children (via `childrenOf`) splitting ITS OWN column width
+ * recursively. `nodes` is the whole flattened tree (every generation, as
+ * `selectArrangedNodes` hands `arrangeLinear` for this construct); `box`'s
+ * origin is always `(0, 0)` (see `BoundingBox`'s own doc comment).
+ */
+export declare function arrangeRecursiveTable(view: RawXmlView<unknown>, plan: ArrangementPlan, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, index: ConstraintIndex, childrenOf: Map<string, DiagramNode[]>, fontName: string | undefined, presLayoutVars: DiagramPresLayoutVars | undefined): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-layout-interpreter-linear-table.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-linear-table.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-linear-table.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-linear-table.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8CG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,WAAW,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtF,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAEpE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAK3E,OAAO,KAAK,EAAE,WAAW,EAAgB,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AAC/F,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAsCxD;;;;;;;;;;;GAWG;AACH,wBAAgB,4BAA4B,CAC3C,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,iBAAiB,EACvB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,OAAO,CAcT;AAgBD;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CACpC,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,eAAe,EACrB,KAAK,EAAE,WAAW,EAAE,EACpB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,SAAS,EAAE,MAAM,EACjB,KAAK,EAAE,eAAe,EACtB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,EACtC,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,oBAAoB,CAsHtB"}

package/dist/diagram/layout/smartart-layout-interpreter-linear.d.ts

@@ -0,0 +1,20 @@
+/**
+ * SmartArt DiagramML interpreter - linear (`lin`) arranger.
+ *
+ * `lin` lays the data-model points out in a single row or column, honouring
+ * `linDir` and the scalar `sibSp`/`begPad`/`endPad`/`w`/`h` constraints,
+ * producing fully-styled rect view-models. Pure geometry; no framework code.
+ * The `snake` algorithm (a boustrophedon grid) is a sibling module,
+ * `smartart-layout-interpreter-snake.ts`, re-exported below so no caller's
+ * import path changes.
+ */
+import type { DiagramNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { ArrangementPlan, FlowDirection } from './smartart-layout-interpreter-model.js';
+import type { BoundingBox, SmartArtLayoutResult } from './smartart-layout-types.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+export { arrangeSnake } from './smartart-layout-interpreter-snake.js';
+/** Execute the `lin` algorithm: a single row/column honouring constraints. */
+export declare function arrangeLinear(view: RawXmlView<unknown>, plan: ArrangementPlan, flow: FlowDirection, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, index?: ConstraintIndex, childrenOf?: Map<string, DiagramNode[]>, fontName?: string, presLayoutVars?: DiagramPresLayoutVars): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-layout-interpreter-linear.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-linear.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-linear.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-linear.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACnE,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AAMtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAkBpE,OAAO,KAAK,EAAE,eAAe,EAAE,aAAa,EAAE,MAAM,qCAAqC,CAAC;AAY1F,OAAO,KAAK,EAAE,WAAW,EAAgB,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AAE/F,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD,OAAO,EAAE,YAAY,EAAE,MAAM,qCAAqC,CAAC;AAEnE,8EAA8E;AAC9E,wBAAgB,aAAa,CAC5B,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,eAAe,EACrB,IAAI,EAAE,aAAa,EACnB,KAAK,EAAE,WAAW,EAAE,EACpB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,SAAS,EAAE,MAAM,EACjB,KAAK,GAAE,eAAwC,EAC/C,UAAU,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,EACvC,QAAQ,CAAC,EAAE,MAAM,EACjB,cAAc,CAAC,EAAE,qBAAqB,GACpC,oBAAoB,CA8NtB"}

package/dist/diagram/layout/smartart-layout-interpreter-model.d.ts

@@ -0,0 +1,77 @@
+/**
+ * SmartArt DiagramML interpreter - shared model helpers.
+ *
+ * These back the *real* (partial) layout interpreter that walks a parsed
+ * `dgm:layoutDef` (`DiagramLayoutDefinition`) and produces per-node
+ * geometry for the common `dgm:alg` families, instead of the legacy
+ * name-based family switch. Pure TypeScript - no framework code, no DOM.
+ *
+ * Scope / honesty: the typed layout model flattens `dgm:forEach` / `dgm:choose`
+ * wrappers when collecting nested `layoutNode`s (see
+ * `smartart-layout-definition.ts`), so this interpreter does NOT run the full
+ * recursive control-flow / constraint-reference solver. Instead it reads the
+ * primary `dgm:alg` type to pick an arrangement family (lin / cycle /
+ * hierRoot|hierChild / pyra / snake), reads the arranger's direction params
+ * (`linDir`, `stAng`, `spanAng`), applies the scalar `dgm:constr` factors
+ * (sp / sibSp / begPad / endPad and w/h aspect), and arranges the *actual
+ * data-model nodes* accordingly. When the definition contains no recognised
+ * arrangement algorithm the interpreter declines (`undefined`) and the caller
+ * keeps the legacy approximation. This module only exposes the discovery +
+ * constraint helpers.
+ */
+import type { DiagramLayoutDefinition, DiagramNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { ArrangementPlan } from './smartart-layout-interpreter-arrangement-kind.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+export { clampByRules, findConstraint, ratioConstraint, } from './smartart-layout-interpreter-constraints.js';
+export { detectPositionFamily, hasPositionGuard, } from './smartart-layout-interpreter-position-family.js';
+export { isMeaningfulAux, PRIMARY_ALG, STRUCTURAL_ARRANGEMENT_KINDS, } from './smartart-layout-interpreter-arrangement-kind.js';
+export type { ArrangementKind, ArrangementPlan, } from './smartart-layout-interpreter-arrangement-kind.js';
+/**
+ * Determine which arrangement algorithm drives the diagram.
+ *
+ * Precedence (highest first):
+ *   1. hierarchy - any `hierRoot`/`hierChild` (org-chart / tree) always wins.
+ *   2. choose - a `dgm:choose` decidable from `nodeCount` selects its branch's
+ *      structural algorithm instead of the blind first-found one (never a
+ *      pos-guarded child - see `smartart-layout-interpreter-position-
+ *      family.ts`). Undecidable chooses fall through, EXCEPT: (a) when the
+ *      node also independently qualifies as its own genuine composite (see
+ *      (3)) AND the result was found by tunnelling 2+ `dgm:layoutNode` levels
+ *      into one of its own child slots - `tunnelsPastOwnCompositeSlot`
+ *      (`smartart-layout-interpreter-choose-depth.ts`, corpus-measured,
+ *      monotonic) - the node's own composite identity wins instead; (b) when
+ *      the resolved branch's own subtree contains a REAL `hierChild`/
+ *      `hierRoot` construct - `hasHierarchyDescendant` (`smartart-layout-
+ *      interpreter-hierarchy-descendant.ts`, SESSION 24) - a shallow packing
+ *      wrapper (e.g. a labelled-hierarchy's own `hierFlow`) must not claim
+ *      the diagram away from the REAL nested hierarchy, found LATER in the
+ *      same walk but with no chance to compete once `chosen` is already set.
+ *   3. composite - a `composite` whose child slots carry positioning
+ *      constraints (maps data points into fixed slots). A passive composite
+ *      wrapper is skipped so its inner arrangement wins.
+ *   4. structural - the first `lin`/`cycle`/`pyra`/`snake` in document order.
+ *   5. conn/sp/tx - only when they are the dominant/only algorithm (no
+ *      structural or slot-mapping composite present) and carry
+ *      constraints/children.
+ *
+ * `nodeCount` (the flat data-point count) is optional; when omitted the choose
+ * step is skipped and the blind first-alg behaviour is preserved. Returns
+ * `undefined` when nothing is recognised, so the caller keeps the legacy
+ * family approximation.
+ *
+ * `presLayoutVars`, when supplied, lets a `func="var"` `dgm:if` decide its
+ * branch. Every `dgm:choose` visited also gets its declaring node's sibling
+ * position/count/depth/tree-max-depth, so `"pos"`/`"revPos"`/`"posEven"`/
+ * `"posOdd"`/`"depth"`/`"maxDepth"` are decidable here too, not just `"cnt"`/
+ * `"var"`. `flatNodes`, when supplied, additionally lets a `func="cnt"`
+ * `dgm:if` whose `@axis` needs real compound navigation decide too (ECMA-376
+ * 21.4.7.5 - see `smartart-layout-interpreter-when.ts`'s `resolveAxisCount`).
+ * Each omitted parameter keeps the coarser pre-existing fallback.
+ *
+ * ROUND 42: a `dgm:choose`-flattened branch reached through one of an
+ * ALREADY-resolved `compositeSlot`'s own named `dgm:forEach` children never
+ * sets `chosen` - see `isMappedSlotAlternative`'s own doc comment.
+ */
+export declare function discoverArrangement<R>(view: RawXmlView<R>, definition: DiagramLayoutDefinition<R>, nodeCount?: number, presLayoutVars?: DiagramPresLayoutVars, flatNodes?: DiagramNode[]): ArrangementPlan<R> | undefined;
+export { algorithmParam, type FlowDirection, itemNode, numericParam, resolveFlowDirection, } from './smartart-layout-interpreter-flow-direction.js';
+//# sourceMappingURL=smartart-layout-interpreter-model.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-model.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-model.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-model.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH,OAAO,KAAK,EACX,uBAAuB,EAEvB,WAAW,EACX,qBAAqB,EACrB,MAAM,UAAU,CAAC;AAMlB,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,gDAAgD,CAAC;AAWtF,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAIxD,OAAO,EACN,YAAY,EACZ,cAAc,EACd,eAAe,GACf,MAAM,2CAA2C,CAAC;AACnD,OAAO,EACN,oBAAoB,EACpB,gBAAgB,GAChB,MAAM,+CAA+C,CAAC;AACvD,OAAO,EACN,eAAe,EACf,WAAW,EACX,4BAA4B,GAC5B,MAAM,gDAAgD,CAAC;AACxD,YAAY,EACX,eAAe,EACf,eAAe,GACf,MAAM,gDAAgD,CAAC;AAExD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AACH,wBAAgB,mBAAmB,CAAC,CAAC,EACpC,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,UAAU,EAAE,uBAAuB,CAAC,CAAC,CAAC,EACtC,SAAS,CAAC,EAAE,MAAM,EAClB,cAAc,CAAC,EAAE,qBAAqB,EACtC,SAAS,CAAC,EAAE,WAAW,EAAE,GACvB,eAAe,CAAC,CAAC,CAAC,GAAG,SAAS,CA4HhC;AAKD,OAAO,EACN,cAAc,EACd,KAAK,aAAa,EAClB,QAAQ,EACR,YAAY,EACZ,oBAAoB,GACpB,MAAM,8CAA8C,CAAC"}

package/dist/diagram/layout/smartart-layout-interpreter-named-rules.d.ts

@@ -0,0 +1,93 @@
+/**
+ * SmartArt DiagramML interpreter - `dgm:rule/@forName` scoped overrides.
+ *
+ * ECMA-376's `CT_Rule` (`dgm:rule`) carries the same target attributes as
+ * `CT_Constraint` (`dgm:constr`): `for`, `forName`, `ptType`. `forName` names
+ * a `dgm:layoutNode` by its `name=` attribute - it is a reference to a
+ * structural ROLE in the layout tree, not to a data-point modelId. This is
+ * confirmed against a genuine PowerPoint-authored diagram: `ppt/diagrams/
+ * layout1.xml` inside `e2e/fixtures/animation-builds-color.pptx` uses
+ * `forName="node"` and `forName="sibTrans"` on `dgm:constr` elements declared
+ * on the ROOT layoutNode, each referring to one of its two differently-named
+ * CHILD layoutNodes (the per-item template and the sibling-transition
+ * spacer). A `dgm:rule` with `forName` scopes the same way: it clamps/sets a
+ * numeric field (`w` / `h` / `primFontSz`) for every data point rendered
+ * through the layoutNode of that name, uniformly. It cannot target one
+ * specific instance among repeated siblings sharing a template, because
+ * DiagramML gives the TEMPLATE a name, not the individual data points -
+ * `forName` never appeared on a `dgm:rule` in that sample, and no
+ * PowerPoint-authored layout names a data point in the first place.
+ *
+ * The previous (deleted) `smartart-layout-rule-evaluator.ts` matched
+ * `forName` against a data-point id instead, and its fallback applied an
+ * unmatched name to EVERY node rather than to none. Both were wrong against
+ * the spec and against genuine content, so this module does not reproduce
+ * that matching: it resolves by layoutNode NAME, and a name that matches
+ * nothing overrides nothing.
+ *
+ * `ruleLst` can be declared at any ancestor in the tree (the root, in the
+ * genuine sample above) and still name a descendant role, so
+ * `collectNamedRules` gathers every rule from the whole definition once; the
+ * caller looks them up by the role name it is currently rendering.
+ *
+ * Scope: wired only for the flat single-role arrangers (`lin` / `snake` /
+ * `cycle` / `pyra`), where one item layoutNode template covers every
+ * rendered point (see `smartart-layout-interpreter.ts`). `hierarchy`
+ * (parent/child roles) and `composite` (heterogeneous named children) do not
+ * reduce to one uniform role name, so applying this there would be a guess
+ * rather than a resolved reference; they keep their existing approximation.
+ * Pure geometry; no framework code, no DOM.
+ *
+ * `secFontSz` is `primFontSz`'s sibling: the same numeric-rule mechanism
+ * scaling a node's SECONDARY (subordinate) text run instead of the primary
+ * one. `applyToNode` has only one `fontSize` field to write per rendered node
+ * (the interpreter doesn't model primary/secondary as separate runs), so a
+ * `secFontSz` override would be applied identically to `primFontSz`; the
+ * distinction would only matter once a renderer starts drawing primary/
+ * secondary text as separate elements.
+ *
+ * NEITHER `primFontSz` NOR `secFontSz` is actually wired into
+ * `OVERRIDE_KEY` (see its own doc comment): per ECMA-376, a `dgm:rule` is a
+ * BOUND on the autofit algorithm's shrink search (a floor/ceiling `dgm:constr`
+ * already resolves to first), never a literal "set the font to this value"
+ * instruction the way a `w`/`h` size rule can plausibly be read as one. A
+ * PREVIOUS version of this module treated a `primFontSz` rule's `val` as a
+ * direct override and measurably broke "Vertical Bullet List"
+ * (`smartart-gallery-ground-truth.test.ts`): its arranger declares
+ * `<dgm:rule type="primFontSz" for="ch" forName="parentText" val="5"/>` as
+ * the shrink-search FLOOR (5pt, an intentionally shallow last resort, mirrored
+ * by the item's own `<dgm:rule type="h" val="INF"/>` - both are BOUNDS, not
+ * values to assign), and this module was hard-setting every rendered node's
+ * font to a literal 5, discarding `smartart-layout-item-font-size.ts`'s own
+ * properly text-measured fit entirely. That floor is now read directly by
+ * `smartart-layout-item-font-size.ts`'s own `primFontSzFloorRuleValues`
+ * (which also checks an ARRANGER-declared `for="ch" forName=<role>` rule, not
+ * only the item's own self-scoped `ruleLst`), so this module no longer needs
+ * to duplicate it.
+ */
+import type { DiagramLayoutDefinition, DiagramNumericRule } from '../model/index.js';
+import type { BoundingBox, SmartArtLayoutResult } from './smartart-layout-types.js';
+/** Depth-first collection of every `dgm:rule` anywhere in the layout tree. */
+export declare function collectNamedRules(definition: DiagramLayoutDefinition): DiagramNumericRule[];
+/** Resolved `forName`-scoped overrides for one layoutNode role. */
+export interface NamedRuleOverride {
+    /** Width, as a ratio (0..1) of the bounding box width. */
+    width?: number;
+    /** Height, as a ratio (0..1) of the bounding box height. */
+    height?: number;
+    /** Absolute font size in points. */
+    fontSize?: number;
+}
+/**
+ * Resolve the `forName`-scoped overrides for the layoutNode named `name`, or
+ * `undefined` when no rule names it (including when `name` itself is
+ * `undefined` - an unnamed template cannot be a `forName` target).
+ */
+export declare function resolveNamedRuleOverride(rules: DiagramNumericRule[], name: string | undefined): NamedRuleOverride | undefined;
+/**
+ * Apply a `forName`-scoped rule override to every rendered node in a layout
+ * result. An `undefined` override is a no-op, so callers can resolve-then-
+ * apply unconditionally.
+ */
+export declare function applyNamedRuleOverride(result: SmartArtLayoutResult, override: NamedRuleOverride | undefined, box: BoundingBox): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-layout-interpreter-named-rules.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-named-rules.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-named-rules.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-named-rules.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkEG;AAEH,OAAO,KAAK,EAAE,uBAAuB,EAAqB,kBAAkB,EAAE,MAAM,UAAU,CAAC;AAC/F,OAAO,KAAK,EAAE,WAAW,EAAgB,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AAE/F,8EAA8E;AAC9E,wBAAgB,iBAAiB,CAAC,UAAU,EAAE,uBAAuB,GAAG,kBAAkB,EAAE,CAY3F;AAqBD,mEAAmE;AACnE,MAAM,WAAW,iBAAiB;IACjC,0DAA0D;IAC1D,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,4DAA4D;IAC5D,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,oCAAoC;IACpC,QAAQ,CAAC,EAAE,MAAM,CAAC;CAClB;AAiBD;;;;GAIG;AACH,wBAAgB,wBAAwB,CACvC,KAAK,EAAE,kBAAkB,EAAE,EAC3B,IAAI,EAAE,MAAM,GAAG,SAAS,GACtB,iBAAiB,GAAG,SAAS,CAmB/B;AAoDD;;;;GAIG;AACH,wBAAgB,sBAAsB,CACrC,MAAM,EAAE,oBAAoB,EAC5B,QAAQ,EAAE,iBAAiB,GAAG,SAAS,EACvC,GAAG,EAAE,WAAW,GACd,oBAAoB,CAKtB"}

package/dist/diagram/layout/smartart-layout-interpreter-position-family.d.ts

@@ -0,0 +1,58 @@
+/**
+ * SmartArt DiagramML interpreter - position-guarded structural arranger
+ * siblings.
+ *
+ * A `dgm:if func="pos"`-guarded `layoutNode` describes ONE position's own
+ * hand-duplicated branch of a `dgm:choose`, not a shared template for every
+ * point - `sub-step-process--hier5.pptx`'s `Name0` declares `chLin1`..
+ * `chLin7`, one `dgm:alg type="lin"` template per top-level point position
+ * (`dgm:varLst/dgm:chMax val="7"` caps the family at 7), each individually
+ * guarded by a two-level `chooseGuard` chain: an outer `func="pos" op="equ"
+ * val="N"` (which position this copy is for) and an inner, nearly-vacuous
+ * `func="cnt" op="gte" val="1"` (does this point have >= 1 own child). See
+ * `smartart-layout-interpreter-model.ts`'s `discoverArrangement`, the one
+ * consumer: a pos-guarded child is disqualified from being ITS single
+ * `chosen` arranger (falls back to the choose-owning node's own resolved,
+ * position-independent algorithm instead) - {@link hasPositionGuard} is
+ * that one-line check.
+ *
+ * {@link detectPositionFamily} is the broader classifier: given a parent
+ * `layoutNode`, finds every group of 2+ DIRECT children sharing the same
+ * `algorithm.type`, each individually `chooseGuard`-gated by a `pos`
+ * condition with a DISTINCT value, and otherwise-identical guard shape (same
+ * non-pos conditions) - the full "family of position-guarded duplicate
+ * structural arranger siblings" shape, sorted ascending by the guard's own
+ * `pos` value. Corpus-measured (`bunx tsx` a one-off scratchpad script over
+ * the whole 227-fixture gallery, every `dgm:layoutNode`'s own `.children`,
+ * for a STRUCTURAL algorithm type): `sub-step-process--hier5.pptx`'s
+ * `chLin1`..`chLin7` (parent `Name0`) is the ONLY family anywhere in the
+ * corpus, and disqualifying ANY structural, pos-guarded node from being a
+ * `chosen` arranger (not only ones grouped into a 2+ family) affects ONLY
+ * that same one fixture (a SEPARATE, broader corpus scan: every structural
+ * `dgm:alg` node anywhere in the gallery whose OWN `chooseGuard` carries a
+ * `pos` condition, family or not - 7 hits, all `chLin1`..`chLin7`). Both
+ * scans are what make {@link hasPositionGuard}'s disqualification safe by
+ * construction, not just by measurement: nothing else in the built-in
+ * gallery can be affected. Exported for documentation/testing and as
+ * general-purpose per-point dispatch infrastructure; `discoverArrangement`
+ * itself only needs {@link hasPositionGuard}, not the full family, since
+ * disqualifying the arranger and falling back to the choose-owning node's
+ * own resolved algorithm is sufficient to fix `sub-step-process`'s own
+ * shape-count/text-key structure (COM-verified: `cached=5 interp=3
+ * matched=1` -> `cached=5 interp=5 matched=5`, every OTHER fixture in the
+ * 227-corpus dashboard unchanged).
+ *
+ * Pure TypeScript - no framework code, no DOM.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+/** `true` when `node`'s own `chooseGuard` chain carries a `func="pos"` condition. */
+export declare function hasPositionGuard(node: DiagramLayoutNode): boolean;
+/**
+ * Sibling `layoutNode`s of `parent` forming a "family of position-guarded
+ * duplicate structural arranger siblings" - see this module's own doc
+ * comment. Sorted ascending by the guard's own `pos` value. `undefined` when
+ * fewer than 2 of `parent.children` share `type`, are `hasPositionGuard`,
+ * and agree on {@link nonPositionGuardShape}.
+ */
+export declare function detectPositionFamily(parent: DiagramLayoutNode, type: string): DiagramLayoutNode[] | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-position-family.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-position-family.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-position-family.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-position-family.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAe,MAAM,UAAU,CAAC;AAE/D,qFAAqF;AACrF,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,iBAAiB,GAAG,OAAO,CAEjE;AAgBD;;;;;;GAMG;AACH,wBAAgB,oBAAoB,CACnC,MAAM,EAAE,iBAAiB,EACzB,IAAI,EAAE,MAAM,GACV,iBAAiB,EAAE,GAAG,SAAS,CAoBjC"}

package/dist/diagram/layout/smartart-layout-interpreter-preset-node.d.ts

@@ -0,0 +1,61 @@
+/**
+ * A box-fit node builder that honours a layoutNode's own `dgm:shape`
+ * override (see `smartart-layout-shape-preset.ts`), falling back to an
+ * arranger's hardcoded family default when the node carries none.
+ *
+ * Used by the flat, box-based arrangers (`lin`/`snake` today) whose item
+ * template is a single rectangle per point; wiring every arranger
+ * (hierarchy/cycle/pyramid/composite) through this is future work - see
+ * `smartart-layout-shape-preset.ts`'s module doc for the honest scope note.
+ *
+ * @module smartart-layout-interpreter-preset-node
+ */
+import type { DiagramLayoutNodeShape, DiagramNode } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { StyleContext } from './smartart-layout-interpreter-render.js';
+import type { PresetRenderKind } from './smartart-layout-shape-preset.js';
+import type { RenderedNode } from './smartart-layout-types.js';
+export interface PresetBoxNodeParams {
+    key: string;
+    x: number;
+    y: number;
+    width: number;
+    height: number;
+    node: DiagramNode;
+    index: number;
+    total: number;
+    palette: string[];
+    style: DiagramStyleIntensity;
+    ctx: StyleContext;
+    /** The item layoutNode's own shape override, when the arranger has one. */
+    shape: DiagramLayoutNodeShape | undefined;
+    /** The arranger's hardcoded default kind, used when `shape` has none. */
+    fallbackKind: PresetRenderKind;
+    /**
+     * A font size every item in the arranged set shares (see
+     * `smartart-layout-item-font-size.ts`), overriding the per-node char-width
+     * fit heuristic. Omit to keep that heuristic (e.g. arrangers with no
+     * uniform item template).
+     */
+    fontSizeOverride?: number | undefined;
+    /** See `RenderedNodeIdentity.descendantFontSize`'s doc comment. */
+    descendantFontSize?: number | undefined;
+    /**
+     * Opt-in: when the resolved kind is `circle` and `width !== height`, carry
+     * the true `width`/`height` through as `RenderedCircleNode.rx`/`.ry`
+     * instead of silently clamping to a circle via `r = min(width, height) /
+     * 2` (the default, pre-existing behaviour every other caller keeps
+     * unchanged). Needed by `smartart-layout-interpreter-cycle.ts`: a real
+     * `ellipse`-preset "Basic Cycle" ring node IS genuinely non-circular (its
+     * PowerPoint aspect comes from fitting an anisotropically-scaled ring into
+     * the diagram box - see that module's doc comment), and clamping it to a
+     * circle was silently discarding a correct width down to the (smaller)
+     * height. Left `false` by default so `smartart-layout-interpreter-
+     * linear.ts`/`smartart-hierarchy-shared.ts`'s existing circle-kind
+     * fixtures render byte-identically.
+     */
+    preserveEllipseAspect?: boolean | undefined;
+}
+/** Build a node covering `[x,y,width,height]`, in the kind `shape` resolves to. */
+export declare function presetBoxNode(params: PresetBoxNodeParams): RenderedNode;
+//# sourceMappingURL=smartart-layout-interpreter-preset-node.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-preset-node.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-preset-node.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH,OAAO,KAAK,EAAE,sBAAsB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AACpE,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AAEtD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,sCAAsC,CAAC;AAMzE,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,gCAAgC,CAAC;AACvE,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,yBAAyB,CAAC;AAE5D,MAAM,WAAW,mBAAmB;IACnC,GAAG,EAAE,MAAM,CAAC;IACZ,CAAC,EAAE,MAAM,CAAC;IACV,CAAC,EAAE,MAAM,CAAC;IACV,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,IAAI,EAAE,WAAW,CAAC;IAClB,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,KAAK,EAAE,qBAAqB,CAAC;IAC7B,GAAG,EAAE,YAAY,CAAC;IAClB,2EAA2E;IAC3E,KAAK,EAAE,sBAAsB,GAAG,SAAS,CAAC;IAC1C,yEAAyE;IACzE,YAAY,EAAE,gBAAgB,CAAC;IAC/B;;;;;OAKG;IACH,gBAAgB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACtC,mEAAmE;IACnE,kBAAkB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACxC;;;;;;;;;;;;;OAaG;IACH,qBAAqB,CAAC,EAAE,OAAO,GAAG,SAAS,CAAC;CAC5C;AAuBD,mFAAmF;AACnF,wBAAgB,aAAa,CAAC,MAAM,EAAE,mBAAmB,GAAG,YAAY,CAwDvE"}