ooxml-core 1.1.0 → 1.2.0

package/dist/diagram/hierarchy/smartart-hierarchy-child-order.d.ts

@@ -0,0 +1,41 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy sibling ordering.
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * this is a standalone concern (fixing up `dgm:ptLst` declaration order into
+ * true left-to-right sibling order before `buildTree` runs), unrelated to
+ * that module's axis-transposition machinery.
+ *
+ * Pure geometry/data reordering; no framework code, no DOM.
+ */
+import type { DiagramNode } from '../model/index.js';
+/**
+ * Reorder `nodes` by `childOrder` (`childId -> srcOrd`, built from `dgm:cxn`'s
+ * own `srcOrd` by `smartart-layout-interpreter.ts`'s `buildChildOrder`) - the
+ * flat array is in `dgm:ptLst` declaration order, which is NOT necessarily
+ * true left-to-right sibling order (COM-verified against
+ * `hierarchy--hier8.pptx`: 5 siblings' `ptLst` order does not match their
+ * cached rendering order, but sorting by `srcOrd` reproduces it exactly).
+ *
+ * `srcOrd` is only meaningful WITHIN one parent's own children - every parent
+ * numbers its direct reports independently starting near 0/1, so a manager
+ * with id "M2" and a manager with id "M4" can each have a child at `srcOrd
+ * 0`. Sorting the WHOLE flat array by that value directly (comparing across
+ * different parents) interleaves unrelated branches and corrupts the tree
+ * `buildTree` is about to build from this array's order - COM-verified
+ * regression against `smartart-orgchart-fan-variants.pptx` (multiple
+ * managers, each with several reports): a global sort scattered 14 of the
+ * genuine-fixture suite's row/stack assertions by hundreds of pixels, while
+ * `hierarchy--hier8.pptx` (a single flat generation, one parent) never
+ * exercised the multi-parent case at all. Only compares `srcOrd` between
+ * nodes that share the SAME `parentId`; a stable sort (guaranteed by the
+ * language since ES2019) preserves the original relative order between
+ * different sibling groups untouched, so this generalises to any number of
+ * branches instead of only the single-parent case it was first measured on.
+ * Falls back to the node's original array position when it has no
+ * `childOrder` entry (e.g. the root) so relative order among those is
+ * unchanged. A no-op (returns `nodes` unchanged) when `childOrder` is absent,
+ * so every caller that does not have connection data keeps prior behaviour.
+ */
+export declare function applyChildOrder<N extends DiagramNode>(nodes: N[], childOrder: Map<string, number> | undefined): N[];
+//# sourceMappingURL=smartart-hierarchy-child-order.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-child-order.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-child-order.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-child-order.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAE5C;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,wBAAgB,eAAe,CAAC,CAAC,SAAS,WAAW,EACpD,KAAK,EAAE,CAAC,EAAE,EACV,UAAU,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,SAAS,GACzC,CAAC,EAAE,CAeL"}

package/dist/diagram/hierarchy/smartart-hierarchy-composite-child.d.ts

@@ -0,0 +1,129 @@
+/**
+ * SmartArt DiagramML interpreter - the hierarchy `composite` node's own
+ * text-bearing child geometry (round 11/SESSION 9 correction).
+ *
+ * `resolveAspectRatio` (`smartart-hierarchy-orientation.ts`) reads the item's
+ * own `h:w` from `algorithmNode`'s (the `hierChild`'s) OWN top-level
+ * `constrLst` - which, for the classic (non-transposed) "Hierarchy" family,
+ * declares `h for="des" forName="composite" refType="w" refFor="des"
+ * refForName="composite" fact="0.667"`. That IS a genuine, self-referential
+ * `h:w` declaration - but it describes the WRAPPING `composite` layoutNode's
+ * own bounding box, not the RENDERED "text" shape the gate actually compares
+ * against (composite additionally nests a "background" `sp`-alg sibling for
+ * a two-shape "3D stacked card" decorative effect real PowerPoint renders -
+ * `background`/`text` are BOTH smaller than their own `composite` cell).
+ *
+ * `composite`'s own LOCAL `constrLst` (a genuinely separate scope, nested
+ * inside the `composite` layoutNode itself, only reachable by walking the
+ * tree - not part of `hierChild`'s own flat constraint list) declares the
+ * rendered child's REAL geometry directly: `w for="ch" forName="text"
+ * refType="w" fact="0.9"` (the child's own width, as a fraction of
+ * `composite`'s width) and `h for="ch" forName="text" refType="w"
+ * refFor="ch" refForName="text" fact="0.635"` (SELF-referential - the
+ * child's own `h:w`, unrelated to `composite`'s `0.667`). Hand-verified
+ * against THREE independent measurements: `hierarchy--flat3.pptx` (real
+ * cached box 319.92x203.15, ratio 0.63500), `--hier5.pptx` (205.66x130.60,
+ * ratio 0.63500), `--hier8.pptx` (144.35x91.66, ratio 0.63500) - all
+ * EXACTLY `0.635`, matching this constraint's own declared `fact` digit for
+ * digit, not `0.667`. "Horizontal Hierarchy" (and every other transposed
+ * hierarchy-family layout checked) declares NO `composite` wrapper at all -
+ * its own top-level `w=2*h` IS the rendered node's real aspect directly (no
+ * indirection to correct), so this module's own `findCompositeDescendant`
+ * simply returns `undefined` for it and every caller falls back to the
+ * EXISTING (already-correct) `resolveAspectRatio` path unchanged.
+ *
+ * SESSION 21: a SECOND composite-child shape exists (`circle-picture-
+ * hierarchy--hier5.pptx`'s own `text`, alongside a non-text `pic`/label
+ * sibling occupying the REST of the composite's width): `w for="ch"
+ * forName="text" refType="w" fact="0.6"` (self-referential, same SHAPE as
+ * the classic family's `fact="0.9"`) but `h for="ch" forName="text"
+ * refType="h" fact="0.8"` - `refType="h"`, NOT `"w"`, with no `refFor`/
+ * `refForName` at all: relative to the composite's own HEIGHT, not
+ * self-referential. This is the SAME "parent-relative" shape SESSION
+ * 18/19 found (and left unlanded, paired with a THEN-unresolved
+ * `fitItemBox` size regression) for `half-circle-organization-chart`'s own
+ * `rootText` - landed HERE because `circle-picture-hierarchy` is `std` mode
+ * (plain "Hierarchy" family, not `tailed` org-chart), so `fitItemBox`'s
+ * `clampToNaturalAspect` stays unconditionally `true` and the org-chart-only
+ * regression does not apply. Conversion: `childAspect = heightFactor *
+ * wrapperAspect / widthFactor` (`wrapperAspect` = the WRAPPING composite's
+ * own top-level `h:w`, `0.5` here) - `0.8 * 0.5 / 0.6 = 0.6667`, matching
+ * `circle-picture-hierarchy--hier5.pptx`'s own cached `144/216 = 0.6667`
+ * EXACTLY.
+ *
+ * `text`'s own `l`/`t` constraints (ALSO declared in `composite`'s own local
+ * `constrLst`, `fact="0.1"`/`fact="0.095"`, both relative to `composite`'s
+ * own `w`) are the "3D card" visual offset between `background` (flush at
+ * `composite`'s own top-left, `t`/`l` absent = 0) and `text` (the shape
+ * actually rendered/matched) - hand-verified against `hierarchy--flat3
+ * .pptx` (measured `text.x - background.x = 35.55px`, `0.1 * (319.92/0.9) =
+ * 35.55` exact) and `--hier5.pptx` (`21.71px` measured, `0.1 * (205.66/0.9)
+ * = 22.85`... within rounding of the measured `21.81`, see this module's
+ * own doc comment history in `smartart-track-r-successor.md` for the full
+ * cross-check). The FAN axis's own real positioning needs this: composite
+ * CELLS (not the smaller rendered child) are what actually get centred with
+ * the layout's own declared (unconverted) `sibSp`, and `text`'s own
+ * constant `l` offset is added on top afterward - see
+ * `smartart-layout-interpreter-hierarchy.ts`'s own fan-axis wiring.
+ *
+ * Pure geometry/constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+export interface CompositeChildGeometry {
+    /** The rendered child's own `h:w`, self-referential - see the module doc comment. */
+    aspectRatio: number;
+    /** The rendered child's own width, as a fraction of the WRAPPING `composite` node's width. */
+    widthFactor: number;
+    /** The rendered child's own leading-edge (`l`) offset from `composite`'s own left edge, as a fraction of `composite`'s width - the fan-axis "3D card" offset. */
+    offsetXRatio: number;
+    /**
+     * The rendered child's own height, as a fraction of the WRAPPING
+     * `composite` node's own height - the generation-axis mirror of
+     * `widthFactor`. Only populated for the "parent-relative" shape (SESSION
+     * 21: `h refType="h"`, e.g. `half-circle-organization-chart`), where the
+     * composite's own height genuinely differs from the rendered item's own
+     * height (`compositeAspect !== aspectRatio`) - `undefined` for the
+     * self-referential shape (plain "Hierarchy"), where no caller has yet
+     * needed this distinction (see `smartart-hierarchy-axis-pitch.ts`'s own
+     * SESSION 28 use, gated on this field so `std`-mode callers are unaffected).
+     */
+    heightFactor?: number;
+}
+/**
+ * Depth-first search for a descendant `dgm:layoutNode` whose own algorithm is
+ * `composite` (the structural signal, not a name convention). Exported for
+ * `smartart-hierarchy-constraint-lookup.ts`'s `resolveIndexedAspectRatio`
+ * (SESSION 38): the SAME "wrapping composite reached from root scope" node
+ * this module already resolves the rendered child's geometry from also names
+ * the role an indirect (`w`/`h` declared as two independent references, no
+ * direct cross-ratio) aspect fallback should resolve against.
+ */
+export declare function findCompositeDescendant(node: DiagramLayoutNode | undefined): DiagramLayoutNode | undefined;
+/**
+ * Resolve the rendered child's own aspect/width/offset facts from
+ * `algorithmNode`'s own `composite`-alg descendant, when one exists (see the
+ * module doc comment). Returns `undefined` for a layoutDef with no such
+ * wrapper (e.g. "Horizontal Hierarchy") - callers keep their existing
+ * fallback behaviour unchanged in that case.
+ */
+export declare function resolveCompositeChildGeometry(algorithmNode: DiagramLayoutNode | undefined, wrapperAspect?: number, allowOmittedWidthFactor?: boolean): CompositeChildGeometry | undefined;
+/**
+ * SESSION 32: the SAME "compound, multi-role text box" structural signal
+ * `resolveCompositeChildGeometry` bails on (see this module's own SESSION 28
+ * doc comment above), exposed standalone for callers that need to know
+ * WHETHER a layout declares this shape without needing its (unresolvable)
+ * aspect/width/offset geometry - `smartart-hierarchy-orientation.ts`'s own
+ * `hangHeightRatio` generalisation (SESSION 32) must NOT apply to
+ * `name-and-title-organization-chart--hier5.pptx`: that fixture's own
+ * `rootText1` height is not determined by a single declared `fact` at all
+ * (two stacked rows), so `generationGapRatio` - the single-role fan/generation
+ * gap - is not a trustworthy stand-in for ITS hang-row gap either (COM-verified
+ * regression: applying it anyway makes this fixture's own residual worse,
+ * `0.0415` -> `0.0542`, while `organization-chart--hier5.pptx`/
+ * `picture-organization-chart--hier5.pptx` - the SAME tree shape, a plain,
+ * single-role `rootText1` - go to exactly `0`). Returns `false` (not just
+ * `undefined`) for a layoutDef with no `composite` wrapper at all, matching
+ * `resolveCompositeChildGeometry`'s own "nothing to bail on" convention.
+ */
+export declare function compositeDeclaresCompoundTextRole(algorithmNode: DiagramLayoutNode | undefined): boolean;
+//# sourceMappingURL=smartart-hierarchy-composite-child.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-composite-child.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-composite-child.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-composite-child.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqEG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAElD,MAAM,WAAW,sBAAsB;IACtC,qFAAqF;IACrF,WAAW,EAAE,MAAM,CAAC;IACpB,8FAA8F;IAC9F,WAAW,EAAE,MAAM,CAAC;IACpB,iKAAiK;IACjK,YAAY,EAAE,MAAM,CAAC;IACrB;;;;;;;;;;OAUG;IACH,YAAY,CAAC,EAAE,MAAM,CAAC;CACtB;AAED;;;;;;;;GAQG;AACH,wBAAgB,uBAAuB,CACtC,IAAI,EAAE,iBAAiB,GAAG,SAAS,GACjC,iBAAiB,GAAG,SAAS,CAc/B;AAaD;;;;;;GAMG;AACH,wBAAgB,6BAA6B,CAC5C,aAAa,EAAE,iBAAiB,GAAG,SAAS,EAC5C,aAAa,CAAC,EAAE,MAAM,EACtB,uBAAuB,UAAQ,GAC7B,sBAAsB,GAAG,SAAS,CAuHpC;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,iCAAiC,CAChD,aAAa,EAAE,iBAAiB,GAAG,SAAS,GAC1C,OAAO,CAWT"}

package/dist/diagram/hierarchy/smartart-hierarchy-constraint-lookup.d.ts

@@ -0,0 +1,76 @@
+/**
+ * SmartArt DiagramML interpreter - small constraint-lookup helpers shared by
+ * the hierarchy orientation/generation-gap modules.
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * `findByReference`/`resolveAspectRatio`, alongside the fallback constant
+ * both consume. Pure geometry/constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+/** COM-verified "Hierarchy" fallback (`h:w`, absent any declared aspect - see `resolveAspectRatio`). */
+export declare const DEFAULT_ASPECT_RATIO = 0.667;
+/**
+ * A constraint search that only cares about `type`/`referenceType`/`factor` -
+ * broader than `findConstraint` (which cannot filter by `referenceType`).
+ * Exported for `smartart-hierarchy-generation-gap.ts` too.
+ *
+ * `preferredName` (SESSION 29): when given, a match whose own `forName`
+ * equals it wins over a plain document-order first match - see
+ * `resolveAspectRatio`'s own doc comment for why a layoutDef with more than
+ * one named item template (`horizontal-multi-level-hierarchy--hier5.pptx`'s
+ * own `LevelOneTextNode`/`LevelTwoTextNode`) needs this: a blind first-match
+ * silently picks whichever item happens to be declared FIRST in the
+ * `hierChild`'s own constrLst, which is the one-off ROOT template here, not
+ * the template the vast majority of rendered nodes actually use.
+ */
+export declare function findByReference(constraints: DiagramLayoutNode['constraints'], type: string, referenceType: string, preferredName?: string): number | undefined;
+/**
+ * The item's own `h:w` (non-transposed) ratio, read directly from whichever
+ * of the two equivalent declarations is present: `h` referencing `w` (a
+ * fact IS the ratio - "Hierarchy"'s own shape) or `w` referencing `h` (a
+ * fact is the ratio's RECIPROCAL - "Horizontal Hierarchy"'s shape, e.g.
+ * `w=2*h` means `h:w=0.5`). Falls back to `DEFAULT_ASPECT_RATIO` when
+ * neither is declared (matches every layout examined that omits it).
+ *
+ * `preferredName` (SESSION 29, optional): the resolved item template's own
+ * name (`findHierarchyItemName`/`resolveHierarchyItemNode`) - see
+ * `findByReference`'s own doc comment. `undefined` for every caller/fixture
+ * with only one named item template keeps this byte-identical to a plain
+ * first-match search.
+ *
+ * Split into `findDirectAspectRatio` (SESSION 38, `undefined` when nothing
+ * direct is declared) plus this function's own `DEFAULT_ASPECT_RATIO`
+ * fallback, so a caller that has a SECOND, more general fallback of its own
+ * (`resolveIndexedAspectRatio` below) can tell "nothing direct declared"
+ * apart from "the diagram genuinely declares 0.667" before reaching for it.
+ */
+export declare function findDirectAspectRatio(constraints: DiagramLayoutNode['constraints'], preferredName?: string): number | undefined;
+export declare function resolveAspectRatio(constraints: DiagramLayoutNode['constraints'], preferredName?: string): number;
+/**
+ * SESSION 38: when neither `h:w` nor `w:h` is declared as a direct
+ * cross-reference (`findDirectAspectRatio` returns `undefined`), some
+ * hierarchy layouts instead declare the WRAPPING `composite` node's own
+ * `w`/`h` as two INDEPENDENT references (each relative to its own enclosing
+ * scope, never to each other) - e.g. `titled-picture-accent-list--
+ * hier5.pptx`'s own `rootComposite`: `<dgm:constr type="w" for="des"
+ * forName="rootComposite" refType="w" fact="4"/>`, `<dgm:constr type="h"
+ * for="des" forName="rootComposite" refType="h"/>` (no `fact`, i.e. `1`) -
+ * neither is a cross-type (`h`-references-`w` or vice versa) declaration, so
+ * `findDirectAspectRatio`'s own targeted search never matches either one,
+ * but the general constraint-chain walker (`resolveConstraint`) resolves
+ * BOTH independently against `rootComposite`'s own role (`w -> 4`, `h -> 1`
+ * here, both ultimately bottoming out at the implicit whole-diagram unit box
+ * `w=h=1`) and their ratio (`1/4 = 0.25`) is the composite's real declared
+ * aspect - COM-verified close to the cached drawing's own item box (SESSION
+ * 36/38, see `smartart-track-r-successor.md`).
+ *
+ * `undefined` when `algorithmNode` declares no `composite` descendant at all
+ * (e.g. the transposed "Horizontal Hierarchy" family, which never wraps one
+ * - see `smartart-hierarchy-composite-child.ts`'s own module doc comment),
+ * or that node's own `w`/`h` do not both resolve to a positive number -
+ * callers keep falling back to `DEFAULT_ASPECT_RATIO` in either case,
+ * unchanged from before this fallback existed.
+ */
+export declare function resolveIndexedAspectRatio(algorithmNode: DiagramLayoutNode | undefined, index: ConstraintIndex): number | undefined;
+//# sourceMappingURL=smartart-hierarchy-constraint-lookup.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-constraint-lookup.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-constraint-lookup.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-constraint-lookup.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAI5E,wGAAwG;AACxG,eAAO,MAAM,oBAAoB,QAAQ,CAAC;AAE1C;;;;;;;;;;;;;GAaG;AACH,wBAAgB,eAAe,CAC9B,WAAW,EAAE,iBAAiB,CAAC,aAAa,CAAC,EAC7C,IAAI,EAAE,MAAM,EACZ,aAAa,EAAE,MAAM,EACrB,aAAa,CAAC,EAAE,MAAM,GACpB,MAAM,GAAG,SAAS,CAWpB;AAED;;;;;;;;;;;;;;;;;;;GAmBG;AACH,wBAAgB,qBAAqB,CACpC,WAAW,EAAE,iBAAiB,CAAC,aAAa,CAAC,EAC7C,aAAa,CAAC,EAAE,MAAM,GACpB,MAAM,GAAG,SAAS,CAUpB;AAED,wBAAgB,kBAAkB,CACjC,WAAW,EAAE,iBAAiB,CAAC,aAAa,CAAC,EAC7C,aAAa,CAAC,EAAE,MAAM,GACpB,MAAM,CAER;AAED;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,wBAAgB,yBAAyB,CACxC,aAAa,EAAE,iBAAiB,GAAG,SAAS,EAC5C,KAAK,EAAE,eAAe,GACpB,MAAM,GAAG,SAAS,CAWpB"}

package/dist/diagram/hierarchy/smartart-hierarchy-corner-plan.d.ts

@@ -0,0 +1,49 @@
+/**
+ * SmartArt DiagramML interpreter - the declared "corner-anchored hierarchy"
+ * arrangement mode (`hierAlign="tL"/"tR"`).
+ *
+ * `hierarchy-list--hier5.pptx` declares a hierarchy whose root gets its own
+ * distinctly-sized item template (`smartart-hierarchy-generation-templates.ts`)
+ * and whose children hang in a single vertical column sharing the root's own
+ * edge (`smartart-hierarchy-hanging.ts`'s `HangingOptions.columnAlign`) -
+ * genuinely different from both the plain fanning "Hierarchy" family
+ * (`hierAlign` absent from any nested `hierRoot`) and the centred-on-children
+ * "Horizontal Hierarchy" family (`hierAlign="lCtrCh"/"rCtrCh"`, a REAL fanned
+ * tree oriented sideways, which must keep using the `std`/`tailed` fan
+ * machinery unchanged - see `smartart-hierarchy-dispatch-lindir.ts`'s own
+ * module doc comment for why the OUTERMOST `linDir` alone cannot tell these
+ * apart, and `smartart-track-r-successor.md`'s SESSION 34/36/37 sections for
+ * the full corpus derivation).
+ *
+ * `resolveCornerHangPlan` is the single gate deciding whether a hierarchy
+ * arrangement is this declared construct - narrow and structural, not a
+ * per-layout name check, so it reaches every future layoutDef sharing the
+ * SAME three properties without special-casing `hierarchy-list` by name:
+ *
+ *   1. the tree's own root item declares `hierAlign="tL"`/`"tR"` (never
+ *      `lCtrCh`/`rCtrCh`/`lT`/`rT`/... - those describe a root CENTRED on a
+ *      real fan, not a single hanging column);
+ *   2. root's own nested `hierChild` (the "children of root" generation)
+ *      declares a VERTICAL `linDir` (`fromT`/`fromB` - "this generation runs
+ *      top-to-bottom", i.e. a single column, not a horizontal fan);
+ *   3. the layout declares a genuinely distinct root-vs-descendant item size
+ *      (`resolveHierarchyGenerationTemplates`'s own `root` entry) - without
+ *      this, `arrangeFullyHangingTree`'s existing single-size hanging column
+ *      has no COM-verified fit for this exact corner-anchored shape, so
+ *      falling through to the pre-existing `std` path is the safer default
+ *      (every corpus fixture NOT hierarchy-list currently satisfies (1)+(2)
+ *      without (3): `square-accent-list`/`titled-picture-accent-list`, kept
+ *      on their existing `std` path unchanged by this gate).
+ */
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { DiagramLayoutNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+export interface CornerHangPlan {
+    /** The nested `hierChild`'s own `linDir` (`fromT`/`fromB`) - feeds `branchMode`. */
+    linDir: string;
+    /** `right`: every row shares the column's RIGHT edge (`chAlign="l"`, COM-verified); `left`: mirrored (`chAlign="r"`). */
+    side: 'left' | 'right';
+}
+/** See the module doc comment. `undefined` unless all three conditions hold. */
+export declare function resolveCornerHangPlan<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined, index: ConstraintIndex): CornerHangPlan | undefined;
+//# sourceMappingURL=smartart-hierarchy-corner-plan.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-corner-plan.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-corner-plan.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-corner-plan.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAChE,OAAO,KAAK,EAAE,iBAAiB,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACzE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAQ5E,MAAM,WAAW,cAAc;IAC9B,oFAAoF;IACpF,MAAM,EAAE,MAAM,CAAC;IACf,yHAAyH;IACzH,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC;CACvB;AAKD,gFAAgF;AAChF,wBAAgB,qBAAqB,CAAC,CAAC,EACtC,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,KAAK,EAAE,eAAe,GACpB,cAAc,GAAG,SAAS,CAwB5B"}

package/dist/diagram/hierarchy/smartart-hierarchy-dispatch-lindir.d.ts

@@ -0,0 +1,58 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy dispatch `linDir`/`hierAlign`
+ * fallback resolution.
+ *
+ * `discoverArrangement` (`smartart-layout-interpreter-model.ts`, Track L/S
+ * territory) falls back to the choose-WRAPPING node itself when a genuine
+ * org-chart-family layoutDef's `hierRoot`/`hierChild` algorithm is reached
+ * only by evaluating a `dgm:choose`, not as a direct `layoutNode` child
+ * (`hierarchy-list--hier5.pptx`/`horizontal-labeled-hierarchy--hier5.pptx`:
+ * see `smartart-track-r-successor.md` SESSION 34/36 for the full derivation).
+ * That fallback node's OWN `.algorithm` field stays `undefined` (never
+ * mutated - hierarchy code elsewhere depends on the EXACT node reference
+ * reaching `arrangeHierarchy` unchanged), so `algorithmParam(algorithmNode,
+ * 'linDir')` reads nothing for it even though the node's own `dgm:choose`
+ * carries the real value.
+ *
+ * The OUTERMOST `hierChild`'s own `linDir` is NOT a safe "whole tree hangs"
+ * signal on its own: the plain "Hierarchy"/"Circle Picture Hierarchy"/
+ * "Labeled Hierarchy" family also wraps `hierChild1`'s alg in an identical
+ * `dir=norm/rev`-mirroring `dgm:choose` declaring `linDir="fromL"/"fromR"`
+ * at EVERY generation (`hierChild1`, `hierChild2`, ...) purely to flip fan
+ * order left/right - NOT to hang anything (`hierRoot1`'s own children are
+ * just its render template, no NESTED `hierChild` inside it at all; the next
+ * generation's `hierChildN` is a SIBLING of `hierRootN`, both children of
+ * the SAME enclosing `forEach`, not nested under the root). A genuinely
+ * hanging construct (`hierarchy-list`/`horizontal-labeled-hierarchy`) instead
+ * nests its OWN "children of root" `hierChild` STRICTLY BELOW a `hierRoot`
+ * node (`hierarchy-list--hier5.pptx`'s `root(hierRoot) -> childShape
+ * (hierChild, linDir=fromT)`; `horizontal-labeled-hierarchy--hier5.pptx`'s
+ * `Name17(hierRoot) -> hierChild2(hierChild, linDir=fromT)` the identical
+ * shape, one level per generation) - so this module searches specifically
+ * for a `hierChild` found BELOW the tree's own first `hierRoot`, never the
+ * outermost wrapper's own `linDir` directly, keeping the plain fanning
+ * family's `fromL`/`fromR` mirror-only value from ever being misread as a
+ * hang signal.
+ *
+ * Resolved independently here (Track R territory only - no edit to
+ * `smartart-layout-interpreter-model.ts` needed, unlike the WeakMap approach
+ * a prior round attempted and reverted). A fixture whose relevant node
+ * already carries a real `.algorithm` (every non-choose-wrapped hierarchy
+ * fixture) resolves identically either way - `branchMode`'s existing
+ * decision is unaffected for them.
+ */
+import type { DiagramLayoutNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+/** See the module doc comment. */
+export declare function resolveHierarchyDispatchLinDir<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): string | undefined;
+/** See {@link resolveHierarchyDispatchLinDir}; the SAME nested `hierChild`'s `chAlign` param. */
+export declare function resolveHierarchyDispatchChAlign<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): string | undefined;
+/**
+ * The tree's own root item's `hierAlign` param (e.g. `tL`/`tR`), found by a
+ * depth-first search below `algorithmNode` for the first `hierRoot`-typed
+ * node (direct `.algorithm`, or its own `dgm:choose` resolved). `undefined`
+ * when nothing resolves - see the module doc comment for why a false
+ * negative here is always safe.
+ */
+export declare function resolveHierarchyRootAlign<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): string | undefined;
+//# sourceMappingURL=smartart-hierarchy-dispatch-lindir.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-dispatch-lindir.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-dispatch-lindir.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-dispatch-lindir.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA0CG;AAEH,OAAO,KAAK,EAA0B,iBAAiB,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACjG,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAiChE,kCAAkC;AAClC,wBAAgB,8BAA8B,CAAC,CAAC,EAC/C,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,MAAM,GAAG,SAAS,CAGpB;AAED,iGAAiG;AACjG,wBAAgB,+BAA+B,CAAC,CAAC,EAChD,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,MAAM,GAAG,SAAS,CAGpB;AAED;;;;;;GAMG;AACH,wBAAgB,yBAAyB,CAAC,CAAC,EAC1C,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,MAAM,GAAG,SAAS,CAGpB"}

package/dist/diagram/hierarchy/smartart-hierarchy-fan-aware-width.d.ts

@@ -0,0 +1,48 @@
+/**
+ * SmartArt DiagramML interpreter - fan-aware column-span for `tailed` mode.
+ *
+ * Split out of `smartart-hierarchy-hang-depth.ts` (the file-size budget):
+ * `buildFanAwareWidthMap`/`resolveSpanWidth`, sharing that module's own
+ * `fanContinues` predicate so the two walks (depth/hang-shape there, width
+ * here) can never silently disagree on which nodes hang.
+ *
+ * `effectiveWidth` (`smartart-hierarchy-orgchart-tree.ts`) is a plain
+ * structural leaf-count sum with NO fan/hang awareness - it was being used,
+ * unconditionally, for a hanging branch's own row-share too. But a branch
+ * that HANGS collapses its entire subtree into exactly ONE shared column
+ * (`placeHangingTree`'s own doc comment: "ALL of t's own ordinary children
+ * share ONE column"), so its correct width contribution is always 1, not
+ * its leaf count. `buildFanAwareWidthMap` computes the CORRECT span per
+ * node, threaded through `StandardOptions.resolveSpan` (`smartart-
+ * hierarchy-standard-options.ts`) into BOTH `fitItemBox`'s own
+ * `totalLeaves` (sizing) AND the actual row positioning
+ * (`placeStandardTree`/`placeFlatChildren`) - previously ALSO over-
+ * allocating a hanging child's row-share, a real positioning bug, not just
+ * a sizing one.
+ *
+ * Pure decision logic (no rendering); mirrors `placeAt`'s CURRENT rules
+ * exactly, via the shared `fanContinues` predicate.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+/**
+ * Fan-aware column-span lookup for `tailed` mode's own hang/fan decision:
+ * unlike `effectiveWidth` (`smartart-hierarchy-orgchart-tree.ts`, a
+ * structural leaf-count sum with no hang awareness), a node whose own
+ * children HANG (not fan) collapses its entire subtree into exactly ONE
+ * column - see `widthWalk`'s own doc comment. Returns a lookup keyed by
+ * `TreeNode` identity (the SAME tree instances `placeStandardTree`/
+ * `placeFlatChildren` walk), covering every node reachable from `roots`.
+ * `std` mode has no hang concept at all (`hangingPlacer` unset) and must
+ * keep using plain `effectiveWidth` directly - only a `tailed`-mode caller
+ * should build and thread this map through (see `resolveSpanWidth` and
+ * `StandardOptions.resolveSpan`, `smartart-hierarchy-standard-options.ts`).
+ */
+export declare function buildFanAwareWidthMap(roots: readonly TreeNode[], orgChart: boolean, perRow: number): Map<TreeNode, number>;
+/**
+ * Resolve `t`'s own column span, consulting `map` (when present - `tailed`
+ * mode) and falling back to plain `effectiveWidth` otherwise (`std` mode, or
+ * a node `map` never reached - should not happen for any node actually
+ * walked by `placeStandardTree`, but a safe fallback rather than a throw).
+ */
+export declare function resolveSpanWidth(map: Map<TreeNode, number> | undefined, t: TreeNode, orgChart: boolean): number;
+//# sourceMappingURL=smartart-hierarchy-fan-aware-width.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-fan-aware-width.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-fan-aware-width.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-fan-aware-width.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAwCxD;;;;;;;;;;;;GAYG;AACH,wBAAgB,qBAAqB,CACpC,KAAK,EAAE,SAAS,QAAQ,EAAE,EAC1B,QAAQ,EAAE,OAAO,EACjB,MAAM,EAAE,MAAM,GACZ,GAAG,CAAC,QAAQ,EAAE,MAAM,CAAC,CAMvB;AAED;;;;;GAKG;AACH,wBAAgB,gBAAgB,CAC/B,GAAG,EAAE,GAAG,CAAC,QAAQ,EAAE,MAAM,CAAC,GAAG,SAAS,EACtC,CAAC,EAAE,QAAQ,EACX,QAAQ,EAAE,OAAO,GACf,MAAM,CAGR"}

package/dist/diagram/hierarchy/smartart-hierarchy-fan.d.ts

@@ -0,0 +1,97 @@
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { HierContext } from './smartart-hierarchy-shared.js';
+/**
+ * SmartArt DiagramML interpreter - "chPref-reached fan" for a hanging
+ * generation (`hierBranch` `init`/`hang`/`l`/`r`, generation 2+).
+ *
+ * `placeHangingTree` (see its doc comment in `smartart-hierarchy-hanging.ts`)
+ * stacks a node's ordinary children in one narrow indented column. Genuine
+ * PowerPoint output refutes that for one specific, common shape: measured
+ * against `smartart-orgchart-nested-hang.pptx` in the corpus (both slides,
+ * Standard AND Both Hanging), when
+ *
+ *   1. the node itself is one of exactly `chPref` siblings under its OWN
+ *      parent (here: Report A/Report B/Report C, three direct reports under
+ *      the CEO, `chPref=3`), AND
+ *   2. that node's own ordinary child count also reaches `chPref` (Report
+ *      B's three children: Team 1/2/3),
+ *
+ * PowerPoint does not hang the children in a column under Report B at all: it
+ * fans Team 1/2/3 across the SAME three x-columns Report A/Report B/Report C
+ * already occupy, one generation lower (Team 1 lands under Report A's own
+ * column, Team 2 under Report B's, Team 3 under Report C's), and the two
+ * excess children beyond a `chPref`-sized cascade (Team 4/Team 5, added past
+ * `chPref` via `SmartArtNode.AddNode()`) are not part of this row at all: the
+ * `README.md` fixture note documents that PowerPoint's own layoutDef has no
+ * further "hierChild group" slot template past generation 1, so `AddNode()`
+ * itself relinks those calls as children of the 3rd fanned node (Team 1) in
+ * the raw `dgm:pt` tree; the interpreter never needs to invent an overflow
+ * placement because the data model has already done it (`Team 1 -> Team 4`,
+ * `Team 1 -> Team 5` are genuine `dgm:cxn` edges, confirmed by inspecting
+ * `data1.xml` directly), and the existing hanging-column recursion places
+ * them correctly once Team 1 itself sits in the right column.
+ *
+ * This module is the pure decision half: given a candidate node's own child
+ * count, the layout's resolved `chPref`/`chMax` row size, and the x-centers
+ * already computed for the node's OWN sibling row (when the caller is a plain
+ * fanned row - see `placeFlatChildren` in `smartart-hierarchy-standard.ts`),
+ * decide whether the fan applies and, if so, which columns to reuse.
+ *
+ * A parent generation that is NOT exactly `chPref`-wide (a manager with 2 or
+ * 4 direct reports, one of which has exactly `chPref` children of its own)
+ * measures a materially different, position-dependent shape: an edge report
+ * fanning its own children can extend the column grid outward by one step
+ * rather than reusing its farthest sibling's column, and a report whose own
+ * generation already overflowed `chPref` (a 4th sibling redirected into the
+ * tree, same "no deeper slot template" mechanism as above) does not fan its
+ * children at all. That variant was measured against a scratch, non-corpus
+ * COM fixture (not checked in: the column-extension direction is not pinned
+ * to a single rule from one sample) and is intentionally NOT modelled here;
+ * see `docs/guide/limitations.md`'s "SmartArt layout" row for the honest
+ * residual. `siblingCxs` being `undefined`, or not exactly `chPref` long,
+ * therefore always falls back to the narrow hanging column.
+ */
+/** What to do with one hanging node's ordinary children once fanning applies. */
+export interface FanPlan {
+    /** x-center for each of the first `columns.length` children, reused verbatim from the parent generation's own row. */
+    columns: number[];
+    /** Count of remaining children (if any) past `columns.length` still needing the ordinary narrow-hang treatment. Genuine PowerPoint org-chart data never populates this (see the module doc comment); kept only so a hand-authored layoutDef cannot silently lose nodes. */
+    overflow: number;
+}
+/**
+ * Decide whether a hanging node's `childCount` ordinary children should fan
+ * across its own parent generation's grid instead of forming a narrow
+ * hanging column.
+ *
+ * @param siblingCxs - x-centers of the node's OWN generation (itself and its
+ *   siblings), in left-to-right order, as already placed by
+ *   `placeFlatChildren`. `undefined` when the caller cannot supply this (the
+ *   node's generation was placed by `placeWrappedChildren`, or is the tree
+ *   root), which always disables the fan.
+ */
+export declare function planFan(childCount: number, perRow: number, siblingCxs: number[] | undefined): FanPlan | undefined;
+/** The `hangingPlacer` slot every fan-eligible options object carries. */
+export interface HangingPlacerOptions {
+    hangingPlacer?: ((hc: HierContext, subtrees: TreeNode[], anchorX: number, anchorY: number) => void) | undefined;
+}
+/**
+ * Shape of `smartart-hierarchy-standard.ts`'s own `placeAt`, injected rather
+ * than imported: `placeAt`'s options type (`StandardOptions`) is declared in
+ * that file, and this module is imported BY it, so taking a callback avoids a
+ * value-level import cycle between the two.
+ */
+export type PlaceAtFn<TOptions> = (hc: HierContext, t: TreeNode, cx: number, cy: number, xOffset: number, spanW: number, level: number, cellW: number, cellH: number, options: TOptions) => void;
+/**
+ * Fan `t`'s first `plan.columns.length` ordinary children across `t`'s OWN
+ * parent-generation columns, one generation below `t`; each fanned child
+ * recurses through `placeAtFn` itself (called WITHOUT sibling columns of its
+ * own: a fan does not cascade a second level deep without its own
+ * genuine-fixture measurement - see the module doc comment), so a fanned
+ * child's own descendants still resolve via the ordinary narrow-hang path.
+ * Any children past `plan.columns` (never populated by genuine PowerPoint
+ * org-chart data - see `planFan`'s doc comment) fall back to the ordinary
+ * hanging column, anchored under the first fanned column so nothing is
+ * silently dropped.
+ */
+export declare function placeFannedRow<TOptions extends HangingPlacerOptions>(hc: HierContext, t: TreeNode, normal: TreeNode[], plan: FanPlan, cx: number, cy: number, level: number, cellW: number, cellH: number, options: TOptions, placeAtFn: PlaceAtFn<TOptions>): void;
+//# sourceMappingURL=smartart-hierarchy-fan.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-fan.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-fan.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-fan.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAExD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;AAE/D;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AAEH,iFAAiF;AACjF,MAAM,WAAW,OAAO;IACvB,sHAAsH;IACtH,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,2QAA2Q;IAC3Q,QAAQ,EAAE,MAAM,CAAC;CACjB;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,OAAO,CACtB,UAAU,EAAE,MAAM,EAClB,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAAE,GAAG,SAAS,GAC9B,OAAO,GAAG,SAAS,CAWrB;AAED,0EAA0E;AAC1E,MAAM,WAAW,oBAAoB;IACpC,aAAa,CAAC,EACX,CAAC,CAAC,EAAE,EAAE,WAAW,EAAE,QAAQ,EAAE,QAAQ,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,KAAK,IAAI,CAAC,GACnF,SAAS,CAAC;CACb;AAED;;;;;GAKG;AACH,MAAM,MAAM,SAAS,CAAC,QAAQ,IAAI,CACjC,EAAE,EAAE,WAAW,EACf,CAAC,EAAE,QAAQ,EACX,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,OAAO,EAAE,QAAQ,KACb,IAAI,CAAC;AAEV;;;;;;;;;;;GAWG;AACH,wBAAgB,cAAc,CAAC,QAAQ,SAAS,oBAAoB,EACnE,EAAE,EAAE,WAAW,EACf,CAAC,EAAE,QAAQ,EACX,MAAM,EAAE,QAAQ,EAAE,EAClB,IAAI,EAAE,OAAO,EACb,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,OAAO,EAAE,QAAQ,EACjB,SAAS,EAAE,SAAS,CAAC,QAAQ,CAAC,GAC5B,IAAI,CAoCN"}

package/dist/diagram/hierarchy/smartart-hierarchy-fanned-hang-geometry.d.ts

@@ -0,0 +1,42 @@
+/**
+ * SmartArt DiagramML interpreter - geometry resolution for the "fanned root
+ * row, N independent per-branch hanging columns" hierarchy construct.
+ *
+ * Split out of `smartart-hierarchy-fanned-hang.ts` (the file-size budget):
+ * `resolveFannedHangGeometry` alone, so the placement/entry-point half stays
+ * under 300 LOC. See that module's own doc comment for the full derivation
+ * (COM-verified against all three `square-accent-list` samples):
+ *
+ * ```
+ * rootW = box.width / (N + (N - 1) * sibSpRatio)
+ * gap   = sibSpRatio * rootW
+ * rootH = rootW / rootAspect            // rootAspect from the root template's own unit-space w/h
+ * descH = rootH / heightFactor          // heightFactor from resolveHierarchyGenerationTemplates, reliable
+ * descW = descWidthFraction * rootW     // descWidthFraction from resolveConstraint on the descendant name
+ * ```
+ *
+ * Pure geometry/constraint reading; no framework code, no DOM.
+ */
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { DiagramLayoutNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+import type { BoundingBox } from '../layout/smartart-layout-types.js';
+export interface FannedHangGeometry {
+    rootW: number;
+    rootH: number;
+    descW: number;
+    descH: number;
+    gap: number;
+    side: 'left' | 'right';
+    /** `true` when the outer fan runs right-to-left (`linDir="fromR"`) - mirrors the root row. */
+    reversed: boolean;
+}
+/**
+ * Resolve this construct's own geometry from `algorithmNode`'s declared
+ * constraints - see the module doc comment. `undefined` when the layout
+ * declares no root/descendant template split, or the root's own aspect does
+ * not resolve to a usable box (the caller falls back to
+ * `arrangeFullyHangingTree` in either case).
+ */
+export declare function resolveFannedHangGeometry<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, index: ConstraintIndex, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined, branchCount: number, box: BoundingBox): FannedHangGeometry | undefined;
+//# sourceMappingURL=smartart-hierarchy-fanned-hang-geometry.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-fanned-hang-geometry.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-fanned-hang-geometry.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-fanned-hang-geometry.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAChE,OAAO,KAAK,EAAE,iBAAiB,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACzE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAI5E,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,iCAAiC,CAAC;AAOnE,MAAM,WAAW,kBAAkB;IAClC,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;IACd,GAAG,EAAE,MAAM,CAAC;IACZ,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC;IACvB,8FAA8F;IAC9F,QAAQ,EAAE,OAAO,CAAC;CAClB;AASD;;;;;;GAMG;AACH,wBAAgB,yBAAyB,CAAC,CAAC,EAC1C,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,KAAK,EAAE,eAAe,EACtB,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,WAAW,EAAE,MAAM,EACnB,GAAG,EAAE,WAAW,GACd,kBAAkB,GAAG,SAAS,CA+ChC"}