ooxml-core 1.1.0 → 1.2.0

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

@@ -0,0 +1,69 @@
+/**
+ * SmartArt DiagramML interpreter - cycle (`cycle`) arranger.
+ *
+ * Places the data-model points evenly around a centre, honouring the `stAng`
+ * (start angle) and `spanAng` (sweep) algorithm parameters, and draws light
+ * arc connectors between consecutive points. When `ctrShpMap`
+ * (`dgm:param[@type=ctrShpMap]`) is `fNode`, the FIRST data point is pulled
+ * off the ring and placed at the box centre instead - PowerPoint's "Radial
+ * Cycle" family layouts use this for a hub node the ring nodes surround.
+ *
+ * ## Node sizing (live-PowerPoint-COM-verified derivation, corrected round
+ * 11/SESSION 8 - ignore any older note citing an "anisotropic fill-to-box"
+ * model: measured against a NOW-FIXED cached-reader bug, does not match real
+ * PowerPoint COM output.)
+ *
+ * Live COM (three independent methods: `SmartArt.AllNodes` shape geometry,
+ * "Convert to Shapes" + `GroupItems`, and a pixel-bounding-box PNG scan - see
+ * `smartart-decompose.test.ts`'s "matches live PowerPoint COM geometry")
+ * proved PowerPoint does NOT independently stretch cached content to fill its
+ * frame: a cached shape's real geometry is `graphicFrame.origin + dsp:sp`'s
+ * own `a:xfrm` offset, size UNCHANGED, sized directly from the DiagramML
+ * constraint graph (ECMA-376 21.4.7); when smaller than the frame on an
+ * axis, it is CENTRED there (verified on `basic-cycle--flat3.pptx`, hub-less,
+ * and `basic-radial--hier5.pptx`, hub+ring - symmetric margins, never
+ * one-sided).
+ *
+ * MS's "Cycle Algorithm" reference (Office 2007 SDK) gives only schema
+ * defaults (`w`/`h`=100, `diam`=0, `sibSp`=0), not the packing formula, so the
+ * RING RADIUS (`R0`) was reverse-engineered against real cached `dsp:sp`
+ * geometry (only the FINAL box-fit step was wrong):
+ *
+ *   1. In a unit space where the node's own width is 1: place `n` points on
+ *      a circle of radius `R0`, spaced by `spanAng/n` (full) or `/(n-1)`
+ *      (arc), starting at `stAng`.
+ *   2. `R0` solves the adjacent-point chord to `(1 + minGap) * 1`:
+ *      `2*R0*sin(step/2) = 1 + minGap`.
+ *   3. Compute the natural bounding box of all `n` unit-width (height = the
+ *      item's own `h:w` fact) footprints centred at those points.
+ *   4. Scale that box by a SINGLE isotropic factor (`Math.min` of the two
+ *      per-axis "fill" candidates, a "contain" not "cover" fit) and CENTRE
+ *      the slack (`smartart-layout-interpreter-cycle-ring.ts` has the
+ *      numeric derivation). Final width = final height / (item h:w fact) -
+ *      `heightOverWidth===1` is ALWAYS a true circle/square.
+ *
+ * Verified against the full gallery: `basic-cycle`/`multidirectional-cycle`/
+ * `continuous-cycle`/`basic-radial--hier5`/`radial-cycle--flat3` all PASS
+ * (<=1% `maxDeltaFraction`) - a general fix.
+ *
+ * `ctrShpMap="fNode"` hub sizing reuses the SAME `R0`/scale computation
+ * (`computeCycleRingLayout`'s `hubCenter`/`naturalHubRadius`): centred at
+ * the ring's natural centre, sized to the largest ellipse fitting the space
+ * to the nearest ring node - `smartart-layout-interpreter-hub.ts`'s
+ * `buildHubRenderedNode` consumes it.
+ *
+ * The ring's fixed-point solve lives in `smartart-layout-interpreter-cycle-
+ * ring.ts`, constraint reading in `smartart-layout-interpreter-cycle-
+ * constraints.ts`; both re-exported here. Pure geometry; no framework code.
+ */
+import type { DiagramNode } 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';
+export type { CycleRingLayout } from './smartart-layout-interpreter-cycle-ring.js';
+export { computeCycleRingLayout } from './smartart-layout-interpreter-cycle-ring.js';
+export { resolveCycleConstraintNode, resolveCycleRingParams, } from './smartart-layout-interpreter-cycle-constraints.js';
+/** Execute the `cycle` algorithm: points on a ring around the box centre. */
+export declare function arrangeCycle(plan: ArrangementPlan, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, index?: ConstraintIndex, hubAlreadyStripped?: boolean, childrenOf?: Map<string, DiagramNode[]>, fontName?: string, declaringRoleChain?: readonly string[], sizeBox?: BoundingBox): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-layout-interpreter-cycle.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAyDG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC5C,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;AAI3E,OAAO,KAAK,EACX,WAAW,EAGX,oBAAoB,EACpB,MAAM,yBAAyB,CAAC;AAEjC,YAAY,EAAE,eAAe,EAAE,MAAM,0CAA0C,CAAC;AAChF,OAAO,EAAE,sBAAsB,EAAE,MAAM,0CAA0C,CAAC;AAClF,OAAO,EACN,0BAA0B,EAC1B,sBAAsB,GACtB,MAAM,iDAAiD,CAAC;AAEzD,6EAA6E;AAC7E,wBAAgB,YAAY,CAC3B,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,GAAE,eAAwC,EAC/C,kBAAkB,UAAQ,EAC1B,UAAU,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,EACvC,QAAQ,CAAC,EAAE,MAAM,EACjB,kBAAkB,CAAC,EAAE,SAAS,MAAM,EAAE,EACtC,OAAO,CAAC,EAAE,WAAW,GACnB,oBAAoB,CAkJtB"}

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

@@ -0,0 +1,18 @@
+/**
+ * SmartArt DiagramML interpreter - per-kind arranger dispatch.
+ *
+ * Split out of `smartart-layout-interpreter.ts` (the repo's per-file line
+ * budget) so that module can stay focused on the overall `runArrangement`/
+ * `interpretSmartArtLayout` orchestration: this half is the plain switch from
+ * a discovered {@link ArrangementPlan}'s `kind` onto its concrete arranger
+ * function. Pure TypeScript - no framework code.
+ */
+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 } from './smartart-layout-interpreter-model.js';
+import type { BoundingBox, SmartArtLayoutResult } from './smartart-layout-types.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/** Dispatch a discovered plan to its arranger, or `undefined` when declined. */
+export declare function dispatchArrangement(view: RawXmlView<unknown>, plan: ArrangementPlan, arranged: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, presLayoutVars: DiagramPresLayoutVars | undefined, index: ConstraintIndex, childrenOf: Map<string, DiagramNode[]>, hubStripped?: boolean, fontName?: string, flat?: DiagramNode[]): SmartArtLayoutResult | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-dispatch.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-dispatch.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-dispatch.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACnE,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAMpE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAE3E,OAAO,KAAK,EAAE,WAAW,EAAE,oBAAoB,EAAE,MAAM,yBAAyB,CAAC;AACjF,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD,gFAAgF;AAChF,wBAAgB,mBAAmB,CAClC,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,eAAe,EACrB,QAAQ,EAAE,WAAW,EAAE,EACvB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,KAAK,EAAE,eAAe,EACtB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,EACtC,WAAW,UAAQ,EACnB,QAAQ,CAAC,EAAE,MAAM,EACjB,IAAI,GAAE,WAAW,EAAa,GAC5B,oBAAoB,GAAG,SAAS,CA2GlC"}

package/dist/diagram/layout/smartart-layout-interpreter-flow-direction.d.ts

@@ -0,0 +1,29 @@
+/**
+ * SmartArt DiagramML interpreter - arranger algorithm parameters + linear
+ * flow direction.
+ *
+ * Split out of `smartart-layout-interpreter-model.ts` (the repo's per-file
+ * line budget): small, generic `dgm:param` readers and the `linDir`/
+ * `presLayoutVars.direction` flow-direction resolver, re-exported from that
+ * module so every existing import site keeps working unchanged. Pure
+ * TypeScript - no framework code, no DOM.
+ */
+import type { DiagramLayoutNode, DiagramPresLayoutVars } from '../model/index.js';
+/** The first nested item `layoutNode` under an arranger (the per-point shape). */
+export declare function itemNode<R>(arranger: DiagramLayoutNode<R>): DiagramLayoutNode<R> | undefined;
+/** Read an algorithm parameter value by its `dgm:param` type. */
+export declare function algorithmParam(node: DiagramLayoutNode, type: string): string | undefined;
+/** Read a numeric algorithm parameter, returning `fallback` when absent/invalid. */
+export declare function numericParam(node: DiagramLayoutNode, type: string, fallback: number): number;
+/** Orientation + ordering resolved from `linDir` and presentation variables. */
+export interface FlowDirection {
+    orientation: 'horizontal' | 'vertical';
+    reverse: boolean;
+}
+/**
+ * Resolve linear flow direction from the arranger's `linDir` param and the
+ * data model's `dgm:dir` (`presLayoutVars.direction`). `fromR`/`fromB` and a
+ * reversed direction both flip the placement order.
+ */
+export declare function resolveFlowDirection(arranger: DiagramLayoutNode, presLayoutVars: DiagramPresLayoutVars | undefined): FlowDirection;
+//# sourceMappingURL=smartart-layout-interpreter-flow-direction.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-flow-direction.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-flow-direction.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AAEzE,kFAAkF;AAClF,wBAAgB,QAAQ,CAAC,CAAC,EAAE,QAAQ,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,CAE5F;AAED,iEAAiE;AACjE,wBAAgB,cAAc,CAAC,IAAI,EAAE,iBAAiB,EAAE,IAAI,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS,CAExF;AAED,oFAAoF;AACpF,wBAAgB,YAAY,CAAC,IAAI,EAAE,iBAAiB,EAAE,IAAI,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,MAAM,CAO5F;AAED,gFAAgF;AAChF,MAAM,WAAW,aAAa;IAC7B,WAAW,EAAE,YAAY,GAAG,UAAU,CAAC;IACvC,OAAO,EAAE,OAAO,CAAC;CACjB;AAED;;;;GAIG;AACH,wBAAgB,oBAAoB,CACnC,QAAQ,EAAE,iBAAiB,EAC3B,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,aAAa,CAQf"}

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

@@ -0,0 +1,49 @@
+/**
+ * SmartArt DiagramML interpreter - control-flow execution (forEach / choose).
+ *
+ * The typed layout model (see `smartart-layout-definition.ts`) flattens the
+ * `dgm:forEach` / `dgm:choose` wrappers when it collects nested `layoutNode`s,
+ * but it preserves the iterator attributes (`axis`/`ptType`/`st`/`cnt`/`step`/
+ * `hideLastTrans`) on each node's `forEach`, and the branch conditions on each
+ * node's `choose`. This module executes the decidable parts of that control flow
+ * so the interpreter selects the right number of data points and, where a
+ * `dgm:choose` is decidable from the node count, the right branch's arrangement
+ * algorithm.
+ *
+ * Scope / honesty: this is still a partial interpreter. It does NOT resolve
+ * point references or run the full recursive solver. `selectArrangedNodes` maps
+ * one flat data point per iteration slot and folds transitions into that stream,
+ * so `hideLastTrans` trims one trailing slot rather than a separate connector.
+ * Pure TypeScript - no framework code, no DOM.
+ */
+import type { DiagramLayoutNode, DiagramNode } from '../model/index.js';
+export type { WhenContext } from './smartart-layout-interpreter-when.js';
+/**
+ * Apply the driving `dgm:forEach` selection semantics (`st` / `cnt` / `step`) to
+ * the flat data-model points and, when the iterator declares `hideLastTrans`,
+ * drop the trailing slot. `st` is 1-based (DiagramML default 1); `cnt` of 0
+ * means "all"; `step` defaults to 1. Returns `flat` unchanged when the arranger
+ * node carries no iterator.
+ *
+ * When `node` declares MORE THAN ONE qualifying iterator ({@link
+ * qualifyingIterators}), or nests a `followSib`/`ptType="node"` iterator
+ * inside one iterator's own item template ({@link
+ * collectFollowSibNodeCounts}), the result is the UNION of every iterator's
+ * own selection, in data order - `Target List`'s 7 independent single-point
+ * ring iterators, and `Alternating Flow`'s `step="2"` primary paired with a
+ * nested `followSib` "next point" secondary, both resolve this way. The
+ * common case (exactly one iterator, no nested pairing) is unaffected: the
+ * union of one iterator's own indices is exactly its own selection, same as
+ * before this generalisation.
+ *
+ * @param roots The original (un-flattened) top-level nodes. When EVERY
+ *   qualifying iterator's axis is exactly `ch` (see {@link isChildOnlyAxis}),
+ *   selection runs over `roots` instead of the depth-first-flattened `flat`,
+ *   so a node with children gets exactly one box; the caller
+ *   (`interpretedLayoutToElements`) folds each unrendered descendant's text
+ *   into its ancestor's box as additional paragraphs. Omit `roots` (or pass
+ *   it equal to `flat`) to keep the previous flat-only behaviour, e.g. for
+ *   callers with no tree to offer.
+ */
+export declare function selectArrangedNodes<N extends DiagramNode>(node: DiagramLayoutNode, flat: N[], roots?: N[]): N[];
+//# sourceMappingURL=smartart-layout-interpreter-flow.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-flow.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-flow.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,KAAK,EAAkB,iBAAiB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAE/E,YAAY,EAAE,WAAW,EAAE,MAAM,oCAAoC,CAAC;AA4GtE;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,wBAAgB,mBAAmB,CAAC,CAAC,SAAS,WAAW,EACxD,IAAI,EAAE,iBAAiB,EACvB,IAAI,EAAE,CAAC,EAAE,EACT,KAAK,CAAC,EAAE,CAAC,EAAE,GACT,CAAC,EAAE,CAkDL"}

package/dist/diagram/layout/smartart-layout-interpreter-hierarchy-descendant.d.ts

@@ -0,0 +1,60 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy-descendant precedence guard for
+ * `discoverArrangement` (`smartart-layout-interpreter-model.ts`, Track S's
+ * own file - this is a Track R cross-track addition, disclosed in the
+ * SESSION 24 report, since it is squarely about `hierChild`/`hierRoot`
+ * precedence).
+ *
+ * SESSION 24 finding (`horizontal-labeled-hierarchy--hier5.pptx`, the
+ * "hierarchy5" layoutDef - and structurally the SAME shape as `labeled-
+ * hierarchy--hier5.pptx`'s own "hierarchy6", which dispatches correctly):
+ * `mainComposite` wraps TWO SIBLING flows, `hierFlow` (`dgm:alg type="lin"`,
+ * itself CHOOSE-WRAPPED - picking whether a leading `firstBuf` spacer is
+ * included) and `bgShapesFlow` (the background-band flow). `hierFlow`'s own
+ * choose CORRECTLY resolves to `lin` (this is not a mis-tunnelled match -
+ * `hierFlow` genuinely IS a `lin`-type layoutNode) - but `hierFlow` is only
+ * a THIN packing wrapper around its own child `hierChild1`, the REAL
+ * arrangement algorithm for the whole diagram. `discoverArrangement`'s walk
+ * visits `hierFlow` BEFORE `hierChild1` (a shallower ancestor, visited
+ * first in the pre-order walk) and sets `chosen = {kind:'linear',
+ * node:hierFlow}` immediately - which, via the `!hierarchy && !chosen` top
+ * guard, PERMANENTLY BLOCKS `hierChild1`'s own (later, but genuinely
+ * decidable) choose resolution from ever running, even though `hierarchy`
+ * carries the HIGHEST final precedence when it IS found.
+ *
+ * This is a DIFFERENT root cause from `nested-target`'s own (a `.choose`
+ * search tunnelling INTO the wrong content) - `tunnelsPastOwnCompositeSlot`
+ * does not fire here at all (`hierFlow.algorithm?.type` is `undefined` at
+ * the point that check runs, not `'composite'`, so `looksLikeOwnComposite`
+ * is false). It is also a NARROWER condition than either of Track S's own
+ * two prior (reverted, 16-fixture-regressing) attempts at a related
+ * precedence fix: those gated the CHOOSE-BRANCH ITSELF broadly (skip a
+ * `.choose` for any node that also independently looks like a composite, or
+ * is a descendant of one) - this instead gates ONLY the `chosen` STRUCTURAL
+ * assignment, and ONLY when the candidate's own subtree contains a REAL
+ * `hierChild`/`hierRoot` construct (a condition true for exactly this
+ * "sibling flows, one hiding a hierarchy tree" shape, not for the ordinary
+ * timeline/picture-list/radial fixtures the 16-fixture regression list
+ * named) - see `smartart-track-r-successor.md` SESSION 24 for the full
+ * corpus classification this was measured against before landing.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+import type { WhenContext } from './smartart-layout-interpreter-when.js';
+/**
+ * True when `node` has a DESCENDANT whose own algorithm resolves to
+ * `hierChild`/`hierRoot` - checked BOTH directly (`child.algorithm?.type`,
+ * a bare non-choose-wrapped `dgm:alg`) AND via `chooseAlgType` (a
+ * choose-wrapped one, e.g. `hierChild1`'s own `linDir` `fromL`/`fromR`
+ * direction pick - the exact shape a genuine org-chart-family `hierChild`
+ * always takes, per `smartart-layout-interpreter-choose-algorithm.ts`'s own
+ * `CHOOSE_ALG_TYPES` inclusion of these two types). Unlike `hasStructural
+ * Descendant` (`smartart-layout-interpreter-composite-detect.ts`), which
+ * deliberately only checks DIRECT algorithms, this one MUST also resolve
+ * choose-wrapped ones - a `hierChild`/`hierRoot` algorithm is choose-wrapped
+ * in every genuine fixture measured so far (the `linDir`/`hierBranch`
+ * direction pick is universal), so a direct-only check would never fire for
+ * the exact construct this guard exists to protect.
+ */
+export declare function hasHierarchyDescendant<R>(view: RawXmlView<R>, node: DiagramLayoutNode<R>, nodeCount: number, context: WhenContext): boolean;
+//# sourceMappingURL=smartart-layout-interpreter-hierarchy-descendant.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-hierarchy-descendant.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-hierarchy-descendant.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,oCAAoC,CAAC;AAItE;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,sBAAsB,CAAC,CAAC,EACvC,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,IAAI,EAAE,iBAAiB,CAAC,CAAC,CAAC,EAC1B,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,WAAW,GAClB,OAAO,CAQT"}

package/dist/diagram/layout/smartart-layout-interpreter-hierarchy-fontfit.d.ts

@@ -0,0 +1,45 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy (`hierRoot` / `hierChild`)
+ * font-fit.
+ *
+ * Split out of `smartart-layout-interpreter-hierarchy.ts` (the repo's
+ * per-file line budget).
+ *
+ * ONE shared font size (pixels) across every node's own text, pre-fit at the
+ * uniform `boxW`/`boxH` a hierarchy run places every item at - the SAME
+ * "unwired `fitFontSize`-fallback" bug class `smartart-layout-interpreter-
+ * cycle-fontfit.ts`'s doc comment names, closed generally for `cycle`/
+ * `composite`/`pyramid` in round 18: `smartart-hierarchy-shared.ts`'s
+ * `pushNode` called `presetBoxNode` with no `fontSizeOverride` at all, so
+ * EVERY hierarchy item in the whole gallery fell through to `rectNode`'s
+ * crude, un-derived `fitFontSize(text, width*0.9, height, 12)` fallback (a
+ * flat ~9pt floor, confirmed via the round-19 corpus font-bucket scan:
+ * `organization-chart`/`hierarchy`/`horizontal-hierarchy`/`picture-
+ * organization-chart`, 9 of the gallery's `hierarchy`-plan fixtures, all
+ * pegged at 12px regardless of their real cached size). Deliberately keyed
+ * off `algorithmNode` itself (not `itemNode(plan.node)`'s first-child
+ * heuristic) - `nodeFontBounds`'s own `findFontRoleNode` DFS already walks
+ * past the per-node `composite`/`tx` wrapper `findHierarchyItemShape`
+ * documents to the real text role, the same way `arrangeText` passes its own
+ * one-level-shallower `plan.node` directly (see that module's round-18 doc
+ * comment). No descendant folding: unlike `lin`/`snake`, a hierarchy child is
+ * always its OWN separate box at the next generation, never folded into a
+ * parent's text - `descendantTexts` is always `[]`. Returns `undefined`
+ * (keeping `pushNode`'s previous fallback) when there is no `algorithmNode`
+ * (a plan this interpreter cannot resolve constraints against) or no
+ * text-bearing node to fit at all.
+ *
+ * Known residual (not fixed this round): this resolves ONE size for the
+ * WHOLE tree, fit against the fanned generation's own `boxW`/`boxH` - real
+ * PowerPoint gives an unaccented/leaf row a LARGER font than an accented row
+ * sharing its slot with other content (the same per-row differentiation
+ * `arrangePyramid`'s own round-19 residual shows), which a single shared size
+ * cannot reproduce exactly. Measured as a real, large reduction in the
+ * average FONT delta across the `hierarchy`-plan fixtures (not an exact
+ * match) - see `smartart-track-l-successor.md`'s round 19 section.
+ */
+import type { DiagramLayoutNode, DiagramNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+/** See the module doc comment. */
+export declare function resolveHierarchyItemFontSizePx(nodes: readonly DiagramNode[], algorithmNode: DiagramLayoutNode | undefined, index: ConstraintIndex, boxW: number, boxH: number, fontName: string | undefined): number | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-hierarchy-fontfit.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-hierarchy-fontfit.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-hierarchy-fontfit.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC/D,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAIpE,kCAAkC;AAClC,wBAAgB,8BAA8B,CAC7C,KAAK,EAAE,SAAS,WAAW,EAAE,EAC7B,aAAa,EAAE,iBAAiB,GAAG,SAAS,EAC5C,KAAK,EAAE,eAAe,EACtB,IAAI,EAAE,MAAM,EACZ,IAAI,EAAE,MAAM,EACZ,QAAQ,EAAE,MAAM,GAAG,SAAS,GAC1B,MAAM,GAAG,SAAS,CAwBpB"}

package/dist/diagram/layout/smartart-layout-interpreter-hub-detect.d.ts

@@ -0,0 +1,26 @@
+/**
+ * SmartArt DiagramML interpreter - "hub + satellites" arranger DETECTION.
+ *
+ * Split out of `smartart-layout-interpreter-hub.ts` (repo per-file line
+ * budget): the raw-XML/typed-field heuristics that decide whether an
+ * arranger's own driving `dgm:forEach` genuinely repeats a child template
+ * (a hub whose children become satellites) as opposed to a plain per-point
+ * template, a list continuation, or an unrelated transition iterator. See
+ * that module's own doc comment for the overall "hub + satellites"
+ * substitution this feeds.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/**
+ * True when `arranger`'s driving `dgm:forEach` (`arranger.forEach[0]`)
+ * either IS ITSELF a `ch`-axis child iterator (`radial-cluster`'s own
+ * `singleCycle`: its one DIRECT forEach child already iterates the hub's
+ * children - there is no separate outer `cnt="1"` forEach wrapping it, that
+ * selection lives one level up, in `arranger.forEachOrigin`, not
+ * `arranger.forEach`) or declares a NESTED `dgm:forEach axis="ch"` in its
+ * raw body (the shape this module originally documented - `radial-cycle`/
+ * `basic-radial`/`balance`, where the arranger's own driving forEach selects
+ * the hub and a forEach nested inside IT arranges the children).
+ */
+export declare function arrangerRepeatsChildTemplate(view: RawXmlView<unknown>, arranger: DiagramLayoutNode): boolean;
+//# sourceMappingURL=smartart-layout-interpreter-hub-detect.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-hub-detect.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-hub-detect.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAIH,OAAO,KAAK,EAAkB,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClE,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AA6FxD;;;;;;;;;;GAUG;AACH,wBAAgB,4BAA4B,CAC3C,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,QAAQ,EAAE,iBAAiB,GACzB,OAAO,CAOT"}

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

@@ -0,0 +1,62 @@
+/**
+ * SmartArt DiagramML interpreter - "hub + satellites" arranger substitution.
+ *
+ * A radial/composite layout (`radial-cycle`, `basic-radial`, `balance`,
+ * `vertical-circle-list`) whose driving `dgm:forEach` selects a SINGLE point
+ * (`cnt="1"`, or simply having one root) is not arranging that one point as
+ * its only content - the point is a HUB, and a NESTED `dgm:forEach
+ * axis="ch"` inside the SAME driving iterator's raw body actually arranges
+ * the hub's OWN children (`nestedLayoutNodes` in `smartart-layout-
+ * definition.ts` flattens that nested forEach's item templates onto the
+ * SAME `.children` array as the hub's own template - it does not model
+ * iteration-scope boundaries - so a raw-XML check is the only way to tell
+ * "these siblings are additional roles of the SAME point"
+ * (`smartart-layout-interpreter-item-roles.ts`'s `resolveItemTextRoles`)
+ * apart from "these REPEAT once per the point's own child" (this module)).
+ * Split out of `smartart-layout-interpreter.ts` to keep that file under the
+ * repo's per-file line budget.
+ */
+import type { DiagramLayoutNode, DiagramNode } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { BoundingBox, RenderedNode } from './smartart-layout-types.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/** The hub point plus the satellites its nested `axis="ch"` forEach actually arranges. */
+export interface HubExpansion {
+    hubNode: DiagramNode;
+    satellites: DiagramNode[];
+}
+/**
+ * Detect the hub pattern for this arranger's already-selected `arranged`
+ * list: exactly one point was selected, its OWN driving forEach repeats a
+ * child template, and it genuinely has children to repeat that template
+ * over. Returns `undefined` (keep `arranged` as-is) otherwise - the common
+ * case, and the safe degradation when a diagram matches the `cnt="1"`/single
+ * -root shape without ALSO nesting a child-repeating forEach (an ordinary
+ * one-point diagram).
+ */
+export declare function detectHubExpansion(view: RawXmlView<unknown>, arranger: DiagramLayoutNode, arranged: DiagramNode[], childrenOf: Map<string, DiagramNode[]>): HubExpansion | undefined;
+/**
+ * Build the hub's own box. When `arranger` is a `cycle` algorithm (every
+ * genuine gallery hub layout - `radial-cycle`, `basic-radial`,
+ * `diverging-radial`, `converging-radial`, `radial-venn` - the hub is the
+ * `ctrShpMap="fNode"` node of a `cycle` alg), this reuses
+ * `smartart-layout-interpreter-cycle.ts`'s own ring-fitting geometry
+ * (`computeCycleRingLayout`) with `satelliteCount` ring nodes for the ring's
+ * own centre/scale, then sizes the hub from `resolveCycleRingParams`'s
+ * `hubRatio` (`node.w = fact * centerShape.w`, DECLARED directly in the
+ * composite's own `constrLst` - see that function's doc comment) when
+ * present: the hub's natural (pre-scale) width is `1 / fact` in the SAME
+ * unit space the ring item's own natural width (fixed at 1) already uses,
+ * so its SCALED half-extents are `(1/fact)/2 * scaleX` /
+ * `(1/fact)/2 * scaleY`, reusing the ring's own already-solved
+ * `scaleX (= ring.nodeWidth)` / `scaleY (= ring.nodeHeight /
+ * heightOverWidth)` - no separate geometric guess needed. Falls back to the
+ * ring's own "largest ellipse that clears every ring node" computation
+ * (`hubHalfWidth`/`hubHalfHeight`) when no such declared ratio is found, and
+ * to the previous coarse `0.3x`-of-the-smaller-box-dimension placeholder for
+ * every other hub-bearing algorithm (`balance`, `vertical-circle-list`),
+ * which this module does not have per-family geometry for.
+ */
+export declare function buildHubRenderedNode(arranger: DiagramLayoutNode, hubNode: DiagramNode, box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, satelliteCount?: number, index?: ConstraintIndex, childrenOf?: Map<string, DiagramNode[]>, fontName?: string): RenderedNode;
+//# sourceMappingURL=smartart-layout-interpreter-hub.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-hub.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-hub.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC/D,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAapE,OAAO,KAAK,EAAE,WAAW,EAAE,YAAY,EAAE,MAAM,yBAAyB,CAAC;AACzE,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD,0FAA0F;AAC1F,MAAM,WAAW,YAAY;IAC5B,OAAO,EAAE,WAAW,CAAC;IACrB,UAAU,EAAE,WAAW,EAAE,CAAC;CAC1B;AAED;;;;;;;;GAQG;AACH,wBAAgB,kBAAkB,CACjC,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,QAAQ,EAAE,iBAAiB,EAC3B,QAAQ,EAAE,WAAW,EAAE,EACvB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,GACpC,YAAY,GAAG,SAAS,CAO1B;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,oBAAoB,CACnC,QAAQ,EAAE,iBAAiB,EAC3B,OAAO,EAAE,WAAW,EACpB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,SAAS,EAAE,MAAM,EACjB,cAAc,SAAI,EAClB,KAAK,GAAE,eAAwC,EAC/C,UAAU,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,EACvC,QAAQ,CAAC,EAAE,MAAM,GACf,YAAY,CAgHd"}

package/dist/diagram/layout/smartart-layout-interpreter-item-role-compound.d.ts

@@ -0,0 +1,36 @@
+/**
+ * SmartArt DiagramML interpreter - compound `presOf axis="ch ..."` per-item
+ * role content.
+ *
+ * Split out of `smartart-layout-interpreter-item-role-shared.ts` (the
+ * file-size budget): `contentIds`'s single-token axis branches (`self`/`ch`/
+ * `des`/`desOrSelf`) assume ONE data point per role. A compound axis whose
+ * FIRST token is `ch` (`Tab List`'s `FirstChild`, `presOf axis="ch desOrSelf"
+ * st="1 1" cnt="1 0"`; `Child`, `axis="ch desOrSelf" st="2 1" cnt="0 0"`)
+ * instead selects a 1-based POSITION RANGE into the point's own children (via
+ * the `ch` token's own `st`/`cnt`), then folds each selected position's
+ * descendants in via the second token - the same "named per-child slot"
+ * shape `smartart-layout-interpreter-composite-children.ts` resolves for a
+ * bare composite wrapper, reused here via {@link positionRange}. Pure
+ * TypeScript - no framework code.
+ */
+import type { DiagramLayoutNode, DiagramNode } from '../model/index.js';
+/**
+ * A compound `presOf axis="ch desOrSelf"` (or `"ch des"`) role's own content:
+ * the FIRST token (`ch`) selects a 1-based POSITION RANGE into `node`'s own
+ * children via its own `start`/`count` (`Tab List`'s `FirstChild`, position 1
+ * only; `Child`, position 2 onward, unbounded - both reached via the SAME
+ * `nodesForEach axis="ch"` as the arranger's own per-point iteration, so
+ * `node` here is already the correctly-anchored point), the second token
+ * (`des`/`desOrSelf`) folds each selected position's own descendants in
+ * alongside it (`desOrSelf` also keeps the position's own text; a bare `des`
+ * does not - this corpus has no fixture exercising a compound `des` second
+ * token, so it is treated the same as `desOrSelf` rather than guessing a
+ * narrower rule). Multiple resolved positions concatenate into ONE role's
+ * content (the first position primary, the rest folded), matching the
+ * existing single-token `desOrSelf` precedent of folding everything into one
+ * box - no gallery fixture currently exercises 2+ remaining positions on the
+ * SAME role to verify a per-position split against instead.
+ */
+export declare function compoundChildIds(role: DiagramLayoutNode, node: DiagramNode, childrenOf: Map<string, DiagramNode[]>): string[];
+//# sourceMappingURL=smartart-layout-interpreter-item-role-compound.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-item-role-compound.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-item-role-compound.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-item-role-compound.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAI/D;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,gBAAgB,CAC/B,IAAI,EAAE,iBAAiB,EACvB,IAAI,EAAE,WAAW,EACjB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,GACpC,MAAM,EAAE,CAsBV"}

package/dist/diagram/layout/smartart-layout-interpreter-item-role-orientation.d.ts

@@ -0,0 +1,80 @@
+/**
+ * SmartArt DiagramML interpreter - per-item role stacking orientation.
+ *
+ * Round 27: `stackRoleContent`/`stackAsRect` (`smartart-layout-interpreter-
+ * item-role-stack{,-rect}.ts`) always stack a role-split item's content roles
+ * VERTICALLY, weighted by each role's own arranger-declared `h` constraint,
+ * scoped against the OUTER arranger's own role name. That is correct for a
+ * FLAT-sibling item template ("Vertical Bullet List"'s `parentText`/
+ * `childText`, direct children of the arranger itself - cached ground truth
+ * genuinely stacks them top-to-bottom), but wrong for an item template whose
+ * roles are nested inside their OWN horizontally-oriented `lin` sub-arranger
+ * ("Vertical Bracket List"'s `linNode`, `linDir="fromL"`, wrapping `parTx`/
+ * `bracket`/`spH`/`desTx` side by side - cached ground truth is two COLUMNS,
+ * a narrow label on the left and a wide descendant box on the right, never a
+ * vertical stack). Round 25 found the root cause (`itemAspect`'s own
+ * same-axis-inherit squash) and the shape of the missing mechanism (a
+ * `stackAsColumns` sibling to `stackAsRect`) but did not build it - see that
+ * round's own successor-doc section for the measured regression its narrower
+ * `itemAspect` attempt caused, and why a dedicated column mechanism, not an
+ * `itemAspect` exemption, is the safer fix.
+ *
+ * This module resolves, for a role-split item template, WHICH layoutNode's
+ * own `constrLst` declares each role's `w`/`h` share (the `declaringRole`
+ * {@link resolveConstraintDeclaredBy} needs), and whether the roles should
+ * stack as ROWS (the pre-existing, unchanged default) or COLUMNS.
+ */
+import type { DiagramLayoutNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/** How a role-split item's content roles are laid out within the item's box. */
+export interface ItemRoleLayoutScope {
+    /** The layoutNode whose `for="ch"/"des" forName="<role>"` constraints size each role - see {@link resolveConstraintDeclaredBy}. */
+    declaringRole: string;
+    orientation: 'row' | 'column';
+}
+/**
+ * True only for an EXPLICIT horizontal `lin` (`dgm:param type="linDir"
+ * val="fromL"|"fromR"`) - never the ECMA default-when-absent (which would
+ * also read as "horizontal" per `resolveFlowDirection`'s own convention).
+ * Deliberately narrower: the overwhelming majority of `lin`-wrapped item
+ * templates in the gallery corpus declare no `linDir` of their own at all
+ * and genuinely want the pre-existing vertical row stack - only a wrapper
+ * that SAYS so explicitly should switch to columns (round 25's own
+ * "narrower trigger" lead, applied here instead of `itemAspect`). Exported
+ * for `smartart-layout-interpreter-linear.ts`'s own `itemAspect` (round 25's
+ * REVERTED same-axis-inherit exemption regressed ~25 unrelated fixtures with
+ * no orientation check at all - this narrower, ALREADY-corpus-safe signal is
+ * the "narrower trigger" that section's own doc comment asked for).
+ */
+export declare function isExplicitHorizontalLin(view: RawXmlView<unknown>, node: DiagramLayoutNode, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): boolean;
+/**
+ * True when `node` is a genuine COLUMN-ORIENTED item wrapper: an EXPLICIT
+ * horizontal `lin` ({@link isExplicitHorizontalLin}) whose own text roles
+ * ({@link unwrapTextRoles}) are 2+ and EVERY one resolves a genuinely plain,
+ * axis-aligned box ({@link resolvedShapeIsPlainRect}). The SINGLE shared
+ * check both `resolveItemRoleLayoutScope` (below, the role-split geometry
+ * itself) and `smartart-layout-interpreter-linear.ts`'s `itemAspect` (the
+ * item's own OVERALL box shape) need to agree on - round 27 first built
+ * these as two SEPARATE checks (`itemAspect` consulting only
+ * `isExplicitHorizontalLin`, without the shape guard) and measured a real
+ * regression from the split: "Vertical Block List" shares "Vertical Bracket
+ * List"'s exact explicit-horizontal-`linNode` wrapper shape, so
+ * `itemAspect`'s own (unguarded) exemption widened ITS box too, even after
+ * the role-split guard correctly kept its ROLE geometry as a row - a
+ * genuinely wrong box shape from a check `resolveItemRoleLayoutScope` had
+ * already correctly declined. Consolidated into one function so both
+ * call sites can never disagree again.
+ */
+export declare function isColumnWrapper(view: RawXmlView<unknown>, node: DiagramLayoutNode, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): boolean;
+/**
+ * Resolve `roles`' own layout scope within `arranger`'s item template.
+ * Default (no qualifying wrapper, or the wrapper is not a genuine {@link
+ * isColumnWrapper}): `arrangerRole` itself declares the constraints and
+ * stacking stays a ROW split - IDENTICAL to every pre-existing `stackAsRect`
+ * caller's behaviour before this module existed. `nodeCount`/`presLayoutVars`
+ * resolve a `dgm:choose`-wrapped wrapper's own algorithm/shape - omitted, an
+ * undecidable choose simply stays a ROW split, never a false-positive column
+ * one.
+ */
+export declare function resolveItemRoleLayoutScope(view: RawXmlView<unknown>, arranger: DiagramLayoutNode, arrangerRole: string, roles: readonly DiagramLayoutNode[], nodeCount?: number, presLayoutVars?: DiagramPresLayoutVars): ItemRoleLayoutScope;
+//# sourceMappingURL=smartart-layout-interpreter-item-role-orientation.d.ts.map

package/dist/diagram/layout/smartart-layout-interpreter-item-role-orientation.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-item-role-orientation.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-item-role-orientation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAIH,OAAO,KAAK,EAAE,iBAAiB,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AAIzE,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD,gFAAgF;AAChF,MAAM,WAAW,mBAAmB;IACnC,mIAAmI;IACnI,aAAa,EAAE,MAAM,CAAC;IACtB,WAAW,EAAE,KAAK,GAAG,QAAQ,CAAC;CAC9B;AAoDD;;;;;;;;;;;;;GAaG;AACH,wBAAgB,uBAAuB,CACtC,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,iBAAiB,EACvB,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,OAAO,CAOT;AAwED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,eAAe,CAC9B,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,iBAAiB,EACvB,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,OAAO,CAST;AAED;;;;;;;;;GASG;AACH,wBAAgB,0BAA0B,CACzC,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,QAAQ,EAAE,iBAAiB,EAC3B,YAAY,EAAE,MAAM,EACpB,KAAK,EAAE,SAAS,iBAAiB,EAAE,EACnC,SAAS,SAAI,EACb,cAAc,CAAC,EAAE,qBAAqB,GACpC,mBAAmB,CASrB"}