ooxml-core 1.1.0 → 1.2.0

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

@@ -0,0 +1,109 @@
+/**
+ * SmartArt DiagramML interpreter - hub/ring-item sizing ratios for a
+ * hub+satellite `cycle` composite (`radial-cycle`, `basic-radial`,
+ * `diverging-radial`, `converging-radial`, `radial-list`).
+ *
+ * Split out of `smartart-layout-interpreter-cycle-constraints.ts` to keep
+ * that file under the repo's per-file line budget. Pure constraint reading;
+ * no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+import type { HubToNodeRatio } from './smartart-layout-interpreter-cycle-hub-ratio-usersize.js';
+export type { HubToNodeRatio } from './smartart-layout-interpreter-cycle-hub-ratio-usersize.js';
+/**
+ * `node.w = fact * <hubName>.w` (`radial-cycle`'s `w for="ch" forName="node"
+ * refType="w" refFor="ch" refForName="centerShape" fact="0.7"`, or
+ * `basic-radial`'s SAME shape with NO `fact` at all - `op="equ"` with an
+ * implicit `factor` of 1, ECMA-376's own default for an omitted `fact`,
+ * COM-verified: `basic-radial--hier5.pptx`'s cached hub is the literal SAME
+ * size as its satellites): the ring item's own width, DECLARED as a
+ * fraction of the hub's, in the SAME "natural" (pre-anisotropic-scale) unit
+ * space `computeCycleRingLayout` already works in (the ring item's own
+ * natural width is fixed at 1 there) - so the hub's own natural width is
+ * `1 / fact`, giving the hub's SCALED size directly from the ring's own
+ * already-solved `scaleX`/`scaleY` without a separate geometric "clears the
+ * nearest ring node" guess. `hubName` (the OTHER end of the reference) is
+ * returned too so a caller can sanity-check it against the actual hub
+ * node's own name when one is known, though every composite ring layout
+ * examined names it `centerShape`.
+ *
+ * SESSION 12: `resolveHubToNodeRatio` now graph-resolves `node.w` and
+ * `hubName.w` independently (`resolveConstraint`, `smartart-constraint-
+ * solver.ts`'s own reference-walking machinery, which already honours
+ * `op="equ"/"gte"/"lte"`) and returns their RATIO instead of reading this
+ * ONE constraint's own raw `fact` in isolation, when `index` is given -
+ * falling back to the raw-fact reading unchanged whenever `index` is
+ * omitted or either side fails to resolve, so every existing caller is
+ * BYTE-IDENTICAL (verified: `basic-radial--hier5.pptx` stays exact).
+ *
+ * SESSION 17: `diverging-radial--hier5.pptx`'s own hub:satellite size-ratio
+ * bug (SESSION 12's own negative result, kept below as history) is NOT a
+ * resolution-depth problem after all - it is a count-gated `dgm:rule`
+ * (`w for="ch" forName="node"`, six `dgm:choose`/`dgm:if cnt<=N` branches,
+ * `fact="1"` for `cnt<=6`, `fact="0.9"` for `cnt<=8`, down to `fact="0.5"`
+ * else) that REPLACES the `constrLst`'s own declared ratio (`1.25`) rather
+ * than multiplying on top of it, missed entirely because it lives inside a
+ * `dgm:choose` (the SAME "rules aren't choose-aware" gap `smartart-layout-
+ * interpreter-named-rules.ts` documents for `primFontSz`/`secFontSz`, here
+ * hitting `w` instead). COM-verified with TWO independent samples: `n=3`
+ * (falls in `cnt<=6`, `fact=1`) renders hub:item at the cached `172:172 =
+ * 1:1`, matching `1/1` exactly; a purpose-built `n=8` sample (`cnt<=8`,
+ * `fact=0.9`) renders `1281782:1153604 = 1.1111`, matching `1/0.9` exactly -
+ * the SAME ratio-inversion relationship (`hub's natural width = 1/fact`)
+ * this function already uses for the `constrLst`-only case, just with the
+ * RULE's `fact` in place of the constraint's. `resolveRuleCountOverride`
+ * below resolves the live branch via `evaluateWhen` given the real
+ * satellite count, first-match-wins in document order (matching
+ * `dgm:choose` semantics), and its result - when present - REPLACES the
+ * constraint-derived factor entirely, not just when no constraint matched.
+ *
+ * **SESSION 12's own negative result, kept as history**: graph-resolving
+ * `node.w`/`hubName.w` independently and dividing (below, unchanged) is
+ * provably a mathematical identity with the raw `constrLst` `factor` alone -
+ * it can never explain a DIFFERENT final ratio than the declared one, since
+ * both sides cascade through the SAME reference chain. The real override
+ * was never reachable through `constrLst` resolution at all; it needed the
+ * count-gated `ruleLst` this session adds.
+ */
+export declare function resolveHubToNodeRatio(ringItem: DiagramLayoutNode | undefined, arrangerConstraints: DiagramLayoutNode['constraints'], index?: ConstraintIndex, arrangerRuleCandidates?: DiagramLayoutNode['ruleCandidates'], satelliteCount?: number, declaringRoleChain?: readonly string[]): HubToNodeRatio | undefined;
+/**
+ * The natural (ring-item-width-unit) gap between the hub and each ring node,
+ * from the arranger's own `sp` constraint - ECMA-376's "space between a
+ * hierarchical parent and its children", reused by every hub+ring composite
+ * examined for "space between the centre shape and each satellite".
+ * COM-verified against `basic-radial--hier5.pptx`: the hub-to-satellite
+ * screen distance (measured from the cached drawing) divides out to
+ * `r0 = 1.306` in this module's own natural unit space (ring item width =
+ * 1); `hubHalfWidth(0.5, hubRatio factor 1) + sp(0.3) + itemHalfWidth(0.5) =
+ * 1.3` matches within rounding of the cached pixel measurement. This is a
+ * DIFFERENT quantity from `sibSp` (adjacent-SATELLITE spacing, used for the
+ * chord-based `r0` solve `ringLayoutForGapFactor` already does for a plain,
+ * hub-less ring) - a hub+ring composite's own `r0` is governed by the
+ * hub-to-satellite gap instead, not by how close adjacent satellites sit to
+ * EACH OTHER (see `computeCycleRingLayout`'s own doc comment for how the two
+ * combine).
+ *
+ * `sp`'s own `refFor`/`refForName` can point at either end of the hub/item
+ * relationship - `basic-radial`/`radial-cycle` reference the ring ITEM
+ * itself (`sp` already in ring-item units, used directly); `diverging-radial`/
+ * `converging-radial` reference the HUB instead (`sp refForName="centerShape"`)
+ * - converted to ring-item units via `hubFactor` (the hub's own natural width
+ * is `1/hubFactor` in this unit space, same conversion `resolveHubToNodeRatio`
+ * itself uses). A BARE `sp` (no `refForName` at all - `radial-cluster--
+ * hier5.pptx`'s own nested `cycle_3`: `<dgm:constr type="sp" refType="w"
+ * fact="0.1"/>`, no cross-role reference of any kind) is treated the SAME as
+ * an explicit self-reference to the ring item (`sp.factor` used directly,
+ * ECMA-376's own default-target convention for an unqualified reference) -
+ * round 45 measured this alone does not reproduce `cycle_3`'s own cached
+ * hub-to-satellite distance exactly (a further, still-unidentified factor
+ * remains - see `smartart-layout-interpreter-cycle.ts`'s own `n===1` hub
+ * doc comment), but it is the general, spec-consistent reading and a real
+ * improvement over the previous behaviour (`undefined`, no hub gap applied
+ * at all). Returns `undefined` when `sp` references some OTHER name (neither
+ * the item nor the hub) or no hub is present at all, so the caller keeps the
+ * existing, COM-verified chord-only `r0` for every fixture this does not
+ * apply to.
+ */
+export declare function resolveHubGapRatio(itemName: string | undefined, hubRatio: HubToNodeRatio | undefined, arrangerConstraints: DiagramLayoutNode['constraints']): number | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-hub-ratio.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-hub-ratio.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-hub-ratio.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAe,MAAM,UAAU,CAAC;AAC/D,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAEpE,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,wDAAwD,CAAC;AAI7F,YAAY,EAAE,cAAc,EAAE,MAAM,wDAAwD,CAAC;AAE7F;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH,wBAAgB,qBAAqB,CACpC,QAAQ,EAAE,iBAAiB,GAAG,SAAS,EACvC,mBAAmB,EAAE,iBAAiB,CAAC,aAAa,CAAC,EACrD,KAAK,CAAC,EAAE,eAAe,EACvB,sBAAsB,CAAC,EAAE,iBAAiB,CAAC,gBAAgB,CAAC,EAC5D,cAAc,CAAC,EAAE,MAAM,EACvB,kBAAkB,CAAC,EAAE,SAAS,MAAM,EAAE,GACpC,cAAc,GAAG,SAAS,CA+B5B;AA+DD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqCG;AACH,wBAAgB,kBAAkB,CACjC,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,QAAQ,EAAE,cAAc,GAAG,SAAS,EACpC,mBAAmB,EAAE,iBAAiB,CAAC,aAAa,CAAC,GACnD,MAAM,GAAG,SAAS,CAiBpB"}

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

@@ -0,0 +1,121 @@
+/**
+ * SmartArt DiagramML interpreter - a ring item's own effective `h:w` aspect,
+ * when it is not a plain literal `fact`/sub-1 `val`: derived from an internal
+ * composite self+child pairing ({@link deriveCompositeSelfChildLayout}), or
+ * from the constraint GRAPH when the item's own `w` is itself reference-
+ * resolved ({@link resolveGraphAspectRatio}).
+ *
+ * Split out of `smartart-layout-interpreter-cycle-constraints.ts` (the
+ * file-size budget). Pure constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from './smartart-constraint-solver.js';
+/** A composite ring item's own self (uniform, ring-placed) + content-dependent child sub-shapes. */
+export interface CompositeContentLayout {
+    /** The "self" sub-shape's own `dgm:layoutNode/@name` (e.g. `parentNode`). */
+    selfName: string;
+    /** `self.w = selfWidthFactor * composite.w` - always a SQUARE (`self.h = self.w`), see the doc comment below. */
+    selfWidthFactor: number;
+    /** The content-dependent "child" sub-shape's own name (e.g. `childNode`), when found alongside `self`. */
+    childName?: string | undefined;
+    /** `child.l = childLeftFactor * self.w` (offset from the self shape's OWN left edge, in self-width units). */
+    childLeftFactor?: number | undefined;
+    /** `child.w = childWidthFactor * composite.w` (same "fraction of the whole composite" convention `selfWidthFactor` uses). */
+    childWidthFactor?: number | undefined;
+}
+/**
+ * `radial-list--hier5.pptx`'s own ring item (`node`) is a `composite` of
+ * `parentNode` (an ellipse, `alg="tx"`, the point's OWN text - always
+ * present) and `childNode` (a rect, side by side, the point's CHILD text -
+ * only present when the point has one) - `node` itself declares no direct
+ * `h` constraint at all, so `resolveRatioConstraint`'s own literal/indexed
+ * lookups both decline.
+ *
+ * The composite's own constrLst declares the real relationship: `parentNode
+ * .w = fact * node.w` (a `w` constraint targeting `parentNode`, with NO
+ * `refFor`/`refForName` - referencing the ENCLOSING composite's own width,
+ * ECMA-376's convention for an unqualified reference) PAIRED with `parentNode
+ * .h = parentNode.w` (a SELF-referential `h` constraint - same `for`/
+ * `forName` as its own `refFor`/`refForName`, i.e. "this child is square").
+ *
+ * An EARLIER round of this derivation used `selfWidthFactor` itself
+ * (`0.4` for `radial-list`) as the WHOLE ring item's own `heightOverWidth`,
+ * reasoning that `node.h = parentNode.h = parentNode.w = 0.4 * node.w`. That
+ * is arithmetically true but the WRONG quantity for `computeCycleRingLayout`'s
+ * own uniform "every point occupies the same natural footprint" ring-placement
+ * model: `node`'s own FULL width (including room for `childNode`) is only
+ * needed by a point that HAS a child - `radial-list--hier5.pptx`'s own cached
+ * ground truth shows a point WITHOUT a child rendering `parentNode` ALONE, at
+ * the SAME uniform size as every other point's own `parentNode` (204x154 for
+ * all three satellites, COM-verified), not stretched to fill the composite's
+ * full (content-dependent) width. The ring's own natural unit-width should
+ * therefore be `parentNode`'s OWN footprint, not the composite's - and since
+ * `parentNode` is declared SELF-SQUARE (`h = w`), that natural aspect is
+ * simply `1` (a circle, before the ring's own anisotropic scale renders it as
+ * an ellipse) - `resolveCycleRingParams` now uses this function only to
+ * DETECT the pattern (and recover the `1` fallback for `heightOverWidth`
+ * instead of the composite's own inflated aspect); the descriptor itself
+ * (`selfWidthFactor`/`childLeftFactor`/`childWidthFactor`) is threaded through
+ * for `smartart-layout-interpreter-cycle-ring-item.ts`'s own POST-PASS
+ * (mirroring `repositionPyramidBands`) that repositions each point's own
+ * content-dependent `childNode` copy relative to its already-correctly-placed
+ * `parentNode` copy.
+ *
+ * The child descriptor is read the SAME way: a sibling `dgm:layoutNode`
+ * declaring `l for="ch" forName=<child> refType="w" refFor="ch"
+ * refForName=<self> fact=G` (the child's own left edge, as a fraction of the
+ * self shape's width) PAIRED with `w for="ch" forName=<child> refType="w"
+ * fact=H` (the child's own width, as a fraction of the WHOLE composite -
+ * the SAME unqualified-reference convention `selfWidthFactor` itself uses).
+ * `radial-list--hier5.pptx`: `childLeftFactor=1.1`, `childWidthFactor=0.6` -
+ * COM-verified: `childNode.w = 0.6*node.w = 0.6*(parentNode.w/0.4) =
+ * 1.5*parentNode.w`, matching the cached rect's own width (305) against the
+ * cached ellipse's own width (204) to within rounding (204*1.5=306).
+ *
+ * General, not `radial-list`-specific: matches ANY composite whose
+ * constrLst declares a `for="ch"` width fraction (no `refFor`) for some
+ * child name, PAIRED with a self-referential `h`-equals-own-`w` constraint
+ * for that SAME child name - the first such pair in document order wins
+ * (matching `parentNode` appearing before `childNode` in every composite
+ * ring item examined). Declines (returns `undefined`) for a plain, non-
+ * `composite` item, or when no such pair is found, so
+ * `resolveCycleRingParams` keeps its existing fallback chain unchanged for
+ * every other ring item (`basic-cycle`'s `dummy`, `basic-radial`'s `node`
+ * ellipse-only item, ...).
+ */
+export declare function deriveCompositeSelfChildLayout(item: DiagramLayoutNode | undefined): CompositeContentLayout | undefined;
+/**
+ * A ring item's genuine `h:w` aspect ratio, resolved via the constraint
+ * GRAPH (`smartart-constraint-solver.ts`'s `resolveConstraint`) when the item
+ * declares no LITERAL `h` fact/sub-1 val of its own (`resolveRatioConstraint`'s
+ * own literal scan, `ratioConstraint`, already handles that simpler case and
+ * is unaffected by this function).
+ *
+ * `diverging-radial--hier5.pptx`'s own ring item ("node", an ellipse) is the
+ * fixture that exposed why this needs to be a SEPARATE step, not just "use
+ * the graph-resolved `h`": its own `h refType="w"` (no `fact` at all, i.e.
+ * ratio 1 - "my height equals my width", a circle before the ring's
+ * anisotropic box-fit stretches it) is declared self-referentially, but its
+ * own `w` is ALSO graph-resolved (the composite's OWN `w for="ch"
+ * forName="node" refType="w" refFor="ch" refForName="centerShape"
+ * fact="1.25"`, from `resolveHubToNodeRatio`'s SAME constraint) to `1.25`
+ * root-normalized units (see `smartart-constraint-solver.ts`'s `combine`:
+ * every graph-resolved quantity bottoms out at the root layoutNode's own
+ * implicit `w=h=1`, so `node.w` and `node.h` are BOTH expressed in that same
+ * absolute unit, not as a ratio of each other). Reading the graph-resolved
+ * `h` (1.25) directly AS the h:w ratio - what the old code did, because
+ * `resolveRatioConstraint`'s "relative" fallback (`resolveReferencedRatio`)
+ * has no notion of "also divide by `w`" - silently inflated `heightOverWidth`
+ * from the correct `1` (a circle, `h == w` when BOTH read in the same units)
+ * to `1.25`, corrupting `computeCycleRingLayout`'s anisotropic scale
+ * (COM-verified: interpreted satellite height 8.26% too tall vs the cached
+ * ellipse). The correct ratio is `resolvedH / resolvedW`, which is what this
+ * computes; it is a no-op improvement (declines, `undefined`, letting the
+ * caller's existing fallback chain run exactly as before) whenever the
+ * item's own `w` is NOT itself graph-resolved - e.g. `basic-radial`/
+ * `radial-cycle`'s own item nodes, whose `sibSp`/`sp` reference the ITEM
+ * directly rather than chaining through a `w`-referencing sibling, so their
+ * `w` role never gets an indexed entry at all.
+ */
+export declare function resolveGraphAspectRatio(item: DiagramLayoutNode | undefined, index: ConstraintIndex): number | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-item-aspect.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-item-aspect.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-item-aspect.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAElD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,8BAA8B,CAAC;AAEpE,oGAAoG;AACpG,MAAM,WAAW,sBAAsB;IACtC,6EAA6E;IAC7E,QAAQ,EAAE,MAAM,CAAC;IACjB,iHAAiH;IACjH,eAAe,EAAE,MAAM,CAAC;IACxB,0GAA0G;IAC1G,SAAS,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IAC/B,8GAA8G;IAC9G,eAAe,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACrC,6HAA6H;IAC7H,gBAAgB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;CACtC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2DG;AACH,wBAAgB,8BAA8B,CAC7C,IAAI,EAAE,iBAAiB,GAAG,SAAS,GACjC,sBAAsB,GAAG,SAAS,CA4DpC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,wBAAgB,uBAAuB,CACtC,IAAI,EAAE,iBAAiB,GAAG,SAAS,EACnC,KAAK,EAAE,eAAe,GACpB,MAAM,GAAG,SAAS,CAWpB"}

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

@@ -0,0 +1,57 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring ITEM node resolution.
+ *
+ * Split out of `smartart-layout-interpreter-cycle-constraints.ts` (repo
+ * per-file line budget): the ring's real per-point item template, when it is
+ * NOT simply the arranger's first child. Pure constraint/tree reading; no
+ * framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+/**
+ * The ring's real per-point item template, when it is NOT simply
+ * `constraintNode.children[0]` (`itemNode`'s own naive assumption).
+ *
+ * A hub+satellite composite ring (`radial-cycle`, `basic-radial`,
+ * `diverging-radial`, `converging-radial`) declares its own `constrLst`
+ * directly on the composite's TOP node (`centerShape`/`node`/`dummy`/
+ * `sibTrans`/`oneComp`/... all as SIBLING children, not nested inside a
+ * `"cycle"`-named descendant `resolveCycleConstraintNode` would find), so
+ * `itemNode()` picks up whichever child happens to be FIRST in document
+ * order - `centerShape` (the hub) for every sample checked, never the actual
+ * repeating ring item (`node`). `sibSp` ("minimum distance between SIBLING
+ * shapes") only has meaning between the REPEATING ring item, so whichever
+ * name its own `referenceForName` points to - when that name matches one of
+ * `constraintNode`'s actual children - is a genuine declarative signal for
+ * "this is the ring's real per-point template", not a per-layout-name guess.
+ * `basic-cycle`/`multidirectional-cycle` decline this path (their own
+ * `sibSp` references `composite`/`w`, not one of their own children's
+ * literal names) and keep `itemNode()`'s original children[0] behaviour,
+ * which was already COM-verified exact for them.
+ *
+ * The name match alone is not sufficient, though: `radial-list--hier5.pptx`
+ * ("Radial List") declares its `sibSp` as a fraction of the HUB's own width
+ * (`sibSp refType="w" refFor="ch" refForName="centerShape" fact="0.08"`, the
+ * per-satellite GAP sized off the hub, not the ring item) - the name match
+ * picks `centerShape` itself, a SINGULAR node reached only through a
+ * `dgm:choose` gate (never repeats per point), feeding the ring math the
+ * hub's own near-square aspect instead of the true, much wider
+ * ellipse+gap+rect ring-item aspect and corrupting every non-full-circle arc.
+ * A genuine repeating ring item is reached through an ENCLOSING `dgm:forEach`
+ * (`forEachOrigin` set - see that field's own doc comment on
+ * `DiagramLayoutNode`; `centerShape` has none, `node` does, reached via
+ * `forEach axis="ch"` then `forEach axis="self" ptType="node"`), so the name
+ * match is only trusted when it also carries one; otherwise this falls back
+ * to the first child that genuinely repeats, before `itemNode()`'s original
+ * children[0] guess.
+ *
+ * A connector (`alg.type==='conn'`) can ALSO carry `forEachOrigin` (it
+ * repeats once per transition point too) and sit BEFORE the real text item
+ * in document order (`radial-cluster`'s own `singleCycle`: its `Name56`
+ * connector precedes `text0`) - skip a repeating connector when a repeating
+ * NON-connector sibling exists, falling back to the old first-match
+ * behaviour only when every repeating child is a connector (unchanged for
+ * every fixture already measured, where the first repeating child was never
+ * a connector).
+ */
+export declare function resolveRingItemNode(constraintNode: DiagramLayoutNode, arrangerConstraints: DiagramLayoutNode['constraints']): DiagramLayoutNode | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-item-node.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-item-node.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-item-node.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAGlD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AACH,wBAAgB,mBAAmB,CAClC,cAAc,EAAE,iBAAiB,EACjC,mBAAmB,EAAE,iBAAiB,CAAC,aAAa,CAAC,GACnD,iBAAiB,GAAG,SAAS,CAe/B"}

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

@@ -0,0 +1,34 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring `sibTrans` bulge bounds.
+ *
+ * Split out of `smartart-layout-interpreter-cycle-ring.ts` (the repo's
+ * per-file line budget) - the satellite-only natural bounding box, plus the
+ * SEPARATE, bulge-expanded box used only for the ring's own scale divisor
+ * (`smartart-layout-interpreter-cycle-sibtrans.ts` has the full `sibTrans`
+ * derivation).
+ *
+ * Pure geometry; no framework code.
+ */
+export interface RingBulgeBounds {
+    /** Satellite-only extremes (no bulge) - `centers`/`hubCenter` map relative to these, and `resolveRingAxisOffset` uses `naturalBoundW`/`naturalBoundH` (not the bulge-expanded ones) so neither the flush nor the tied margin split shifts. */
+    minX: number;
+    maxX: number;
+    minY: number;
+    maxY: number;
+    naturalBoundW: number;
+    naturalBoundH: number;
+    /** Bulge-expanded on both extremes - the SCALE divisor only. */
+    scaleBoundW: number;
+    scaleBoundH: number;
+}
+/**
+ * The satellite-only bounding box (`halfW`/`halfH` around every natural
+ * point), plus a SEPARATE bulge-expanded box for the scale divisor only -
+ * see `RingBulgeBounds`'s own field docs, and `smartart-layout-interpreter-
+ * cycle-ring.ts`'s own call site for the measured regression this split
+ * fixes (bulge-expanding the SAME box `resolveRingAxisOffset` uses shifted
+ * a flush satellite ~34px off the box edge, and a tied-axis ring ~34px off
+ * box-centre, in opposite directions).
+ */
+export declare function computeRingBulgeBounds(xs: number[], ys: number[], halfW: number, halfH: number, sibTransBulgeRatio: number | undefined): RingBulgeBounds;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-ring-bulge.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-ring-bulge.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-ring-bulge.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,MAAM,WAAW,eAAe;IAC/B,8OAA8O;IAC9O,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,aAAa,EAAE,MAAM,CAAC;IACtB,aAAa,EAAE,MAAM,CAAC;IACtB,gEAAgE;IAChE,WAAW,EAAE,MAAM,CAAC;IACpB,WAAW,EAAE,MAAM,CAAC;CACpB;AAED;;;;;;;;GAQG;AACH,wBAAgB,sBAAsB,CACrC,EAAE,EAAE,MAAM,EAAE,EACZ,EAAE,EAAE,MAAM,EAAE,EACZ,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,kBAAkB,EAAE,MAAM,GAAG,SAAS,GACpC,eAAe,CAkBjB"}

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

@@ -0,0 +1,39 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring content-dependent child
+ * repositioning (`radial-list--hier5.pptx`'s own `parentNode`/`childNode`
+ * composite ring item).
+ *
+ * `smartart-layout-interpreter-item-role-stack.ts`'s `stackRoleContent`
+ * cannot split a `circle`-kind ring item's own geometry the way a `rect`
+ * splits by height (see that module's own doc comment) - each role
+ * (`parentNode` "self", `childNode` "des") starts as an UNCHANGED copy of
+ * the ring's own already-placed circle, tagged `itemRoleName`. This module
+ * is the arranger-specific geometry pass that module's doc comment calls
+ * for (mirroring `smartart-layout-interpreter-pyramid-bands.ts`'s
+ * `repositionPyramidBands` for the pyramid family): the "self" copy is
+ * already correct (the ring placed it directly); the "child" copy, present
+ * only on a point that HAS a child, is repositioned beside its own "self"
+ * sibling using the item template's own declared `l`/`w` fractions
+ * (`smartart-layout-interpreter-cycle-item-aspect.ts`'s
+ * `CompositeContentLayout`, COM-verified against `radial-list--hier5.pptx`).
+ *
+ * Pure geometry; no framework code.
+ */
+import type { DiagramNode } from '../model/index.js';
+import type { CompositeContentLayout } from './smartart-layout-interpreter-cycle-item-aspect.js';
+import type { SmartArtLayoutResult } from './smartart-layout-types.js';
+/**
+ * Reposition every `childName`-tagged ring entry beside its own `selfName`
+ * sibling (the SAME point's own "self" role, found via `flatNodes`' own
+ * `parentId` linkage - a `des`-axis child role resolves to the CHILD data
+ * node's own id, a DIFFERENT id from the point it visually sits beside, so
+ * matching by `nodeId` directly - the way `repositionPyramidBands` matches
+ * an accent to its row - does not apply here; the lookup goes through the
+ * child's own parent instead). A no-op when `contentLayout` does not
+ * describe a child sub-shape at all (a plain ring item with no composite
+ * self+child split), or when a `childName`-tagged entry's own self sibling
+ * cannot be found (declines that ONE entry, leaves it as the unchanged copy
+ * `stackRoleContent` produced - never drops a shape).
+ */
+export declare function repositionCycleRingContent(result: SmartArtLayoutResult, contentLayout: CompositeContentLayout | undefined, flatNodes: readonly DiagramNode[]): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-ring-item.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-ring-item.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-ring-item.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC5C,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,iDAAiD,CAAC;AAC9F,OAAO,KAAK,EAGX,oBAAoB,EACpB,MAAM,yBAAyB,CAAC;AAEjC;;;;;;;;;;;;GAYG;AACH,wBAAgB,0BAA0B,CACzC,MAAM,EAAE,oBAAoB,EAC5B,aAAa,EAAE,sBAAsB,GAAG,SAAS,EACjD,SAAS,EAAE,SAAS,WAAW,EAAE,GAC/B,oBAAoB,CA6CtB"}

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

@@ -0,0 +1,22 @@
+/**
+ * SmartArt DiagramML interpreter - the `n===1` nested hub+one-satellite ring
+ * case (round 46).
+ *
+ * Split out of `smartart-layout-interpreter-cycle-ring.ts` to keep that file
+ * under the repo's per-file line budget. Pure geometry; no framework code.
+ */
+import type { CycleRingLayout, HubRingGeometry } from './smartart-layout-interpreter-cycle-ring.js';
+import type { BoundingBox } from './smartart-layout-types.js';
+/**
+ * A genuinely nested hub+one-satellite ring whose node width is ALREADY
+ * known (`radial-cluster--hier5.pptx`'s `cycle_3`, both "Four" (hub) and
+ * "Five" (satellite) independently sized off the same diagram-wide `userS`
+ * fact - see `arrangeCycle`'s own `knownNodeWidthPx` doc comment). Unlike
+ * the plain `n===1` degenerate case (no hub, stretches to fill the box),
+ * this places the hub at the box centre and the one satellite at `r0` (hub
+ * half-extent + `hubGeometry.gapRatio` + item half-extent, in node-width
+ * units - the SAME formula the non-degenerate hub+ring path uses) along
+ * `stAngDeg`, both sized at the known width.
+ */
+export declare function nestedHubSatelliteRingLayout(stAngDeg: number, heightOverWidth: number, box: BoundingBox, hubGeometry: HubRingGeometry, nodeWidthPx: number): CycleRingLayout;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-ring-nested-hub.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-ring-nested-hub.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-ring-nested-hub.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,KAAK,EAAE,eAAe,EAAE,eAAe,EAAE,MAAM,0CAA0C,CAAC;AACjG,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAC;AAI3D;;;;;;;;;;GAUG;AACH,wBAAgB,4BAA4B,CAC3C,QAAQ,EAAE,MAAM,EAChB,eAAe,EAAE,MAAM,EACvB,GAAG,EAAE,WAAW,EAChB,WAAW,EAAE,eAAe,EAC5B,WAAW,EAAE,MAAM,GACjB,eAAe,CAmBjB"}

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

@@ -0,0 +1,43 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring per-axis slack placement.
+ *
+ * Split out of `smartart-layout-interpreter-cycle-ring.ts` (the repo's
+ * per-file line budget) - this is the single `resolveRingAxisOffset` helper,
+ * kept in its own file with its own doc comment.
+ *
+ * Pure geometry; no framework code.
+ */
+/**
+ * SESSION 16: a ring's slack on ONE axis is not always centred - live-COM
+ * measurement (`radial-cycle--hier5.pptx`, a hub+3-satellite ring: 1
+ * satellite alone at the top, 2 tied at the bottom) found the box's near
+ * edge sitting FLUSH (measured top margin 0.17pt of a 400pt box) against
+ * whichever side has the LONE satellite, with ALL the slack pushed to the
+ * opposite (tied-satellite) side (measured bottom margin 52.68pt) - not
+ * split evenly the way `ringLayoutForGapFactor`'s own centred formula
+ * (unchanged before this session) assumed.
+ *
+ * The general rule this generalises to, verified against every existing
+ * passing fixture before landing (see the call site's own comment): for a
+ * `stAng`-rotated regular n-gon, whichever extreme (min or max) on an axis
+ * is reached by FEWER satellites is the "lone" side and sits flush (zero
+ * margin); the extreme reached by MORE satellites keeps the leftover slack.
+ * When BOTH extremes are reached by the same count (`basic-cycle--
+ * flat3.pptx`'s own hub-less n=3 ring on its OWN binding axis - content
+ * fills 99.98% of the box height already, so there is no real slack either
+ * way to distinguish the two models; `basic-radial--hier5.pptx`'s n=4 ring,
+ * where a point sits at BOTH poles for an even n, genuinely IS 1-vs-1 on
+ * both axes) this reduces to the ORIGINAL centred formula exactly - a
+ * strict generalisation, not a special case.
+ *
+ * `values` are the RAW natural-space satellite centre coordinates on this
+ * axis (not yet offset by the item's own half-extent). The caller's own
+ * `centers` mapping is `(naturalCoord - low) * scale + offset` (already
+ * `low`-relative before this function ever runs), so at the LOW extreme
+ * (`naturalCoord===low`) the mapped position is simply `offset` - flush
+ * there means `offset=0`, not a `low`-dependent term. `boundSize` is the
+ * axis's own already-half-extent-adjusted span (`maxX-minX`/`maxY-minY`,
+ * floored at `1e-6`).
+ */
+export declare function resolveRingAxisOffset(dimension: number, boundSize: number, scale: number, values: number[]): number;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-ring-offset.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-ring-offset.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-ring-offset.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAKH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AACH,wBAAgB,qBAAqB,CACpC,SAAS,EAAE,MAAM,EACjB,SAAS,EAAE,MAAM,EACjB,KAAK,EAAE,MAAM,EACb,MAAM,EAAE,MAAM,EAAE,GACd,MAAM,CAoBR"}

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

@@ -0,0 +1,76 @@
+/**
+ * SmartArt DiagramML interpreter - cycle ring geometry (fixed-point solve).
+ *
+ * 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 of the "natural circle, then isotropic CONTAIN fit,
+ * centred" model (round 11/SESSION 8: live PowerPoint COM proved cached
+ * SmartArt geometry is placed at its OWN constraint-derived size, centred in
+ * the frame when smaller than it, never independently stretched per axis -
+ * see ECMA-376 21.4.7; a prior "anisotropic fill-to-box" model here was
+ * measured against a NOW-FIXED reader bug and reproduced NO real PowerPoint
+ * output, see the parent module's doc comment for the full history); this
+ * file is purely the numeric machinery (no constraint reading).
+ *
+ * Pure geometry; no framework code.
+ */
+import type { BoundingBox } from './smartart-layout-types.js';
+/** One natural-space (pre box-fit) point on the ring. */
+interface NaturalPoint {
+    x: number;
+    y: number;
+}
+/** Result of fitting `n` ring nodes (plus an optional centred hub) to `box`. */
+export interface CycleRingLayout {
+    /** Node CENTRE points, in box-local pixel coordinates (0..box.width / 0..box.height). */
+    centers: NaturalPoint[];
+    /** Uniform node width/height across the whole ring, in pixels. */
+    nodeWidth: number;
+    nodeHeight: number;
+    /** The ring's own natural centre, mapped into box-local pixel coordinates - the best available centre for a `ctrShpMap="fNode"` hub. */
+    hubCenter: NaturalPoint;
+    /** Hub half-extents (pixels) that keep it clear of the nearest ring node - see the module doc comment's `naturalHubRadius` note. */
+    hubHalfWidth: number;
+    hubHalfHeight: number;
+}
+/**
+ * A hub+ring composite's own centre-to-satellite sizing (see
+ * `smartart-layout-interpreter-cycle-hub-ratio.ts`'s `resolveHubToNodeRatio`/
+ * `resolveHubGapRatio`): `factor` is the ring item's width as a fraction of
+ * the hub's own (so the hub's natural half-width is `0.5 / factor`), and
+ * `gapRatio` is the declared `sp` space between the hub's edge and each
+ * satellite's edge, both already converted to this module's own natural
+ * unit space (ring item width = 1).
+ */
+export interface HubRingGeometry {
+    factor: number;
+    gapRatio: number;
+}
+/**
+ * Fit `n` ring nodes evenly spaced by `spanDeg` (full circle when
+ * `abs(spanDeg) >= 360`, else split over `n - 1` gaps like `stAng + spanAng`
+ * landing on the LAST point) starting at `stAng`, honouring `minGapRatio`
+ * (the resolved `sibSp`, floored - see `smartart-layout-interpreter-cycle-
+ * constraints.ts`'s `DEFAULT_MIN_GAP_RATIO`) and `heightOverWidth` (the item
+ * node's own resolved `h:w` fact), into `box`. See the parent module's doc
+ * comment for the derivation and what it does and does not reproduce
+ * exactly.
+ *
+ * `absoluteGapPx`, when given (an ABSOLUTE `sibSp` `val`, points -> pixels -
+ * see `resolveCycleRingParams`), OVERRIDES `minGapRatio`: geometry is solved
+ * in a "natural" unit space (node width = 1), so an absolute pixel gap needs
+ * `gapFactor = absoluteGapPx / nodeWidthPx`, which itself depends on
+ * `nodeWidth` - resolved by fixed-point iteration (guess `gapFactor`, refine
+ * from the resulting `nodeWidth`, repeat). COM-verified against
+ * `continuous-cycle--flat3.pptx` (`sibSp val="15"` = 20px): converges to
+ * `gapFactor ~= 0.0472`, `nodeWidth ~= 423.5` vs the cached 420 (0.8%).
+ *
+ * `absoluteHubGapPx`, when given (an ABSOLUTE `sp val`, e.g. `radial-list
+ * --hier5.pptx`'s own `<dgm:constr type="sp" val="20"/>`): the SAME
+ * fixed-point idea, refining `hubGeometry.gapRatio` toward
+ * `absoluteHubGapPx / nodeWidthPx` instead - both can run in the SAME loop
+ * when a layout declares both.
+ */
+export declare function computeCycleRingLayout(n: number, stAngDeg: number, spanDeg: number, minGapRatio: number, heightOverWidth: number, box: BoundingBox, absoluteGapPx?: number, hubGeometry?: HubRingGeometry, absoluteHubGapPx?: number, sibTransBulgeRatio?: number, knownNodeWidthPx?: number): CycleRingLayout;
+export {};
+//# sourceMappingURL=smartart-layout-interpreter-cycle-ring.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-ring.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-ring.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAKH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAC;AAI3D,yDAAyD;AACzD,UAAU,YAAY;IACrB,CAAC,EAAE,MAAM,CAAC;IACV,CAAC,EAAE,MAAM,CAAC;CACV;AAED,gFAAgF;AAChF,MAAM,WAAW,eAAe;IAC/B,yFAAyF;IACzF,OAAO,EAAE,YAAY,EAAE,CAAC;IACxB,kEAAkE;IAClE,SAAS,EAAE,MAAM,CAAC;IAClB,UAAU,EAAE,MAAM,CAAC;IACnB,wIAAwI;IACxI,SAAS,EAAE,YAAY,CAAC;IACxB,oIAAoI;IACpI,YAAY,EAAE,MAAM,CAAC;IACrB,aAAa,EAAE,MAAM,CAAC;CACtB;AAoCD;;;;;;;;GAQG;AACH,MAAM,WAAW,eAAe;IAC/B,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;CACjB;AAyGD;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,wBAAgB,sBAAsB,CACrC,CAAC,EAAE,MAAM,EACT,QAAQ,EAAE,MAAM,EAChB,OAAO,EAAE,MAAM,EACf,WAAW,EAAE,MAAM,EACnB,eAAe,EAAE,MAAM,EACvB,GAAG,EAAE,WAAW,EAChB,aAAa,CAAC,EAAE,MAAM,EACtB,WAAW,CAAC,EAAE,eAAe,EAC7B,gBAAgB,CAAC,EAAE,MAAM,EACzB,kBAAkB,CAAC,EAAE,MAAM,EAC3B,gBAAgB,CAAC,EAAE,MAAM,GACvB,eAAe,CAmEjB"}

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

@@ -0,0 +1,40 @@
+/**
+ * SmartArt DiagramML interpreter - `cycle` ring `sibTrans` connector
+ * clearance (SESSION 21).
+ *
+ * `radial-cycle--{hier5,hier8}.pptx`'s own ~9% scale residual is NOT a
+ * hub-ratio bug (the hub:item ratio, and the ring's own `r0`, both already
+ * match cached geometry within 0.5% - see `smartart-track-r-successor.md`'s
+ * own SESSION 20 section for the full measurement). The remaining gap is
+ * that `radial-cycle` uniquely (among the gallery's hub+ring family)
+ * declares a `sibTrans` `dgm:layoutNode` - a CURVED connector between
+ * adjacent satellite CENTRES (`dgm:alg type="conn"`, `connRout="curve"`,
+ * `begPts="ctr"`, `endPts="ctr"`) - that neither `basic-radial` (no
+ * connector layoutNode at all) nor `diverging-radial`/`converging-radial`
+ * (a `parTrans`, hub-to-satellite, not satellite-to-satellite) declare.
+ * `basic-cycle`'s own hub-less ring ALSO declares a `sibTrans`, but its own
+ * `connRout` is a plain straight line there (not `curve`), so it needs no
+ * extra clearance - the `curve` routing specifically is what bulges past
+ * the chord between two adjacent satellite centres, needing extra room in
+ * the ring's own natural bounding box beyond what the satellites' own
+ * edges already reserve.
+ *
+ * The bulge amount is declared directly: `h for="ch" forName="sibTrans"
+ * refType="w" refFor="ch" refForName="<item>" fact="0.24"` (radial-cycle's
+ * own value) - the connector's own natural "height" (perpendicular bulge),
+ * as a fraction of the ring item's own natural width (unit 1 in
+ * `smartart-layout-interpreter-cycle-ring.ts`'s own natural space).
+ *
+ * Pure constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+/**
+ * The `sibTrans` curve connector's own natural bulge, as a fraction of the
+ * ring item's own natural width - `undefined` when this composite declares
+ * no curve-routed, centre-to-centre sibling connector at all (every
+ * hub+ring family checked except `radial-cycle`, and `basic-cycle`'s own
+ * straight-routed `sibTrans`). See the module doc comment for the full
+ * derivation.
+ */
+export declare function resolveSibTransBulgeRatio(constraintNode: DiagramLayoutNode, arrangerConstraints: DiagramLayoutNode['constraints']): number | undefined;
+//# sourceMappingURL=smartart-layout-interpreter-cycle-sibtrans.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-cycle-sibtrans.d.ts","sourceRoot":"","sources":["../../../diagram/layout/smartart-layout-interpreter-cycle-sibtrans.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AA0BlD;;;;;;;GAOG;AACH,wBAAgB,yBAAyB,CACxC,cAAc,EAAE,iBAAiB,EACjC,mBAAmB,EAAE,iBAAiB,CAAC,aAAa,CAAC,GACnD,MAAM,GAAG,SAAS,CA4BpB"}