ooxml-core 1.1.0 → 1.2.0

package/dist/diagram/layout/smartart-interpreter-fold-text.d.ts

@@ -0,0 +1,75 @@
+/**
+ * Folded-descendant text helpers for the DiagramML interpreter bridge.
+ *
+ * Split out of pptx's `smartart-interpreter-drawing-bridge.ts` (file-size
+ * budget): that module's `interpretedLayoutToElements` and `arrangeLinear`/
+ * `arrangeSnake` (`smartart-layout-interpreter-linear.ts`/`-snake.ts`) both
+ * need to know which descendants fold into a node's own box and what text
+ * they carry; this module is the single source for that.
+ */
+import type { DiagramNode } from '../model/index.js';
+/**
+ * Descendants of `node` that were NOT separately given their own rendered
+ * shape (i.e. not in `renderedIds`), in pre-order, read via `childrenOf`
+ * (`smartArtChildrenOf`: works for both the loader's flat `parentId`
+ * representation and a nested `.children` one). Stops descending into an
+ * already-rendered descendant's own subtree: that descendant's box handles
+ * its own folding independently when the caller processes it in turn.
+ *
+ * This is how a node added one level deeper via the SmartArt text pane's
+ * Tab/"Add Bullet" (real PowerPoint: `axis="ch"` selects only the top-level
+ * box per {@link import('./smartart-layout-interpreter-flow').selectArrangedNodes},
+ * so the deeper node never gets its own box) still reaches the canvas: as an
+ * additional paragraph in its nearest rendered ancestor's box, matching
+ * PowerPoint's own cached drawing (see `smartart-gallery-ground-truth.test.ts`).
+ *
+ * Trims a LEADING/TRAILING run of empty-text (unrendered) descendants but
+ * keeps an INTERIOR one as a blank-paragraph placeholder - the SAME rule
+ * `smartArtDescendantsWithText` (`smartart-node-tree-axis.ts`) uses for the
+ * composite/item-role "des"-axis fold, unified here after a corpus-wide
+ * check (every text-bearing cached shape across all 227 gallery fixtures
+ * whose text contains an interior blank paragraph - 5, across `bubble-
+ * picture-list--hier5`/`meet-the-team--hier8`/`small-dots-horizontal--
+ * hier8`/`text-card-short-line--hier8.pptx` - wants that blank PRESERVED;
+ * none wants it dropped). This module's own PRIOR design deliberately
+ * dropped every empty-text unrendered descendant unconditionally, reasoning
+ * that a structural GROUP-WRAPPER content point (real genuine org charts
+ * insert these between a manager and its reports) would otherwise corrupt
+ * its ancestor's text with a spurious blank paragraph - a real, principled
+ * concern, but one with NO corpus fixture currently measuring it either way
+ * (zero of the 227 fixtures' cached text disagrees with preserving an
+ * interior blank here); the empirical, corpus-wide signal favours ONE
+ * unified rule over two conflicting ones, so this now matches
+ * `smartArtDescendantsWithText` exactly. A GROUP-WRAPPER's own children are
+ * typically ALREADY separately rendered (hierarchy gives every real node
+ * its own box), so they are excluded via `renderedIds` before this trim
+ * ever runs - the wrapper itself only survives the trim when it sits
+ * BETWEEN two other real, unrendered fold entries, which is precisely the
+ * shape PowerPoint's own cached drawing renders as a blank line.
+ */
+export declare function collectFoldedDescendants<N extends DiagramNode>(node: N, renderedIds: Set<string>, childrenOf: Map<string, N[]>): N[];
+/**
+ * `node`'s own text plus any {@link collectFoldedDescendants} text, `\n`-joined
+ * - the SAME combined text PowerPoint's own cached drawing carries in one box
+ * (see `projectFoldedNodeText` below). Exposed for a caller
+ * (`smartart-layout-interpreter-linear.ts`'s `arrangeLinear`/`arrangeSnake`)
+ * that needs to size/fit the SHARED item font against the TRUE rendered text
+ * content of a node whose descendants fold into its own box (a list layout's
+ * `axis="ch"`-selected top-level point with a node added a level deeper via
+ * the text pane's Tab/"Add Bullet"), not just the arranged node's own short
+ * label - measured against `basic-process--hier5.pptx`/`--hier8.pptx`
+ * (`smartart-gallery-ground-truth.test.ts`): the font-fit computed from only
+ * the top-level node's own text is too generous once its folded bullet text
+ * is what actually has to fit the box.
+ */
+export declare function foldedItemText(node: DiagramNode, renderedIds: Set<string>, childrenOf: Map<string, DiagramNode[]>): string;
+/**
+ * Just the {@link collectFoldedDescendants} text, WITHOUT `node`'s own text
+ * prepended - for a caller (`smartart-layout-item-font-tier.ts`) that needs
+ * to size the node's own top-level paragraph and its folded descendants at
+ * two DIFFERENT font sizes rather than `foldedItemText`'s single joined
+ * string. See that module's doc comment for why a folded item's descendant
+ * paragraph renders at a DIFFERENT (smaller) size than the item's own text.
+ */
+export declare function foldedDescendantTexts(node: DiagramNode, renderedIds: Set<string>, childrenOf: Map<string, DiagramNode[]>): string[];
+//# sourceMappingURL=smartart-interpreter-fold-text.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-interpreter-fold-text.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-interpreter-fold-text.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAE5C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AACH,wBAAgB,wBAAwB,CAAC,CAAC,SAAS,WAAW,EAC7D,IAAI,EAAE,CAAC,EACP,WAAW,EAAE,GAAG,CAAC,MAAM,CAAC,EACxB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,CAAC,EAAE,CAAC,GAC1B,CAAC,EAAE,CAqBL;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,cAAc,CAC7B,IAAI,EAAE,WAAW,EACjB,WAAW,EAAE,GAAG,CAAC,MAAM,CAAC,EACxB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,GACpC,MAAM,CAGR;AAED;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CACpC,IAAI,EAAE,WAAW,EACjB,WAAW,EAAE,GAAG,CAAC,MAAM,CAAC,EACxB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,GACpC,MAAM,EAAE,CAIV"}

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

@@ -0,0 +1,25 @@
+/**
+ * DiagramML control-flow attributes (`dgm:forEach`, `dgm:if`, `dgm:presOf`,
+ * all CT_Iterate based) read through an {@link AttributeReader}, so the same
+ * parser serves the pptx object tree and the ordered-XML walkers, plus the
+ * format-neutral validation of the typed model. Extracted from
+ * `pptx/core/utils/smartart-layout-control-flow.ts` (pptx keeps the object
+ * tree child lookup and the writers).
+ */
+import type { AttributeReader } from '../../drawingml/types.js';
+import type { DiagramIteratorAttributes, DiagramLayoutNode, DiagramWhen } from '../model/index.js';
+import type { OrderedXmlElement } from './smartart-choose-xml.js';
+/** Reads an ordered element's attributes by local name. */
+export declare function orderedAttributes(element: OrderedXmlElement): AttributeReader;
+/**
+ * CT_Iterate's shared attribute set (`name`/`ref`/`axis`/`ptType`/
+ * `hideLastTrans`/`st`/`cnt`/`step`), also used verbatim for `dgm:presOf`.
+ */
+export declare function parseIteratorAttributes(read: AttributeReader): DiagramIteratorAttributes;
+/** A `dgm:if` (CT_When), or `undefined` when `func`, `op` or `val` is missing. */
+export declare function parseWhenAttributes<R>(read: AttributeReader, rawXml: R): DiagramWhen<R> | undefined;
+/** A `dgm:if` element of the ordered tree, its raw slot the element itself. */
+export declare function parseOrderedWhen(element: OrderedXmlElement): DiagramWhen<OrderedXmlElement> | undefined;
+/** Range and required-field errors in a layout node's `forEach`/`choose` model. */
+export declare function validateSmartArtControlFlow(node: DiagramLayoutNode): string[];
+//# sourceMappingURL=smartart-layout-control-flow.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-control-flow.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-control-flow.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,uBAAuB,CAAC;AAC7D,OAAO,KAAK,EAAE,yBAAyB,EAAE,iBAAiB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC1F,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,uBAAuB,CAAC;AAyC/D,2DAA2D;AAC3D,wBAAgB,iBAAiB,CAAC,OAAO,EAAE,iBAAiB,GAAG,eAAe,CAE7E;AAED;;;GAGG;AACH,wBAAgB,uBAAuB,CAAC,IAAI,EAAE,eAAe,GAAG,yBAAyB,CAWxF;AAED,kFAAkF;AAClF,wBAAgB,mBAAmB,CAAC,CAAC,EACpC,IAAI,EAAE,eAAe,EACrB,MAAM,EAAE,CAAC,GACP,WAAW,CAAC,CAAC,CAAC,GAAG,SAAS,CAc5B;AAED,+EAA+E;AAC/E,wBAAgB,gBAAgB,CAC/B,OAAO,EAAE,iBAAiB,GACxB,WAAW,CAAC,iBAAiB,CAAC,GAAG,SAAS,CAE5C;AAED,mFAAmF;AACnF,wBAAgB,2BAA2B,CAAC,IAAI,EAAE,iBAAiB,GAAG,MAAM,EAAE,CAgC7E"}

package/dist/diagram/layout/smartart-layout-interpreter-arranged-selection.d.ts

@@ -0,0 +1,56 @@
+/**
+ * SmartArt DiagramML interpreter - top-level point selection + hub
+ * detection for `runArrangement`.
+ *
+ * Split out of `smartart-layout-interpreter.ts` (the repo's per-file line
+ * budget): resolves which data-model points `dispatchArrangement` actually
+ * arranges, including the "hub + satellites" nested-forEach expansion (a
+ * container point whose OWN children a NESTED forEach arranges - see
+ * `smartart-layout-interpreter-hub.ts`). Pure TypeScript - no framework
+ * code, no DOM.
+ */
+import type { DiagramNode } from '../model/index.js';
+import type { DiagramConnection } from '../types.js';
+import type { HubExpansion } from './smartart-layout-interpreter-hub.js';
+import type { ArrangementPlan } from './smartart-layout-interpreter-model.js';
+import type { RawXmlView } from './smartart-choose-xml.js';
+export interface ArrangedSelection {
+    childrenOf: Map<string, DiagramNode[]>;
+    hub: HubExpansion | undefined;
+    arranged: DiagramNode[];
+}
+/**
+ * Resolve the points `dispatchArrangement` arranges, and the hub expansion
+ * (if any) so the caller can build the hub's own rendered node separately.
+ *
+ * A top-level `composite` arranger (`gear`, `balance`) maps its NAMED slots
+ * onto the top-level points directly via each slot's OWN `presOf` (see
+ * `arrangeComposite`'s module doc comment); it typically declares several
+ * SEPARATE single-point `forEach`s (one per slot, e.g. `gear2`'s own
+ * `st="2" cnt="1"`), which `selectArrangedNodes`'s single "driving iterator"
+ * model was never built to combine, so it is bypassed here in favour of the
+ * plain top-level point list every slot's ordinal position already indexes
+ * into. Known gap: a composite with SEVEN independent single-point
+ * `forEach`s, one per named "ring" slot (`target-list`'s concentric rings)
+ * still needs a real multi-forEach walk - see the Track S/R handoff notes
+ * for the exact diagnosis.
+ *
+ * ROUND 42: hub detection is skipped entirely for a `composite` plan - its
+ * children are named SLOTS, not ring satellites, and `detectHubExpansion`'s
+ * raw-XML shape check can wrongly match the composite's own root (`Name0`)
+ * as a hub+satellite ring.
+ *
+ * `hub.satellites` (`smartArtChildrenOf`, built from flat `parentId`
+ * pointers) is in `dgm:ptLst` declaration order, which is NOT necessarily
+ * true ring order - the SAME class of bug `buildChildOrder`/
+ * `applyChildOrder` already fixes for `arrangeHierarchy` (see their doc
+ * comments), reused verbatim here: every satellite shares the SAME parent
+ * (the hub), so `applyChildOrder`'s same-parent-only scoping is trivially
+ * satisfied and this is a plain, safe sort by `dgm:cxn`'s own `srcOrd`.
+ * COM-verified regression against `basic-radial--hier5.pptx`/
+ * `diverging-radial--hier5.pptx`: without this, satellites landed at the
+ * wrong ring position (rotated relative to the cached drawing) even though
+ * their SIZE already matched after `resolveHubToNodeRatio`.
+ */
+export declare function selectArrangedPoints(view: RawXmlView<unknown>, plan: ArrangementPlan, nodes: DiagramNode[], flat: DiagramNode[], connections: DiagramConnection[] | undefined): ArrangedSelection;
+//# sourceMappingURL=smartart-layout-interpreter-arranged-selection.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-arranged-selection.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-arranged-selection.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC5C,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAKlD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,mCAAmC,CAAC;AACtE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAE3E,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAExD,MAAM,WAAW,iBAAiB;IACjC,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,CAAC;IACvC,GAAG,EAAE,YAAY,GAAG,SAAS,CAAC;IAC9B,QAAQ,EAAE,WAAW,EAAE,CAAC;CACxB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,wBAAgB,oBAAoB,CACnC,IAAI,EAAE,UAAU,CAAC,OAAO,CAAC,EACzB,IAAI,EAAE,eAAe,EACrB,KAAK,EAAE,WAAW,EAAE,EACpB,IAAI,EAAE,WAAW,EAAE,EACnB,WAAW,EAAE,iBAAiB,EAAE,GAAG,SAAS,GAC1C,iBAAiB,CAiBnB"}

package/dist/diagram/layout/smartart-layout-interpreter-arrangement-kind.d.ts

@@ -0,0 +1,37 @@
+/**
+ * SmartArt DiagramML interpreter - arrangement-kind types/constants.
+ *
+ * Split out of `smartart-layout-interpreter-model.ts` (the file-size budget):
+ * `ArrangementKind`/`ArrangementPlan`/`PRIMARY_ALG`/`STRUCTURAL_ARRANGEMENT_KINDS`/
+ * `isMeaningfulAux`, re-exported from that module so every existing import
+ * site is unaffected. Pure types/constants; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+/** Arrangement families the interpreter can execute. */
+export type ArrangementKind = 'linear' | 'cycle' | 'hierarchy' | 'pyramid' | 'snake' | 'composite' | 'conn' | 'spacer' | 'text';
+/** The arranger `layoutNode` plus the resolved arrangement family. */
+export interface ArrangementPlan<R = unknown> {
+    kind: ArrangementKind;
+    /** The `layoutNode` carrying the arrangement algorithm + its constraints. */
+    node: DiagramLayoutNode<R>;
+}
+/** Map a non-hierarchy `dgm:alg` type to an arrangement family. */
+export declare const PRIMARY_ALG: Readonly<Record<string, ArrangementKind>>;
+/**
+ * Kinds driven by a real point-flow algorithm (preferred over conn/sp/tx),
+ * and where every arranged point gets its own item box from a shared
+ * per-item template - so `smartart-layout-interpreter-item-roles.ts`'s
+ * multi-role expansion (a list layout's `childText`, a card layout's
+ * `roleText`/`bodyText`, ...) applies uniformly to all four. `hierarchy` and
+ * `composite` are excluded: hierarchy gives each node's own box independent
+ * per-depth treatment, and a top-level `composite` arranger maps points 1:1
+ * onto EXPLICIT named slots rather than repeating one item template.
+ */
+export declare const STRUCTURAL_ARRANGEMENT_KINDS: Set<ArrangementKind>;
+/**
+ * True when a `conn`/`sp`/`tx` node carries enough to arrange as a standalone
+ * primary (constraints or children). A bare leaf is meaningless on its own, so
+ * the interpreter declines and the caller keeps its legacy approximation.
+ */
+export declare function isMeaningfulAux(node: DiagramLayoutNode): boolean;
+//# sourceMappingURL=smartart-layout-interpreter-arrangement-kind.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-arrangement-kind.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-arrangement-kind.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAElD,wDAAwD;AACxD,MAAM,MAAM,eAAe,GACxB,QAAQ,GACR,OAAO,GACP,WAAW,GACX,SAAS,GACT,OAAO,GACP,WAAW,GACX,MAAM,GACN,QAAQ,GACR,MAAM,CAAC;AAEV,sEAAsE;AACtE,MAAM,WAAW,eAAe,CAAC,CAAC,GAAG,OAAO;IAC3C,IAAI,EAAE,eAAe,CAAC;IACtB,6EAA6E;IAC7E,IAAI,EAAE,iBAAiB,CAAC,CAAC,CAAC,CAAC;CAC3B;AAED,mEAAmE;AACnE,eAAO,MAAM,WAAW,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,eAAe,CAAC,CASjE,CAAC;AAEF;;;;;;;;;GASG;AACH,eAAO,MAAM,4BAA4B,sBAKvC,CAAC;AAEH;;;;GAIG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,iBAAiB,GAAG,OAAO,CAEhE"}

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

@@ -0,0 +1,66 @@
+/**
+ * SmartArt DiagramML interpreter - auxiliary arrangers (`conn` / `sp` / `tx`).
+ *
+ * These cover the three "leaf / glue" algorithms that appear inside composite
+ * DiagramML layout definitions. They are intentionally best-effort standalone
+ * passes for the interpreter, which arranges the flat data-model points
+ * linearly rather than running the full recursive constraint solver:
+ *
+ *   - `tx`   (text):      a single node that fills the whole parent region with
+ *                         the point's text. Degenerate but real - it is the leaf
+ *                         of a composite where an outer arranger has already
+ *                         chosen the region. On its own it renders one filling
+ *                         rect for the first point.
+ *   - `sp`   (space):     a spacer that consumes layout space but draws nothing.
+ *                         We return an empty (but valid) result: zero nodes and
+ *                         zero connectors. See `arrangeSpacer` for the rationale.
+ *   - `conn` (connector): connector shapes drawn between sibling nodes. Faithful
+ *                         connector geometry needs the primary arrangement's
+ *                         resolved positions; standalone we arrange the points
+ *                         linearly (via the `lin` arranger) and link consecutive
+ *                         rects with arrowed paths, honouring `linDir` plus the
+ *                         connector's own `begSty`/`endSty`/`connRout`/`bendPt`/
+ *                         `dim` params (see `smartart-layout-interpreter-conn-path.ts`).
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+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';
+import type { RawXmlView } from './smartart-choose-xml.js';
+/**
+ * Execute the `conn` algorithm: arrange the points linearly and draw a
+ * connector between each consecutive pair (N nodes -> N-1 connectors), honouring
+ * `begSty`/`endSty` (arrowhead presence), `connRout` (straight/bend/curve),
+ * `dim` (facing-edge vs centre-to-centre routing), and `linDir` ordering.
+ *
+ * Limitation: this is a standalone best-effort pass. A real `conn` node draws
+ * against positions computed by the sibling arranger; without that shared
+ * geometry we re-run the linear arrangement here. `presLayoutVars` direction is
+ * not threaded through this signature, so only `linDir` reversal is honoured.
+ * `bendPt`'s finer corner-routing variants collapse to one fixed midpoint elbow
+ * (see `smartart-layout-interpreter-conn-path.ts`'s module doc).
+ */
+export declare function arrangeConn(view: RawXmlView<unknown>, plan: ArrangementPlan, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, index?: ConstraintIndex): SmartArtLayoutResult | undefined;
+/**
+ * Execute the `sp` algorithm: a spacer that reserves layout space but draws
+ * nothing.
+ *
+ * Choice: we return a valid, empty `SmartArtLayoutResult` (no nodes, no
+ * connectors) rather than a transparent placeholder rect or `undefined`. The
+ * spacer is genuinely "applicable" (it is a recognised algorithm), so declining
+ * with `undefined` would wrongly send the caller to the legacy family
+ * approximation; emitting an invisible placeholder would add a stray hit-target
+ * and complicate node indexing. An empty result cleanly represents "consumed
+ * space, nothing drawn".
+ */
+export declare function arrangeSpacer(_plan: ArrangementPlan, _nodes: DiagramNode[], box: BoundingBox, _palette: string[], style: DiagramStyleIntensity, _elementId: string): SmartArtLayoutResult | undefined;
+/**
+ * Execute the `tx` algorithm: a single node filling the parent region with the
+ * point's text. Only the first point is placed (composite `tx` leaves describe
+ * one region). Returns `undefined` when there is no point to render.
+ */
+export declare function arrangeText(plan: ArrangementPlan, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, index?: ConstraintIndex, childrenOf?: Map<string, DiagramNode[]>, fontName?: string): SmartArtLayoutResult | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-aux.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-aux.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-aux.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,OAAO,KAAK,EAAqB,WAAW,EAAE,MAAM,UAAU,CAAC;AAC/D,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAUpE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAI3E,OAAO,KAAK,EACX,WAAW,EAGX,oBAAoB,EACpB,MAAM,yBAAyB,CAAC;AACjC,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,uBAAuB,CAAC;AAcxD;;;;;;;;;;;;GAYG;AACH,wBAAgB,WAAW,CAC1B,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,GAAE,eAAwC,GAC7C,oBAAoB,GAAG,SAAS,CA2BlC;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,aAAa,CAC5B,KAAK,EAAE,eAAe,EACtB,MAAM,EAAE,WAAW,EAAE,EACrB,GAAG,EAAE,WAAW,EAChB,QAAQ,EAAE,MAAM,EAAE,EAClB,KAAK,EAAE,qBAAqB,EAC5B,UAAU,EAAE,MAAM,GAChB,oBAAoB,GAAG,SAAS,CASlC;AAED;;;;GAIG;AACH,wBAAgB,WAAW,CAC1B,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,UAAU,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,EACvC,QAAQ,CAAC,EAAE,MAAM,GACf,oBAAoB,GAAG,SAAS,CAmDlC"}

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

@@ -0,0 +1,128 @@
+/**
+ * SmartArt DiagramML interpreter - ECMA-376 21.4.7.5 compound `@axis`
+ * navigation for `dgm:if/@func="cnt"`.
+ *
+ * Split out of `smartart-layout-interpreter-when.ts` (the file-size budget):
+ * `evaluateWhen`'s `cnt` case calls {@link resolveAxisCount} here when a
+ * `dgm:if` needs real tree navigation (a compound `@axis` list, or a single
+ * hop with its own `@st`/`@cnt`) rather than a bare node count - see that
+ * function's own doc comment for the derivation and the fixture that needed
+ * it (`basic-radial--hier5.pptx`'s `axis="ch ch" ptType="node node" st="1 1"
+ * cnt="1 0"` `stAng` choose).
+ *
+ * Pure tree navigation; no framework code.
+ */
+import type { DiagramNode } from '../model/index.js';
+/**
+ * ECMA-376 21.4.7.5's compound axis navigation: `axis`/`ptType`/`st`/`cnt`
+ * are PARALLEL lists, one entry per hop, applied pairwise in order -
+ * `axis="ch ch" ptType="node node" st="1 1" cnt="1 0"` means "from the
+ * diagram root: take child 1 (`ch`, `st=1 cnt=1`), then ALL of that point's
+ * own children (`ch`, `st=1 cnt=0` = unbounded)" - general over any axis
+ * list length, not a special case for exactly two `"ch"` hops (a single bare
+ * `axis="ch"` with its own `st`/`cnt`, or a 3+-hop chain, go through the
+ * SAME loop).
+ *
+ * Hop 0's starting point has TWO modes:
+ *
+ * - `context` supplied: hop 0 navigates from that explicit ANCHOR point set
+ *   via {@link navigateAxisHop}, accepting every single-hop axis token the
+ *   spec defines (`self`/`ch`/`des`/`desOrSelf`/`par`/`ancst`/`ancstOrSelf`/
+ *   `followSib`/`precedSib`/`follow`/`preced`/`none`) - needed for a
+ *   `presOf`/`dgm:if` reached through a `dgm:forEach` (a node's own
+ *   {@link DiagramLayoutNode.forEachOrigin}), where content is scoped
+ *   to ONE specific point, not the whole diagram (`Phased Process`'s
+ *   `circ1Tx`, `presOf axis="desOrSelf"`, is anchored one hop up by its
+ *   `forEachOrigin`'s `axis="ch ch" st="2 1" cnt="1 1"` - "point 2's first
+ *   child" - so `desOrSelf` there must resolve relative to THAT point).
+ *   EXCEPT `root`: an explicit `root` hop 0 always opts OUT of anchor-
+ *   relative navigation and resolves exactly as the `context`-omitted case
+ *   below does, `context` or not - `navigateAxisHop` has no relative
+ *   reading for `root` at all (it is only ever meaningful root-relatively),
+ *   and a node CAN legitimately have both its own `forEachOrigin` (for its
+ *   OWN box's identity/position) and a `root`-starting presOf (for content
+ *   explicitly scoped to the whole diagram, not that anchor) - `funnel--
+ *   flat3.pptx`'s `item1..3`, each reached through its own single-point
+ *   `forEachOrigin` (`axis="ch" st="2"/"3"/"4" cnt="1"`) but with presOf
+ *   `axis="root ch desOrSelf"`.
+ * - `context` omitted (the pre-existing default, used by every caller before
+ *   this parameter existed): hop 0 is root-relative, and `ch`/`self`/`root`
+ *   are decidable there - every other token returns `undefined`
+ *   (undecidable), exactly as before. This is deliberately NOT generalised
+ *   the way the `context`-supplied path is: the diagram's own document root
+ *   is not itself a member of `nodes` in this codebase's data model, so a
+ *   bare, un-anchored `des`/`desOrSelf`/... has no single correct reading,
+ *   and guessing one (this was tried and reverted - see git history)
+ *   silently changed `dgm:if/func="cnt"` guard decisions gallery-wide,
+ *   regressing `basic-venn` and 17 other fixtures at once by resolving a
+ *   `desOrSelf`-anchored content slot that was supposed to stay undecided
+ *   (and fall through to a DIFFERENT, correct resolution path) into a wrong,
+ *   over-eager "every node in the diagram" answer instead. A caller that
+ *   legitimately needs a scoped answer for one of those tokens must supply
+ *   `context` explicitly.
+ *   - `ch`/`self` at hop 0 both yield the diagram's own top-level points
+ *     (`roots`) - this codebase's data model never carries the actual
+ *     document/`doc`-typed point `self` would otherwise mean, so both
+ *     tokens collapse to the same "start from the top" reading.
+ *   - `root` at hop 0, USED ALONE, means exactly the same thing (`roots`) -
+ *     ECMA-376's `root` axis means "the topmost ancestor", and root-
+ *     relatively (no anchor) that topmost ancestor IS the diagram's own
+ *     document node, whose own top-level point list is `roots`.
+ *   - `root` COMPOUNDED with an immediately-following `ch` (`axis="root
+ *     ch..."`, the ONLY compound shape measured against real fixtures -
+ *     `nested-target--hier5.pptx`'s `outerBox`/`middleBox`/`centerBox`
+ *     guards, `basic-venn--hier5.pptx`'s `circ1TxSh` guard) means "the
+ *     document node, then ITS children" - since the document node is not a
+ *     real member of `nodes`, `ch` here is not a real tree-hop (there is
+ *     nothing in `childrenOf` to hop from); it is ABSORBED into the `root`
+ *     read itself, and the pair together STILL means exactly `roots` -
+ *     COM-verified: `basic-venn--hier5.pptx` (3 top-level points, 2 of which
+ *     have a child each) has `resolveAxisNodes(flat, ['root','ch'], ['all',
+ *     'node'])` correctly returning length 3 (the top-level COUNT), not the
+ *     5 a fallback `flat.length` denominator gives NOR the 2 a real
+ *     "children of the top-level points" hop would give; `nested-target`'s
+ *     single top-level point ("Node One", with 3 children of its own) needs
+ *     the SAME `root ch` shape to read 1 (not 3), or its three concentric-
+ *     ring `dgm:if`/@func="cnt"` thresholds (`>= 1`/`>= 2`/`>= 3`) cannot
+ *     discriminate at all. `ch`'s own `@ptType`/`@st`/`@cnt` (the compound's
+ *     SECOND hop) still applies, to the FULL `roots` list (`root`'s own hop
+ *     is a true no-op: the document is always exactly one node, so its own
+ *     `@st`/`@cnt` never meaningfully narrows anything real fixtures use).
+ *     A `root` compounded with anything OTHER than an immediately-following
+ *     `ch` (e.g. a hypothetical `axis="root des"`) is left exactly as
+ *     undecidable as before this change - not measured against any fixture,
+ *     and extending the same "absorb the next hop" reading to `des`/
+ *     `desOrSelf` is the SAME "every node in the diagram" trap the reverted
+ *     generalisation above hit.
+ *
+ * Returns `undefined` (undecidable) when `axis` is empty, or (with no
+ * `context`) hop 0 is none of `ch`/`self`/`root`, or hop 0 is `root`
+ * compounded with anything other than a following `ch`; a recognised-but-
+ * empty hop (a leaf's `ch`, or an anchored `desOrSelf` set that resolved to
+ * nothing) is a real empty array, not undecidable. Exported (not just
+ * `resolveAxisCount`'s own count) for `smartart-layout-interpreter-
+ * composite-choose.ts` and `smartart-layout-interpreter-composite-
+ * foreach.ts`'s content resolution, which need the actual resolved NODES,
+ * not just how many.
+ */
+export declare function resolveAxisNodes<N extends DiagramNode>(nodes: N[], axis: string[], pointTypes: string[] | undefined, start: number[] | undefined, count: number[] | undefined, context?: N[]): N[] | undefined;
+/**
+ * `resolveAxisCount`'s own callers (`dgm:if/@func="cnt"` evaluation) only
+ * need the resolved COUNT - see {@link resolveAxisNodes} for the full
+ * derivation, shared verbatim.
+ *
+ * `context` is the same anchor-point-set parameter `resolveAxisNodes` (and,
+ * since round 13, `resolveAxisMaxDepth`) already accepts: when supplied, hop
+ * 0 navigates from that explicit anchor rather than the diagram root. A
+ * `dgm:choose` living INSIDE a nested composite slot (reached through its own
+ * `forEachOrigin`, not the diagram's top level) needs this to answer its own
+ * `cnt` predicates against ITS anchor's children, not the diagram's few (or
+ * one) top-level points - see `evaluateWhen`'s `cnt` case
+ * (`smartart-layout-interpreter-when.ts`) for the call site and the fixture
+ * (`radial-cluster--hier5.pptx`) that needs it. Omitted (the pre-existing
+ * default, every caller before this parameter existed) keeps the exact prior
+ * root-relative behaviour - no regression for a caller with no anchor to
+ * offer.
+ */
+export declare function resolveAxisCount(nodes: DiagramNode[], axis: string[], pointTypes: string[] | undefined, start: number[] | undefined, count: number[] | undefined, context?: DiagramNode[]): number | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-axis-count.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-axis-count.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-axis-count.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAiE5C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2FG;AACH,wBAAgB,gBAAgB,CAAC,CAAC,SAAS,WAAW,EACrD,KAAK,EAAE,CAAC,EAAE,EACV,IAAI,EAAE,MAAM,EAAE,EACd,UAAU,EAAE,MAAM,EAAE,GAAG,SAAS,EAChC,KAAK,EAAE,MAAM,EAAE,GAAG,SAAS,EAC3B,KAAK,EAAE,MAAM,EAAE,GAAG,SAAS,EAC3B,OAAO,CAAC,EAAE,CAAC,EAAE,GACX,CAAC,EAAE,GAAG,SAAS,CA0EjB;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,gBAAgB,CAC/B,KAAK,EAAE,WAAW,EAAE,EACpB,IAAI,EAAE,MAAM,EAAE,EACd,UAAU,EAAE,MAAM,EAAE,GAAG,SAAS,EAChC,KAAK,EAAE,MAAM,EAAE,GAAG,SAAS,EAC3B,KAAK,EAAE,MAAM,EAAE,GAAG,SAAS,EAC3B,OAAO,CAAC,EAAE,WAAW,EAAE,GACrB,MAAM,GAAG,SAAS,CAEpB"}

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

@@ -0,0 +1,73 @@
+/**
+ * SmartArt DiagramML interpreter - ECMA-376 21.4.7.5 `dgm:if/@func="maxDepth"`
+ * axis-aware, anchor-relative depth measurement.
+ *
+ * Split out of `smartart-layout-interpreter-when.ts` (the file-size budget):
+ * `evaluateWhen`'s `maxDepth` case calls {@link resolveAxisMaxDepth} here when
+ * a `dgm:if` declares its own `@axis` and the caller supplies an ANCHOR point
+ * set to navigate it from - the SAME generalisation `smartart-layout-
+ * interpreter-axis-count.ts`'s `resolveAxisCount` already makes for
+ * `func="cnt"` (root- or anchor-relative real tree navigation instead of a
+ * flat, context-blind number), applied here to "how many tree levels deep
+ * does this hop reach, counted from the anchor" instead of "how many points
+ * does this hop reach".
+ *
+ * Derivation: `radial-cluster--hier5.pptx`'s own `Name40` (`<dgm:if
+ * axis="des" func="maxDepth" op="lte" val="1">`, nested inside a `dgm:forEach
+ * axis="ch" cnt="1"` binding the diagram's sole top-level point, "Node One",
+ * as anchor - captured as that layout node's `forEachOrigin`) needs "how deep
+ * does Node One's own descendant tree go" (2: Node One -> Four -> Five, so
+ * the `lte 1` guard is false and the diagram must take the OTHER `dgm:choose`
+ * branch), NOT "how deep is the LAYOUT DEFINITION's own `dgm:layoutNode` XML
+ * nesting" - what `smartart-layout-interpreter-tree-location.ts`'s
+ * `treeMaxDepth` measures, and the ONLY source `discoverArrangement`
+ * (`smartart-layout-interpreter-model.ts`) had for `WhenContext.maxDepth`
+ * before this module existed. Those are two unrelated numbers that happen to
+ * share a name: one is a property of the layoutDef's own XML shape (constant
+ * for a given layout, independent of the diagram's real data), the other a
+ * property of the diagram's actual data tree, anchored at the point a
+ * `dgm:forEach` bound. Confusing them makes `func="maxDepth"` either
+ * undecidable (defaulting to "allow" wherever a caller does not even attempt
+ * `context.maxDepth`, e.g. every `dgm:choose`-guarded composite slot today)
+ * or, worse, decidable but WRONG (a constant unrelated to the real tree
+ * shape, silently deciding the branch the same way for every dataset).
+ *
+ * NOT YET WIRED into production `dgm:choose` resolution as of this module's
+ * introduction: the two real call sites that decide `singleCycle` vs
+ * `textCenter`/`cycle_N` for `radial-cluster--hier5.pptx`
+ * (`guardAllows`, `smartart-layout-interpreter-composite-choose.ts`, and
+ * `winningOrdinalFor`, `smartart-layout-interpreter-composite-choose-
+ * groups.ts`) both call `evaluateWhen` with no anchor at all today
+ * (`{ nodes: flat }`), so this mechanism stays dormant for every existing
+ * caller until one of those (composite-owned, outside this module's own
+ * structural-interpreter ownership) threads a resolved anchor through - see
+ * the round 13 successor doc (`smartart-track-s-successor-round13.md` in the
+ * scratchpad) for the exact diff. Landed anyway, ahead of that wiring,
+ * because it is a genuine, independently-testable, zero-regression-risk unit
+ * (no existing caller populates `WhenContext.anchor`, so behaviour is
+ * unchanged everywhere until one does).
+ *
+ * Pure tree navigation; no framework code.
+ */
+import type { DiagramNode } from '../model/index.js';
+/**
+ * ECMA-376 `dgm:if/@func="maxDepth"`: the deepest level reached by the
+ * `@axis`-resolved point set, counted from `anchor` (the enclosing
+ * `dgm:forEach`'s own bound point(s) - see `DiagramLayoutNode.
+ * forEachOrigin`, the SAME anchor {@link resolveAxisNodes}'s own `context`
+ * parameter already threads through for `des`/`desOrSelf`/etc navigation
+ * reached through a forEach). `anchor` is a set (mirroring `resolveAxisNodes`
+ * itself) because a multi-point `forEachOrigin` (an unbounded second hop)
+ * can bind more than one point at once; the returned depth is the MAXIMUM
+ * across every anchor point's own resolved set.
+ *
+ * Returns `undefined` (undecidable) when `anchor` is empty (nothing to
+ * navigate from at all), or exactly when {@link resolveAxisNodes} itself
+ * would for this `axis` (an unrecognised token, or - deliberately, see that
+ * function's own doc comment - a bare non-`root` axis with no anchor at all)
+ * - a caller with nothing to navigate keeps its pre-existing fallback. A
+ * REAL, non-empty anchor whose own axis-resolved set is empty (a childless
+ * point) is a real, decidable `0` - not undecidable.
+ */
+export declare function resolveAxisMaxDepth(nodes: DiagramNode[], axis: string[], pointTypes: string[] | undefined, start: number[] | undefined, count: number[] | undefined, anchor: DiagramNode[]): number | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-axis-depth.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-axis-depth.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-axis-depth.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAgC5C;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,mBAAmB,CAClC,KAAK,EAAE,WAAW,EAAE,EACpB,IAAI,EAAE,MAAM,EAAE,EACd,UAAU,EAAE,MAAM,EAAE,GAAG,SAAS,EAChC,KAAK,EAAE,MAAM,EAAE,GAAG,SAAS,EAC3B,KAAK,EAAE,MAAM,EAAE,GAAG,SAAS,EAC3B,MAAM,EAAE,WAAW,EAAE,GACnB,MAAM,GAAG,SAAS,CAmBpB"}

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

@@ -0,0 +1,48 @@
+/**
+ * SmartArt DiagramML interpreter - ECMA-376 21.4.7.5 single-hop `@axis`
+ * navigation.
+ *
+ * Split out of `smartart-layout-interpreter-axis-count.ts` (the repo's
+ * per-file line budget): {@link navigateAxisHop} is the tree-walk primitive
+ * one `@axis` hop uses; `resolveAxisNodes` there chains it hop by hop, from
+ * either the diagram's own top-level points (the pre-existing, root-relative
+ * default) or an explicit ANCHOR point set (a node's own `forEachOrigin`,
+ * for content genuinely scoped to one specific point rather than the whole
+ * diagram - see that function's own doc comment). Pure tree navigation; no
+ * framework code.
+ */
+import type { DiagramNode } from '../model/index.js';
+/**
+ * One `@axis` hop (ECMA-376 21.4.7.5's `ST_AxisType`) from every point in
+ * `current`, unioned in DOCUMENT order with duplicates dropped (several
+ * `current` points can share an ancestor/descendant/sibling). Implements
+ * every single-hop axis token the spec defines: `self`/`ch`/`des`/
+ * `desOrSelf`/`par`/`ancst`/`ancstOrSelf`/`followSib`/`precedSib`/`follow`/
+ * `preced`/`root`/`none`. The `...OrSelf` pair is the standard XPath UNION
+ * reading ECMA-376's axis vocabulary is modelled on - `desOrSelf` is the
+ * point ITSELF plus every descendant (self always first, so a caller that
+ * treats the first entry as "primary" and the rest as folded-in extras gets
+ * the right shape), `ancstOrSelf` is the point plus every ancestor - NOT
+ * "descendants, falling back to self when there are none" (a reading this
+ * function used, briefly, and reverted: it dropped the anchor's OWN text
+ * whenever it had a descendant). COM-verified via `basic-venn--hier5.pptx`'s
+ * `circ1Tx` (`presOf axis="desOrSelf"`, anchored one hop up by its own
+ * `forEachOrigin`): a point WITH a child folds BOTH its own text and the
+ * child's into one shape (`"Node One\nNode Two has a longer label"`), a
+ * childless point renders just its own text (`desOrSelf` degenerates to
+ * `self` exactly when there is nothing to union in) - never the child's text
+ * ALONE.
+ * `follow`/`preced` use `nodes`' own declaration order (`dgm:ptLst` order) as
+ * document order, excluding a point's own descendants (for `follow`) or
+ * ancestors (for `preced`) the way ECMA-376's XPath-derived axes do. `root`
+ * resolves to the TOPMOST ancestor of each `current` point (walking
+ * `parentOf` all the way up), or the point itself when it has none - the
+ * diagram's own document root is not itself a member of `nodes` in this
+ * codebase's data model, so there is no literal doc-typed point to return
+ * for a bare top-level `root` hop; this is a reasonable, spec-consistent
+ * approximation for the ONE shape actually reachable (`root` used deeper
+ * than hop 0, from a real anchored point). `none` is always empty (ECMA's
+ * own explicit "no navigation" token).
+ */
+export declare function navigateAxisHop<N extends DiagramNode>(current: N[], axis: string, nodes: N[], childrenOf: Map<string, N[]>, parentOf: Map<string, N>, roots: N[]): N[];
+//# sourceMappingURL=smartart-layout-interpreter-axis-hop.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-axis-hop.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-axis-hop.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAuC5C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,wBAAgB,eAAe,CAAC,CAAC,SAAS,WAAW,EACpD,OAAO,EAAE,CAAC,EAAE,EACZ,IAAI,EAAE,MAAM,EACZ,KAAK,EAAE,CAAC,EAAE,EACV,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,CAAC,EAAE,CAAC,EAC5B,QAAQ,EAAE,GAAG,CAAC,MAAM,EAAE,CAAC,CAAC,EACxB,KAAK,EAAE,CAAC,EAAE,GACR,CAAC,EAAE,CA6EL"}

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

@@ -0,0 +1,19 @@
+/**
+ * SmartArt DiagramML interpreter - `dgm:presOf`/`dgm:forEach` 1-based
+ * position-range resolution.
+ *
+ * Shared by `smartart-layout-interpreter-composite-children.ts` (a bare
+ * composite wrapper slot's per-child item templates, e.g. `Table List`'s
+ * `pillar1`/`pillarX`) and `smartart-layout-interpreter-item-role-compound.ts`
+ * (a compound `presOf axis="ch desOrSelf"` role, e.g. `Tab List`'s
+ * `FirstChild`/`Child`): both need the exact same `start`/`count`/`step`
+ * position math over a `total`-length list. Pure TypeScript - no framework
+ * code.
+ */
+/**
+ * 1-based positions into a `total`-length list an iterator's `start`/`count`/
+ * `step` resolves to. `count` of `undefined`/`0` means "every remaining
+ * position" (DiagramML default).
+ */
+export declare function positionRange(start: number, count: number | undefined, step: number, total: number): number[];
+//# sourceMappingURL=smartart-layout-interpreter-axis-range.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-axis-range.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-axis-range.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;GAWG;AAEH;;;;GAIG;AACH,wBAAgB,aAAa,CAC5B,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,GAAG,SAAS,EACzB,IAAI,EAAE,MAAM,EACZ,KAAK,EAAE,MAAM,GACX,MAAM,EAAE,CAUV"}