ooxml-core 1.1.0 → 1.2.0

package/dist/diagram/layout/smartart-layout-interpreter-connector-order.d.ts

@@ -0,0 +1,23 @@
+/**
+ * SmartArt DiagramML interpreter - `dgm:cxn`-derived connector labels and
+ * child order.
+ *
+ * Split out of `smartart-layout-interpreter.ts` (the repo's per-file line
+ * budget): two small, pure lookups built from the data model's `dgm:cxn`
+ * connections, consumed by `runArrangement` there and by `arrangeHierarchy`.
+ * Pure TypeScript - no framework code, no DOM.
+ */
+import type { DiagramConnection } from '../types.js';
+/** Build `${parentId}>${childId} -> label` from labelled `parOf` connections. */
+export declare function buildConnectorLabels(connections: DiagramConnection[] | undefined): Map<string, string> | undefined;
+/**
+ * Build `childId -> srcOrd` from `parOf` connections. `arrangeHierarchy`'s
+ * flat `nodes` array is in `dgm:ptLst` declaration order, which is NOT
+ * necessarily left-to-right sibling order - the `dgm:cxn`'s own `srcOrd`
+ * (`DiagramConnection.srcOrd`) is (COM-verified against
+ * `hierarchy--hier8.pptx`: 5 siblings' `ptLst` order does not match their
+ * cached left-to-right rendering order, but sorting by `srcOrd` reproduces
+ * it exactly). See `arrangeHierarchy`'s own doc comment for how this is used.
+ */
+export declare function buildChildOrder(connections: DiagramConnection[] | undefined): Map<string, number> | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-connector-order.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-connector-order.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-connector-order.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAElD,iFAAiF;AACjF,wBAAgB,oBAAoB,CACnC,WAAW,EAAE,iBAAiB,EAAE,GAAG,SAAS,GAC1C,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,SAAS,CAejC;AAED;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAC9B,WAAW,EAAE,iBAAiB,EAAE,GAAG,SAAS,GAC1C,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,SAAS,CAYjC"}

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

@@ -0,0 +1,28 @@
+/**
+ * SmartArt DiagramML interpreter - constraint/ratio resolution helpers.
+ *
+ * Split out of `smartart-layout-interpreter-model.ts` (which was pushing past
+ * the file-size guideline): these read `dgm:constr` entries off a parsed
+ * layoutNode and resolve them to a scalar ratio, independent of the
+ * arrangement-discovery logic that stayed behind. Pure TypeScript - no
+ * framework code, no DOM.
+ */
+import type { DiagramConstraint, DiagramNumericRule } from '../model/index.js';
+/** Find the first constraint of `type`, optionally restricted to a relationship. */
+export declare function findConstraint<C extends DiagramConstraint>(constraints: C[] | undefined, type: string, forRel?: DiagramConstraint['for']): C | undefined;
+/** Clamp a ratio to a matching `dgm:ruleLst` numeric rule's `max`, when present. */
+export declare function clampByRules(value: number, rules: DiagramNumericRule[] | undefined, type: string): number;
+/**
+ * Resolve a spacing/padding constraint to a *ratio* of the item extent.
+ *
+ * DiagramML commonly expresses sibling spacing and padding as a factor of a
+ * referenced dimension, e.g. `<dgm:constr type="sibSp" refType="w" fact="0.1"/>`.
+ * We surface that factor directly. When only a small absolute `val` (< 1) is
+ * present we treat it as a ratio too; otherwise the caller's default is used.
+ *
+ * A `for="ch"` constraint (the child-scoped form real diagrams use for sibling
+ * spacing / padding) is preferred over an unscoped one, and the result is capped
+ * by any matching `dgm:ruleLst` numeric rule `max` when `rules` is supplied.
+ */
+export declare function ratioConstraint(constraints: DiagramConstraint[] | undefined, types: readonly string[], fallback: number, rules?: DiagramNumericRule[]): number;
+//# sourceMappingURL=smartart-layout-interpreter-constraints.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-constraints.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-constraints.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,kBAAkB,EAAE,MAAM,UAAU,CAAC;AAEtE,oFAAoF;AACpF,wBAAgB,cAAc,CAAC,CAAC,SAAS,iBAAiB,EACzD,WAAW,EAAE,CAAC,EAAE,GAAG,SAAS,EAC5B,IAAI,EAAE,MAAM,EACZ,MAAM,CAAC,EAAE,iBAAiB,CAAC,KAAK,CAAC,GAC/B,CAAC,GAAG,SAAS,CAIf;AAkBD,oFAAoF;AACpF,wBAAgB,YAAY,CAC3B,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,kBAAkB,EAAE,GAAG,SAAS,EACvC,IAAI,EAAE,MAAM,GACV,MAAM,CAMR;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,eAAe,CAC9B,WAAW,EAAE,iBAAiB,EAAE,GAAG,SAAS,EAC5C,KAAK,EAAE,SAAS,MAAM,EAAE,EACxB,QAAQ,EAAE,MAAM,EAChB,KAAK,CAAC,EAAE,kBAAkB,EAAE,GAC1B,MAAM,CAeR"}

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

@@ -0,0 +1,31 @@
+/**
+ * SmartArt DiagramML interpreter - manual `cust*` override final transform.
+ *
+ * PowerPoint writes `custAng`/`custScaleX`/`custScaleY`/`custSzX`/`custSzY`/
+ * `custFlipHor`/`custFlipVert`/`custLinFactX`/`custLinFactY`/`custRadScaleRad`/
+ * `custRadScaleInc` onto a `dgm:pt/dgm:prSet` when the user drags, resizes,
+ * rotates, or flips a node in its own diagram editor (see
+ * `DiagramNode.customLayout`, populated by
+ * `smartart-data-model-attributes.ts`). Neither algorithmic layout path ever
+ * looks at these, so a manually-placed node silently reverted to its
+ * algorithmic position whenever there was no cached `dsp:` drawing to fall
+ * back on. This module applies them as the final geometry pass after any
+ * arranger runs, regardless of which algorithm produced the base layout.
+ *
+ * Scope: `linearFactorNeighborX/Y` compensate a NEIGHBOURING node's spacing
+ * when this one is resized; they have no effect on this node's own geometry,
+ * and folding them into a neighbour's geometry needs whole-layout awareness
+ * this per-node pass does not have, so they are parsed (for round-trip
+ * completeness) but intentionally not applied here. Pure geometry; no
+ * framework code, no DOM.
+ */
+import type { DiagramNode } from '../model/index.js';
+import type { BoundingBox, SmartArtLayoutResult } from './smartart-layout-types.js';
+/**
+ * Apply every node's manual `cust*` layout override (if any) as a final
+ * transform over an already-computed layout result. A no-op when no node in
+ * `nodes` carries a `customLayout`, returning `result` unchanged (same
+ * reference) so callers can cheaply skip re-deriving anything downstream.
+ */
+export declare function applyCustomLayoutOverrides(result: SmartArtLayoutResult, nodes: DiagramNode[], box: BoundingBox): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-layout-interpreter-custom.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-custom.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-custom.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAE5C,OAAO,KAAK,EACX,WAAW,EAKX,oBAAoB,EACpB,MAAM,yBAAyB,CAAC;AAyIjC;;;;;GAKG;AACH,wBAAgB,0BAA0B,CACzC,MAAM,EAAE,oBAAoB,EAC5B,KAAK,EAAE,WAAW,EAAE,EACpB,GAAG,EAAE,WAAW,GACd,oBAAoB,CAatB"}

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

@@ -0,0 +1,36 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring/hub box building.
+ *
+ * Split out of `smartart-layout-interpreter-cycle.ts` (repo per-file line
+ * budget): turns a solved `CycleRingLayout` plus the arranged data nodes
+ * into the actual `RenderedNode` boxes (satellites, and the optional
+ * `ctrShpMap="fNode"` hub). Pure node-building; no framework code.
+ */
+import type { DiagramLayoutNodeShape, DiagramNode } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { CycleFontFit } from './smartart-layout-interpreter-cycle-fontfit.js';
+import type { CycleRingLayout } from './smartart-layout-interpreter-cycle-ring.js';
+import type { StyleContext } from './smartart-layout-interpreter-render.js';
+import type { RenderedNode } from './smartart-layout-types.js';
+/** Shared per-box inputs every ring/hub box shares. */
+export interface CycleBoxInputs {
+    palette: string[];
+    style: DiagramStyleIntensity;
+    ctx: StyleContext;
+    shape: DiagramLayoutNodeShape | undefined;
+    elementId: string;
+    fontSizeOverride?: number;
+    descendantFontSize?: number;
+}
+/** One box per ring satellite, at its own solved centre/size. */
+export declare function buildCycleRingBoxes(ringNodes: DiagramNode[], ring: CycleRingLayout, inputs: CycleBoxInputs): RenderedNode[];
+/**
+ * The centred `ctrShpMap="fNode"` hub box, sized from the ring's own
+ * largest-clearing-ellipse fit. `hubFontFit` (round 36): the hub fits its OWN
+ * box independently of the ring items - see `smartart-layout-interpreter-
+ * cycle-fontfit.ts`'s module doc comment. Falls back to `inputs`' own ring
+ * size when omitted, so an existing caller with no hub-specific fit is
+ * unaffected.
+ */
+export declare function buildCycleHubBox(hubNode: DiagramNode, ring: CycleRingLayout, totalNodeCount: number, inputs: CycleBoxInputs, hubFontFit?: CycleFontFit): RenderedNode;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-boxes.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-boxes.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-boxes.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,sBAAsB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AACpE,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,6CAA6C,CAAC;AAChF,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,0CAA0C,CAAC;AAEhF,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,sCAAsC,CAAC;AACzE,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,yBAAyB,CAAC;AAE5D,uDAAuD;AACvD,MAAM,WAAW,cAAc;IAC9B,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,KAAK,EAAE,qBAAqB,CAAC;IAC7B,GAAG,EAAE,YAAY,CAAC;IAClB,KAAK,EAAE,sBAAsB,GAAG,SAAS,CAAC;IAC1C,SAAS,EAAE,MAAM,CAAC;IAClB,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,kBAAkB,CAAC,EAAE,MAAM,CAAC;CAC5B;AAED,iEAAiE;AACjE,wBAAgB,mBAAmB,CAClC,SAAS,EAAE,WAAW,EAAE,EACxB,IAAI,EAAE,eAAe,EACrB,MAAM,EAAE,cAAc,GACpB,YAAY,EAAE,CAsBhB;AAED;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAC/B,OAAO,EAAE,WAAW,EACpB,IAAI,EAAE,eAAe,EACrB,cAAc,EAAE,MAAM,EACtB,MAAM,EAAE,cAAc,EACtB,UAAU,CAAC,EAAE,YAAY,GACvB,YAAY,CAqBd"}

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

@@ -0,0 +1,21 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring connector arcs.
+ *
+ * Split out of `smartart-layout-interpreter-cycle.ts` (repo per-file line
+ * budget): the light, outward-bulging quadratic-bezier arc drawn between
+ * adjacent ring points, pulled away from the ring's own centre. Pure
+ * geometry; no framework code.
+ */
+import type { CycleRingLayout } from './smartart-layout-interpreter-cycle-ring.js';
+import type { RenderedConnector } from './smartart-layout-types.js';
+/**
+ * One arc per adjacent ring-point pair (`n` pairs on a full circle, `n - 1`
+ * on an open arc), pulled outward from `ringCentre` in proportion to the
+ * item size - unchanged from the arranger's own pre-existing connector
+ * math, just relocated.
+ */
+export declare function buildCycleRingConnectors(ring: CycleRingLayout, n: number, connectorCount: number, ringCentre: {
+    x: number;
+    y: number;
+}, elementId: string): RenderedConnector[];
+//# sourceMappingURL=smartart-layout-interpreter-cycle-connectors.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-connectors.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-connectors.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,0CAA0C,CAAC;AAChF,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,yBAAyB,CAAC;AAEjE;;;;;GAKG;AACH,wBAAgB,wBAAwB,CACvC,IAAI,EAAE,eAAe,EACrB,CAAC,EAAE,MAAM,EACT,cAAc,EAAE,MAAM,EACtB,UAAU,EAAE;IAAE,CAAC,EAAE,MAAM,CAAC;IAAC,CAAC,EAAE,MAAM,CAAA;CAAE,EACpC,SAAS,EAAE,MAAM,GACf,iBAAiB,EAAE,CAgBrB"}

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

@@ -0,0 +1,116 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring constraint reading (`sibSp`,
+ * item `h:w`, and the choose-branch-flattening workaround for a nested
+ * `cycle` layoutNode).
+ *
+ * Split out of `smartart-layout-interpreter-cycle.ts` to keep that file
+ * under the repo's per-file line budget. See that module's doc comment for
+ * the full COM-verified derivation this feeds into.
+ *
+ * Pure geometry/constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import { findConstraint } from './smartart-layout-interpreter-constraints.js';
+import type { HubToNodeRatio } from './smartart-layout-interpreter-cycle-hub-ratio.js';
+import type { CompositeContentLayout } from './smartart-layout-interpreter-cycle-item-aspect.js';
+export { resolveHubToNodeRatio } from './smartart-layout-interpreter-cycle-hub-ratio.js';
+/**
+ * ECMA-376 21.4.2.x: a `dgm:constr`/`dgm:rule` numeric attribute with no
+ * `fact`/`refType` (an absolute `val`, e.g. `sibSp val="15"`) is in POINTS,
+ * PowerPoint's own unit for `CT_Constraint`, not a bare pixel or a percentage
+ * - same convention `smartart-layout-item-font-size.ts` already established
+ * for `primFontSz`. Duplicated here (rather than importing that module's
+ * private constant) to avoid a cross-track dependency for one literal.
+ */
+export declare const POINTS_TO_PIXELS: number;
+/**
+ * `sibSp`'s SCHEMA default is 0 (MS's "Cycle Algorithm" reference), but that
+ * is a floor the layoutDef may raise, never a target the renderer hits
+ * exactly: `basic-cycle`/`multidirectional-cycle` (declared 0.5/0.65) and
+ * `nondirectional-cycle`/`block-cycle` (declared 0.15, a SMALLER floor) all
+ * measure the SAME effective minimum gap once the declared value is at or
+ * below this figure, i.e. the real engine enforces its own aesthetic
+ * minimum regardless of a smaller declared `sibSp`. COM-verified exact for
+ * the two layouts that declare >= 0.5; see the module doc comment.
+ *
+ * SESSION 10: does NOT generalise to a composite self+child ring item
+ * (`resolveCycleRingParams`'s own `contentLayout`, e.g.
+ * `radial-list--hier5.pptx`'s `node` ellipse+rect): its declared `sibSp`
+ * (`~0.1333` once resolved) is relative to the COMPOSITE's own width, but
+ * the ring's natural unit-width is the narrower SELF sub-shape
+ * (`contentLayout.selfWidthFactor=0.4` - see `smartart-layout-interpreter-
+ * cycle-item-aspect.ts`). Converting (`declaredRatio / selfWidthFactor =
+ * 0.333`) and skipping this floor for a composite item reproduces the
+ * fixture's own cached ring-item size (161px vs cached 154px, 4.5% off) far
+ * closer than either the floored-at-0.5 reading (137px, 11% off) or the raw
+ * unconverted `0.1333` (167px, 8.4% off) - the remaining ~4.5% was not
+ * chased further this session, no 4th independent sample to re-derive it.
+ */
+export declare const DEFAULT_MIN_GAP_RATIO = 0.5;
+/**
+ * A `dgm:constr`'s genuinely ABSOLUTE `val` in POINTS (ECMA-376 21.4.2.x: no
+ * `fact`, no `refType` at all, and a `value` that is not itself a sub-1
+ * ratio - `ratioConstraint`'s own convention, see
+ * `smartart-layout-interpreter-constraints.ts`, for treating a small literal
+ * `val` as a ratio instead), or `undefined` when `constraint` is absent or is
+ * a ratio (`fact`, `refType`, or a sub-1 `val`). `sibSp val="15"`
+ * (continuous-cycle) resolves to `15`; `sibSp fact="0.5"` (basic-cycle) and
+ * `sibSp refType="w" fact="0.15"` both resolve to `undefined`.
+ */
+export declare function absoluteConstraintPoints(constraint: ReturnType<typeof findConstraint>): number | undefined;
+/**
+ * The layoutNode that ACTUALLY carries the ring's own `constrLst` (`sibSp`,
+ * `diam`, `w`) and item template, when `arrangerNode` is not it directly.
+ *
+ * `continuous-cycle`'s ("cycle3") top layoutNode is a `dgm:choose` between a
+ * dedicated 2-node `composite` layout and, for 3+ nodes, a nested
+ * `dgm:layoutNode name="cycle"` carrying the real ring `constrLst` and item
+ * templates. `smartart-layout-definition.ts`'s parser flattens BOTH branches'
+ * children onto the top node's own `.children` (it does not model
+ * choose-branch scoping - the same simplification
+ * `smartart-layout-interpreter-hub.ts`'s module doc comment describes for
+ * nested `forEach`), so `itemNode(arrangerNode)` on the top node picks up the
+ * WRONG branch's item (`node1`, the 2-node composite's, not `nodeFirstNode`).
+ * `arrangerNode.algorithm` itself is unaffected (already correctly resolved
+ * to the chosen branch by `discoverArrangement`), so `stAng`/`spanAng` are
+ * fine either way - only the item/constraint lookups need this.
+ *
+ * `basic-cycle`/`multidirectional-cycle`/`nondirectional-cycle`/`block-cycle`
+ * all declare a single, ungated top `dgm:layoutNode name="cycle"`, so
+ * `arrangerNode` already IS this node for them (returned unchanged).
+ * Depth-first search for a descendant literally named `"cycle"` - the naming
+ * convention every built-in cycle-family gallery layout examined uses for
+ * its actual ring layoutNode, whether or not it is the top node.
+ */
+export declare function resolveCycleConstraintNode(arrangerNode: DiagramLayoutNode): DiagramLayoutNode;
+/**
+ * Resolve the ring's `sibSp` (either a dimensionless `minGapRatio`, floored
+ * at `DEFAULT_MIN_GAP_RATIO` when it is a genuine ratio - see that constant's
+ * doc comment - or an absolute `absoluteGapPx`, converted points -> pixels,
+ * when the layout declares a bare `val` - see `computeCycleRingLayout`'s doc
+ * comment), `heightOverWidth` (the item node's own `h` fact), `hubRatio` (see
+ * `resolveHubToNodeRatio`, `undefined` for a plain ring with no hub), and
+ * `hubGapRatio` (see {@link resolveHubGapRatio}, `undefined` when no hub is
+ * present or `sp` does not resolve) from the arranger's own declared
+ * constraints. Takes the raw arranger `DiagramLayoutNode` (not an
+ * `ArrangementPlan`) so `smartart-layout-interpreter-hub.ts` can call it for
+ * a hub's ring without constructing a synthetic plan.
+ *
+ * `satelliteCount` (SESSION 17, optional): the ring's own satellite count
+ * (hub excluded), fed straight through to `resolveHubToNodeRatio`'s own
+ * count-gated `dgm:rule` override - see that function's own doc comment.
+ * `undefined` from a caller with no count yet (the ratio still resolves via
+ * `constrLst` alone then, exactly as before this session).
+ */
+export declare function resolveCycleRingParams(arrangerNode: DiagramLayoutNode, index: ConstraintIndex, satelliteCount?: number, declaringRoleChain?: readonly string[]): {
+    minGapRatio: number;
+    heightOverWidth: number;
+    absoluteGapPx?: number | undefined;
+    hubRatio?: HubToNodeRatio | undefined;
+    hubGapRatio?: number | undefined;
+    absoluteHubGapPx?: number | undefined;
+    contentLayout?: CompositeContentLayout | undefined;
+    sibTransBulgeRatio?: number | undefined;
+};
+//# sourceMappingURL=smartart-layout-interpreter-cycle-constraints.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-constraints.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-constraints.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAElD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAEpE,OAAO,EAAE,cAAc,EAAmB,MAAM,2CAA2C,CAAC;AAC5F,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,+CAA+C,CAAC;AASpF,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,iDAAiD,CAAC;AAI9F,OAAO,EAAE,qBAAqB,EAAE,MAAM,+CAA+C,CAAC;AAEtF;;;;;;;GAOG;AACH,eAAO,MAAM,gBAAgB,QAAU,CAAC;AAExC;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,eAAO,MAAM,qBAAqB,MAAM,CAAC;AAEzC;;;;;;;;;GASG;AACH,wBAAgB,wBAAwB,CACvC,UAAU,EAAE,UAAU,CAAC,OAAO,cAAc,CAAC,GAC3C,MAAM,GAAG,SAAS,CAYpB;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,0BAA0B,CAAC,YAAY,EAAE,iBAAiB,GAAG,iBAAiB,CAU7F;AAED;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,sBAAsB,CACrC,YAAY,EAAE,iBAAiB,EAC/B,KAAK,EAAE,eAAe,EACtB,cAAc,CAAC,EAAE,MAAM,EACvB,kBAAkB,CAAC,EAAE,SAAS,MAAM,EAAE,GACpC;IACF,WAAW,EAAE,MAAM,CAAC;IACpB,eAAe,EAAE,MAAM,CAAC;IACxB,aAAa,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACnC,QAAQ,CAAC,EAAE,cAAc,GAAG,SAAS,CAAC;IACtC,WAAW,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACjC,gBAAgB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACtC,aAAa,CAAC,EAAE,sBAAsB,GAAG,SAAS,CAAC;IACnD,kBAAkB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;CACxC,CAwGA"}

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

@@ -0,0 +1,110 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring point EXTENSION (a data node
+ * on the ring that itself has children - `radial-cluster`'s construct).
+ *
+ * PowerPoint's own "Radial Cluster" gallery layoutDef does not implement
+ * this recursively at the DiagramML level - it HAND-DUPLICATES a full
+ * "this satellite becomes its own centre + one further point" sub-structure
+ * for each of up to 7 possible ring positions (`childCenter1..7`/`text1..7`
+ * in the raw XML, each an `alg="tx"` fixed-position leaf, gated by its own
+ * `dgm:choose func="cnt"` checking whether that specific satellite's data
+ * node has children - see `smartart-track-r-successor.md` SESSION 11's
+ * construct analysis). Reproducing that hand-authored per-slot absolute
+ * positioning exactly is not a generalisable fix (it does not extend to an
+ * arbitrary ring size, and 172 hand-unrolled `dgm:alg` blocks are not a
+ * pattern worth porting literally) - this module is the GENERAL
+ * interpreter-side equivalent instead: a ring point whose data node has its
+ * own children is not a leaf; its child(ren) continue OUTWARD along the
+ * same radial direction the point itself already sits on, one step further
+ * from the ring's own centre, recursing for any deeper generation.
+ *
+ * COM-verified for the one shape the corpus actually exercises
+ * (`radial-cluster--hier5.pptx`'s "Node Four" -> "Node Five", a single
+ * grandchild): the cached child centre lies on the ray from the ring's own
+ * centre through the parent's centre, at `t ~= 2.0-2.1` (twice the parent's
+ * own radius) - i.e. the child continues in the SAME direction, not on an
+ * independent sub-ring of its own. This module reproduces that by placing a
+ * lone child exactly on that ray, one item-width-plus-gap further out.
+ *
+ * The MULTI-child fan (more than one grandchild under the SAME parent) is
+ * NOT exercised by any corpus fixture - `fanSpanDeg` (the total angular
+ * spread the siblings fan across, centred on the outward direction) is a
+ * REASONED EXTRAPOLATION only, not an empirically confirmed value: whoever
+ * finds a multi-grandchild sample should re-verify it against live
+ * PowerPoint COM output rather than trust this module's own default.
+ *
+ * Pure geometry + node-building; no framework code.
+ */
+import type { DiagramLayoutNode, DiagramNode } from '../model/index.js';
+import type { CycleBoxInputs } from './smartart-layout-interpreter-cycle-boxes.js';
+import type { CycleRingLayout } from './smartart-layout-interpreter-cycle-ring.js';
+import type { RenderedConnector, RenderedNode } from './smartart-layout-types.js';
+interface Point {
+    x: number;
+    y: number;
+}
+/**
+ * True when `node` (the arranger `discoverArrangement` resolved) was reached
+ * through an enclosing `dgm:if func="maxDepth"` ({@link
+ * DiagramLayoutNode.chooseGuard}) - the one structural, non-per-layout-
+ * name signal that distinguishes `radial-cluster`'s own `singleCycle` (reached
+ * through exactly one `func="maxDepth" op="lte" val="1"` guard - COM-verified
+ * via a direct `discoverArrangement` dump) from EVERY other hub-bearing cycle
+ * fixture in the corpus (`radial-cycle`/`basic-radial`/`diverging-radial`/
+ * `converging-radial`/`radial-venn`, all confirmed `chooseGuard: undefined`)
+ * - see `arrangeCycle`'s own call site for why this is required IN ADDITION
+ * to `hubAlreadyStripped`, not instead of it: `radial-cycle--hier5.pptx`'s
+ * own sample data gives one ring satellite an unrelated extra child too (the
+ * IDENTICAL data shape `radial-cluster--hier5.pptx` uses), and its cached
+ * drawing FOLDS that child's text into the satellite's own box instead of
+ * rendering it separately - `hubAlreadyStripped` alone cannot tell these two
+ * layouts apart, since both are genuinely hub-stripped.
+ */
+export declare function hasMaxDepthGuard(node: DiagramLayoutNode): boolean;
+/** Shared, per-diagram inputs for every extension point this ring builds. */
+export interface CycleExtensionContext extends CycleBoxInputs {
+    /** The main ring's own natural centre (box-local pixels) - every extension direction is measured from here. */
+    ringCentre: Point;
+    itemWidth: number;
+    itemHeight: number;
+    /** Edge-to-edge gap (pixels) between a parent and its extension child - reuses the ring's own resolved `sibSp` gap. */
+    gapPx: number;
+    /** Total angular spread (degrees) a MULTI-child fan occupies, centred on the outward direction - see the module doc comment's "not empirically confirmed" note. */
+    fanSpanDeg: number;
+    childrenOf: Map<string, DiagramNode[]>;
+}
+/**
+ * Recursively render `parentNode`'s own children (and their own children, at
+ * any depth) as further ring-continuation points, extending outward from
+ * `parentCentre` along the ray from `context.ringCentre` through it. Returns
+ * an EMPTY result (a no-op) when `parentNode` has no children - the common
+ * case for every ring point in every other cycle-family fixture, so wiring
+ * this into `arrangeCycle` is behaviour-preserving whenever no ring point
+ * has children of its own.
+ */
+export declare function buildCycleRingExtensions(parentCentre: Point, parentNode: DiagramNode, context: CycleExtensionContext, path: string): {
+    nodes: RenderedNode[];
+    connectors: RenderedConnector[];
+};
+/** `arrangeCycle`'s own per-diagram inputs for {@link applyCycleRingExtensions}. */
+export interface CycleRingExtensionInputs extends CycleBoxInputs {
+    ringCentre: Point;
+    minGapRatio: number;
+    absoluteGapPx: number | undefined;
+    /** The main ring's own per-slot angular width - see {@link CycleExtensionContext.fanSpanDeg}'s doc comment. */
+    ringStepDeg: number;
+    childrenOf: Map<string, DiagramNode[]>;
+}
+/**
+ * Run {@link buildCycleRingExtensions} for every point on `ring`, combining
+ * every point's own (possibly empty) result - the single call site
+ * `arrangeCycle` needs (split out of that module for the repo's per-file
+ * line budget). A no-op (empty `nodes`/`connectors`) whenever no `ringNodes`
+ * entry has children in `childrenOf`.
+ */
+export declare function applyCycleRingExtensions(ringNodes: DiagramNode[], ring: CycleRingLayout, inputs: CycleRingExtensionInputs): {
+    nodes: RenderedNode[];
+    connectors: RenderedConnector[];
+};
+export {};
+//# sourceMappingURL=smartart-layout-interpreter-cycle-extension.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-extension.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-extension.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC/D,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,2CAA2C,CAAC;AAChF,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,0CAA0C,CAAC;AAEhF,OAAO,KAAK,EAAE,iBAAiB,EAAE,YAAY,EAAE,MAAM,yBAAyB,CAAC;AAI/E,UAAU,KAAK;IACd,CAAC,EAAE,MAAM,CAAC;IACV,CAAC,EAAE,MAAM,CAAC;CACV;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,iBAAiB,GAAG,OAAO,CAEjE;AAED,6EAA6E;AAC7E,MAAM,WAAW,qBAAsB,SAAQ,cAAc;IAC5D,+GAA+G;IAC/G,UAAU,EAAE,KAAK,CAAC;IAClB,SAAS,EAAE,MAAM,CAAC;IAClB,UAAU,EAAE,MAAM,CAAC;IACnB,uHAAuH;IACvH,KAAK,EAAE,MAAM,CAAC;IACd,mKAAmK;IACnK,UAAU,EAAE,MAAM,CAAC;IACnB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,CAAC;CACvC;AAED;;;;;;;;GAQG;AACH,wBAAgB,wBAAwB,CACvC,YAAY,EAAE,KAAK,EACnB,UAAU,EAAE,WAAW,EACvB,OAAO,EAAE,qBAAqB,EAC9B,IAAI,EAAE,MAAM,GACV;IAAE,KAAK,EAAE,YAAY,EAAE,CAAC;IAAC,UAAU,EAAE,iBAAiB,EAAE,CAAA;CAAE,CAqD5D;AAED,oFAAoF;AACpF,MAAM,WAAW,wBAAyB,SAAQ,cAAc;IAC/D,UAAU,EAAE,KAAK,CAAC;IAClB,WAAW,EAAE,MAAM,CAAC;IACpB,aAAa,EAAE,MAAM,GAAG,SAAS,CAAC;IAClC,+GAA+G;IAC/G,WAAW,EAAE,MAAM,CAAC;IACpB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,CAAC;CACvC;AAED;;;;;;GAMG;AACH,wBAAgB,wBAAwB,CACvC,SAAS,EAAE,WAAW,EAAE,EACxB,IAAI,EAAE,eAAe,EACrB,MAAM,EAAE,wBAAwB,GAC9B;IAAE,KAAK,EAAE,YAAY,EAAE,CAAC;IAAC,UAAU,EAAE,iBAAiB,EAAE,CAAA;CAAE,CAsB5D"}

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

@@ -0,0 +1,50 @@
+/**
+ * SmartArt DiagramML interpreter - shared font-fit wiring for the `cycle`
+ * arranger.
+ *
+ * Split out of `smartart-layout-interpreter-cycle.ts` (the repo's per-file
+ * line budget).
+ *
+ * Round 18: `arrangeCycle` used to never call the shared font-fit at all, so
+ * every item fell through `rectNode`/`circleNode`'s own `fontSizeOverride ??
+ * fitFontSize(...)` fallback - a crude, un-derived `0.6 char-width` heuristic
+ * capped at a literal 12px (9pt) ceiling, regardless of the diagram's real
+ * declared `primFontSz`. Measured against the full gallery: dozens of
+ * `cycle`/`pyramid`/hierarchy-family fixtures rendered a flat ~8-9pt for
+ * cached sizes of 20-70pt. This wires the SAME shared fitter `lin`/`snake`
+ * already use (`smartart-layout-interpreter-linear.ts`'s matching call) -
+ * it degenerates to the single-tier case when no item folds a descendant
+ * (the common case here), and folds correctly when one does (`basic-
+ * cycle--hier5.pptx`'s "Node One\nNode Two has a longer label").
+ *
+ * Round 36: a `ctrShpMap="fNode"` hub was still being forced into the SAME
+ * joint fit as the ring items (one `fitItems` array, one binary search), so
+ * the hub's font size was capped at whatever size the SMALLER ring boxes
+ * could fit - never its own, usually much bigger, box. A corpus-wide scan of
+ * every hub-bearing cycle fixture's own CACHED drawing (`l36-hub-font-scan.ts`,
+ * scratchpad) shows the hub's real font size is ALWAYS independently larger
+ * than the ring items' (`basic-radial--hier5.pptx`: hub 50.7pt vs ring 28pt;
+ * `converging-radial--hier5.pptx`: 66.7pt vs 38.7pt; `radial-venn--hier5.pptx`:
+ * 86.7pt vs 24pt; `radial-cluster--hier5.pptx`: 36pt vs 13.3pt; 8 more
+ * fixtures, same pattern, zero counterexamples) - PowerPoint fits the hub to
+ * ITS OWN box, never jointly with the ring. Fixed generally (every
+ * hub-bearing cycle fixture, not a `radial-cluster` special case): the hub
+ * now gets its own {@link resolveTieredItemFontSize} call, against its own
+ * box only. A ring-less cycle (`hubNode` undefined, the majority of the
+ * family) is byte-identical to before this round: the ring-only branch below
+ * is unchanged.
+ */
+import type { DiagramNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { ArrangementPlan } from './smartart-layout-interpreter-model.js';
+/** Resolved root/descendant font size (px) for the ring items, plus the hub's own (when one is present). */
+export interface CycleFontFit {
+    fontSizeOverride: number;
+    descendantSizePx: number;
+    /** The hub's own, independently-fit root size (px) - see the module doc comment's Round 36 note. `undefined` when there is no hub. */
+    hubFontSizeOverride?: number;
+    /** The hub's own, independently-fit descendant size (px). `undefined` when there is no hub. */
+    hubDescendantSizePx?: number;
+}
+export declare function resolveCycleFontFit(plan: ArrangementPlan, index: ConstraintIndex, ringNodes: DiagramNode[], hubNode: DiagramNode | undefined, ringNodeWidth: number, ringNodeHeight: number, hubWidth: number, hubHeight: number, cornerInsetPx: number, childrenOf: Map<string, DiagramNode[]> | undefined, fontName: string | undefined): CycleFontFit;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-fontfit.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-fontfit.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-fontfit.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC5C,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAEpE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAG3E,4GAA4G;AAC5G,MAAM,WAAW,YAAY;IAC5B,gBAAgB,EAAE,MAAM,CAAC;IACzB,gBAAgB,EAAE,MAAM,CAAC;IACzB,sIAAsI;IACtI,mBAAmB,CAAC,EAAE,MAAM,CAAC;IAC7B,+FAA+F;IAC/F,mBAAmB,CAAC,EAAE,MAAM,CAAC;CAC7B;AAED,wBAAgB,mBAAmB,CAClC,IAAI,EAAE,eAAe,EACrB,KAAK,EAAE,eAAe,EACtB,SAAS,EAAE,WAAW,EAAE,EACxB,OAAO,EAAE,WAAW,GAAG,SAAS,EAChC,aAAa,EAAE,MAAM,EACrB,cAAc,EAAE,MAAM,EACtB,QAAQ,EAAE,MAAM,EAChB,SAAS,EAAE,MAAM,EACjB,aAAa,EAAE,MAAM,EACrB,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,WAAW,EAAE,CAAC,GAAG,SAAS,EAClD,QAAQ,EAAE,MAAM,GAAG,SAAS,GAC1B,YAAY,CAgDd"}

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

@@ -0,0 +1,66 @@
+/**
+ * SmartArt DiagramML interpreter - `ctrShpMap="fNode"` hub detection for the
+ * `cycle` arranger.
+ *
+ * Split out of `smartart-layout-interpreter-cycle.ts` to keep that file
+ * under the repo's per-file line budget. Pure geometry/decision logic; no
+ * framework code.
+ */
+import type { DiagramNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { HubToNodeRatio } from './smartart-layout-interpreter-cycle-hub-ratio.js';
+import type { HubRingGeometry } from './smartart-layout-interpreter-cycle-ring.js';
+import type { ArrangementPlan } from './smartart-layout-interpreter-model.js';
+import type { BoundingBox } from './smartart-layout-types.js';
+/** Everything `arrangeCycle` needs about whether/how this ring has a `ctrShpMap="fNode"` hub. */
+export interface HubExpansion {
+    hasHub: boolean;
+    hubNode: DiagramNode | undefined;
+    ringNodes: DiagramNode[];
+    /** Centre-to-satellite sizing/gap, when a hub is present and `sp` resolves. */
+    hubGeometry: HubRingGeometry | undefined;
+    /** The known absolute node width for a nested `n===1` hub+satellite ring (round 46). */
+    knownNodeWidthPx: number | undefined;
+}
+/**
+ * `ctrShpMap="fNode"` pulls the first data point into a hub at the ring's own
+ * natural centre; every other value (including absent) puts every point on
+ * the ring. Real gallery hub layouts (`radial-cycle`, `basic-radial`,
+ * `diverging-radial`, `converging-radial`, `radial-venn`, ...) are already
+ * stripped of their hub point upstream (`hubAlreadyStripped`) - essential,
+ * not a fallback nicety: `ctrShpMap` stays `'fNode'` on `plan.node.algorithm`
+ * regardless, so without this flag `arrangeCycle` would re-detect a SECOND,
+ * PHANTOM hub from the first satellite in its own already-hub-free `nodes`.
+ *
+ * `!hubRatio`: `radial-list--hier5.pptx`'s own shape - THREE top-level "node"
+ * points, plus a SEPARATE, always-present `centerShape` (a decorative image)
+ * - the composite's own direct `w ... refForName="centerShape"` cross-
+ * reference (`hubRatio`) is the SAME signal that "this composite already
+ * structurally names its own hub", so the `ctrShpMap` fallback below must
+ * NOT ALSO peel `nodes[0]` (COM-verified: doing so collapsed a real
+ * 3-satellite ring to a degenerate 2).
+ *
+ * `hubRatio.viaUserSize` (round 46): unlike a direct cross-reference, a
+ * `userS`-ancestor-chain resolution carries no "already structurally named"
+ * meaning, so it must NOT suppress the peel either -
+ * `radial-cluster--hier5.pptx`'s nested `cycle_3` (hub "Four", satellite
+ * "Five", both independently sized off the SAME diagram-wide fact) resolves
+ * `hubRatio` this way yet still needs the peel to render its hub separately.
+ *
+ * `hubGeometry`: a hub+ring composite's own centre-to-satellite `r0` is
+ * governed by `hubGapRatio` (the `sp` space between the hub's edge and each
+ * satellite's), independent of `hubAlreadyStripped` - the satellites still
+ * ring AROUND the hub even when it was already pulled out and rendered
+ * separately. A `viaUserSize` hub's own `factor` is the diagram-wide
+ * item:hub ratio BOTH independently anchor to, not their size relative to
+ * EACH OTHER, so they are the SAME absolute size (`factor: 1`).
+ *
+ * `knownNodeWidthPx`: a genuinely NESTED single-satellite ring (`n===1`, a
+ * `viaUserSize` hub) has no independent box-fit to derive its node width
+ * from - resolve the SAME absolute pixel size `resolveUserSizeItemBoxPx`
+ * already gives a flat repeater's `userS` item, so both the hub and
+ * satellite honour the real diagram-wide fact instead of stretching to fill
+ * the box.
+ */
+export declare function resolveHubExpansion(nodes: DiagramNode[], plan: ArrangementPlan, hubAlreadyStripped: boolean, hubRatio: HubToNodeRatio | undefined, hubGapRatio: number | undefined, absoluteHubGapPx: number | undefined, index: ConstraintIndex, box: BoundingBox, sizeBox: BoundingBox | undefined): HubExpansion;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-hub-detect.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-hub-detect.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-hub-detect.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC5C,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AACpE,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,+CAA+C,CAAC;AAEpF,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,0CAA0C,CAAC;AAEhF,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,qCAAqC,CAAC;AAC3E,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAC;AAE3D,iGAAiG;AACjG,MAAM,WAAW,YAAY;IAC5B,MAAM,EAAE,OAAO,CAAC;IAChB,OAAO,EAAE,WAAW,GAAG,SAAS,CAAC;IACjC,SAAS,EAAE,WAAW,EAAE,CAAC;IACzB,+EAA+E;IAC/E,WAAW,EAAE,eAAe,GAAG,SAAS,CAAC;IACzC,wFAAwF;IACxF,gBAAgB,EAAE,MAAM,GAAG,SAAS,CAAC;CACrC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AACH,wBAAgB,mBAAmB,CAClC,KAAK,EAAE,WAAW,EAAE,EACpB,IAAI,EAAE,eAAe,EACrB,kBAAkB,EAAE,OAAO,EAC3B,QAAQ,EAAE,cAAc,GAAG,SAAS,EACpC,WAAW,EAAE,MAAM,GAAG,SAAS,EAC/B,gBAAgB,EAAE,MAAM,GAAG,SAAS,EACpC,KAAK,EAAE,eAAe,EACtB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,WAAW,GAAG,SAAS,GAC9B,YAAY,CAiBd"}

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

@@ -0,0 +1,81 @@
+/**
+ * SmartArt DiagramML interpreter - `userS`-declared hub/ring-item ratio.
+ *
+ * Split out of `smartart-layout-interpreter-cycle-hub-ratio.ts` (the repo's
+ * per-file line budget): {@link resolveHubToNodeRatioViaUserSize} is the
+ * `resolveHubToNodeRatio` fallback for a ring item that declares its own
+ * size INDIRECTLY through `userS` ("user specified size") rather than a
+ * direct `w for="ch" forName="<item>" refFor="ch" refForName="<hub>"`
+ * cross-reference. Pure constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { BoundingBox } from './smartart-layout-types.js';
+/**
+ * `resolveHubToNodeRatio`'s resolved ring-item:hub ratio, tagged with WHERE
+ * it was found - `viaUserSize` (round 46) marks a ratio resolved through
+ * {@link resolveHubToNodeRatioViaUserSize} (a `userS` diagram-wide fact, e.g.
+ * `radial-cluster--hier5.pptx`'s `textCenter`-anchored `fact="0.67"`) rather
+ * than a DIRECT local cross-role reference (`radial-list`'s own `centerShape`
+ * reference). The two carry different structural meaning for a caller
+ * deciding whether this composite already names its own hub: a direct
+ * reference genuinely means "this ring already has a structurally-named hub,
+ * do not also peel `nodes[0]`"; a `userS`-ancestor-chain resolution carries no
+ * such meaning at all (it is just "some diagram-wide ratio happens to
+ * exist") - see `arrangeCycle`'s own `hasHub` gate.
+ */
+export interface HubToNodeRatio {
+    hubName: string;
+    factor: number;
+    viaUserSize?: boolean;
+}
+/**
+ * `node.w = fact * <hubName>.w`, declared INDIRECTLY through `userS` ("user
+ * specified size") - `radial-cluster`'s own `singleCycle`/`text0`: `text0`'s
+ * own `w` constraint is a BARE `refType="userS"` self-reference (no hub
+ * mentioned at all in THIS constraint), and the actual hub-relative factor
+ * lives on a SEPARATE constraint declared on the ARRANGER itself (`userS
+ * for="ch" ptType="node" refType="w" refFor="ch" refForName="singleCenter"
+ * fact="0.67"` - targeted by `ptType`, the DiagramML convention for "every
+ * child node point", not by `forName`, since `userS` is declared once for
+ * the whole repeated item template rather than by its specific layoutNode
+ * name). COM-verified the `0.67` fact is IDENTICAL across every live
+ * `dgm:choose` branch this construct's own `cnt`-gated `constrLst` declares
+ * (`cnt=1`/`cnt>=2` both declare the SAME `userS ... fact="0.67"` - only the
+ * HUB's own size differs per branch, never this ratio), so reading it
+ * without evaluating the choose's own `cnt` condition (`buildConstraintIndex`
+ * does not model `dgm:choose` scoping at all - see its own doc comment) is
+ * not a guess: whichever live branch's copy this finds, the fact is the
+ * same.
+ *
+ * `index`/`declaringRoleChain` (nearest ancestor first): when the LOCAL
+ * `arrangerConstraints` carries no `userS` declaration at all, the actual
+ * one may live at a DISTANT ancestor's own `constrLst` instead - a genuinely
+ * nested arranger (`radial-cluster--hier5.pptx`'s `cycle_3`, itself a child
+ * of the composite root `Name0`, two levels above the ring item `text3`)
+ * whose own `userS` reference is declared once, diagram-wide, at `Name0`
+ * (`userS for="des" ptType="node" refType="w" refFor="ch"
+ * refForName="textCenter" fact="0.67"`), never repeated locally on
+ * `cycle_3`. `resolveByAncestorChain` (`smartart-constraint-declared-by.ts`)
+ * searches the WHOLE `ConstraintIndex` for a `userS` declaration, but ONLY
+ * accepts one whose `declaringRole` is in this chain - `radial-cluster`
+ * itself also declares an UNRELATED `userS` at its own `singleCycle`
+ * alternative branch (its `n=1` structure, never an ancestor of `cycle_3`),
+ * which a plain "first `userS` found" scan would wrongly prefer or collide
+ * with; the chain is what tells the two apart.
+ */
+export declare function resolveHubToNodeRatioViaUserSize(ringItem: DiagramLayoutNode, arrangerConstraints: DiagramLayoutNode['constraints'], index?: ConstraintIndex, declaringRoleChain?: readonly string[]): HubToNodeRatio | undefined;
+/**
+ * The absolute pixel width (and, by construction, height - {@link
+ * HubToNodeRatio} only ever tags a SQUARE `userS` item, see
+ * `resolveUserSizeItemBoxPx`'s own `isSquareHeightConstraint` gate) a
+ * `viaUserSize`-tagged hub ratio's ring item resolves to - the SAME
+ * computation `resolveUserSizeItemBoxPx` (`smartart-layout-interpreter-
+ * composite-children.ts`) already performs for a flat repeater slot, reused
+ * here for a genuinely NESTED ring's degenerate single-satellite case
+ * (`arrangeCycle`'s own `n===1` branch), which has no independent box-fit to
+ * derive a node width from at all. `undefined` when the hub's own `w` does
+ * not resolve (defensive; not expected once `ratio.viaUserSize` is true).
+ */
+export declare function resolveViaUserSizeNodeWidthPx(ratio: HubToNodeRatio, index: ConstraintIndex, box: BoundingBox, sizeBox: BoundingBox): number | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-hub-ratio-usersize.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-hub-ratio-usersize.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-hub-ratio-usersize.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAElD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAGpE,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAC;AAM3D;;;;;;;;;;;;GAYG;AACH,MAAM,WAAW,cAAc;IAC9B,OAAO,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,MAAM,CAAC;IACf,WAAW,CAAC,EAAE,OAAO,CAAC;CACtB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AACH,wBAAgB,gCAAgC,CAC/C,QAAQ,EAAE,iBAAiB,EAC3B,mBAAmB,EAAE,iBAAiB,CAAC,aAAa,CAAC,EACrD,KAAK,CAAC,EAAE,eAAe,EACvB,kBAAkB,CAAC,EAAE,SAAS,MAAM,EAAE,GACpC,cAAc,GAAG,SAAS,CAuC5B;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,6BAA6B,CAC5C,KAAK,EAAE,cAAc,EACrB,KAAK,EAAE,eAAe,EACtB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,WAAW,GAClB,MAAM,GAAG,SAAS,CAQpB"}