ooxml-core 1.1.0 → 1.2.1

package/dist/diagram/hierarchy/smartart-hierarchy-fit-item-box.d.ts

@@ -0,0 +1,111 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy item-box sizing.
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * `fitItemBox` itself, kept alongside `HIER_TAIL_OFFSET_RATIO` (its own
+ * `maxHangDepth` WIDTH term) and `HANG_HEIGHT_RATIO` (its own `maxHangRows`
+ * HEIGHT term). Pure geometry; no framework code, no DOM.
+ */
+import type { BoundingBox } from '../layout/smartart-layout-types.js';
+/**
+ * WIDTH-axis extra reservation, active ONLY when `HierarchyHangShape
+ * .allChildrenHang` is true (every one of the root's own direct children
+ * hangs, none a leaf, none continuing to fan) - see that field's own doc
+ * comment in `smartart-hierarchy-hang-depth.ts` for the structural
+ * definition and why partial-hang shapes (2 of 3 branches, etc.) do not
+ * need it. COM-verified (SESSION 23) against `half-circle-organization-
+ * chart--hier5.pptx` (the SAME `organization-chart--hier5.pptx` tree shape,
+ * n=2, BOTH children hang 1 leaf each - the first fixture where the item's
+ * OWN aspect correction flips this axis to WIDTH-bound, exposing `widthFit`'s
+ * own residual directly instead of it staying masked by the height-bound
+ * clamp): reproduces the cached `278px` item width from `867px` box width
+ * within 0.3% (`867/(2+1*0.21+1*0.25+0.6587)=277.9`) - a MEASURED constant
+ * (matching this module's own existing `HIER_TAIL_OFFSET_RATIO`/
+ * `HANG_HEIGHT_RATIO` precedent, neither of which traces to a declared XML
+ * fact either), NOT yet verified to scale correctly for `n>=3` (no clean COM
+ * sample exists where every one of 3+ branches hangs with none a leaf) -
+ * see `smartart-track-r-successor.md` SESSION 23 for the derivation and
+ * this open question.
+ */
+export declare const ALL_CHILDREN_HANG_EXTRA_RATIO = 0.6587;
+/**
+ * Fit one item box's width/height for the `std`/`tailed` branch modes: the
+ * box width is whatever fits `columns` siblings (the diagram's total
+ * leaf-column count, `effectiveWidth` summed over every root - see its doc
+ * comment in `smartart-hierarchy-shared.ts`) side by side with a
+ * `sibSpRatio` gap between each pair, inset from the box edges by
+ * `marginXRatio`; the box height is the SMALLER of that width's natural
+ * `aspectRatio` and whatever fits `levels` stacked generations (the tree's
+ * own depth) with a `generationGapRatio` gap between each, inset by
+ * `marginYRatio`. Every ratio comes from `resolveHierarchyOrientation`
+ * (`smartart-hierarchy-orientation.ts`), which reads them from the layout's
+ * own declared constraints where possible (`marginXRatio`/`marginYRatio` are
+ * the one exception - see `OUTER_MARGIN_X_RATIO`'s doc comment for why they
+ * are 0 for a transposed hierarchy and a fixed measured constant otherwise)
+ * - matching every genuine sample measured: a shallow, narrow tree
+ * ("hierarchy--hier8.pptx") renders at its natural aspect (width-bound), a
+ * tall tailed hang ("hierarchy--hier5.pptx") renders visibly SQUASHED below
+ * that aspect (height-bound), and a 1-generation fan
+ * ("hierarchy--flat3.pptx") falls between the two. Callers pass a `box` and
+ * `columns`/`levels` already in the correct (possibly transposed)
+ * orientation; this function itself has no orientation logic.
+ *
+ * `maxHangDepth` (default `0`, every existing `std`-mode caller unaffected):
+ * the deepest hanging-tail chain past `levels`' own fanned generations (see
+ * `smartart-hierarchy-hang-depth.ts`'s `computeHangShape`) - a `tailed`
+ * hierarchy's hanging portion consumes EXTRA room on the WIDTH axis a plain
+ * `columns` count never captures (`HIER_TAIL_OFFSET_RATIO`'s own per-hop
+ * horizontal indent, the SAME constant `placeAt` uses to POSITION the
+ * hanging tail, reused here so the item is SIZED consistently with where it
+ * will actually be placed). COM-verified against `organization-chart--
+ * flat3.pptx` (`maxHangDepth=0`, unaffected) / `--hier5.pptx`/`--hier8.pptx`
+ * (`maxHangDepth=1`, `levels` itself already larger via `computeHangShape`'s
+ * own fan-boundary detection): reproduces the cached item box within ~1% on
+ * both axes for all three, without needing a margin (`marginXRatio`/
+ * `marginYRatio` are `0` for `tailed` mode - see `resolveHierarchyOrientation`'s
+ * own doc comment).
+ *
+ * `maxHangRows` (default `maxHangDepth`, so a caller that only ever measured
+ * `maxHangDepth` - a pure hanging chain, at most 1 ordinary child per hung
+ * node - is unaffected): the SEPARATE HEIGHT-axis term, the tallest hanging
+ * branch's own row count (`HierarchyHangShape.maxHangRows`'s doc comment in
+ * `smartart-hierarchy-hang-depth.ts` has the full derivation and the COM
+ * sweep that found it diverges from `maxHangDepth` whenever a hung node has
+ * more than one ordinary child - `placeHangingTree` stacks every one of
+ * THOSE in the SAME shared column, one row each, not one row per hop).
+ *
+ * `hangHeightRatio` (default `HANG_HEIGHT_RATIO`, every existing caller
+ * unaffected): the per-hang-row HEIGHT-axis gap constant `maxHangRows`
+ * multiplies. SESSION 25 (`smartart-track-r-successor.md`): a `tailed`
+ * hierarchy whose hang ALSO grows along the fan-becomes-generation
+ * transposed axis (`orientation.transposed`, e.g. "Horizontal Organization
+ * Chart" - see `resolveHierarchyOrientation`'s own `tailedTransposed`
+ * signal) needs `orientation.generationGapRatio` here instead of the fixed
+ * `0.55`: COM-verified against `horizontal-organization-chart--hier5.pptx`
+ * (`n=2`, both children hang 1 leaf each - the SAME tree shape as plain
+ * `organization-chart--hier5.pptx`, which stays correct with the DEFAULT
+ * `HANG_HEIGHT_RATIO`, confirming this is a transposed-only correction, not
+ * a universal one): the un-substituted denominator (`2+1+0.2+1*0.55=3.75`)
+ * under-sizes the item box by the SAME ~10% on BOTH axes (`boxW`/`boxH`
+ * share one aspect ratio here); substituting `generationGapRatio=0.2` gives
+ * `2+1+0.2+1*0.2=3.4`, matching the cached item box within 0.4%.
+ *
+ * `hangingColumns` (default `columns`, so every existing caller that never
+ * measured it stays byte-identical): out of `columns` total leaf columns, how
+ * many actually pass through a hang (`HierarchyHangShape.hangingColumns`'s
+ * own doc comment in `smartart-hierarchy-hang-depth.ts` has the full
+ * derivation). SESSION 34: `maxHangDepth * HIER_TAIL_OFFSET_RATIO` reserves
+ * width as if EVERY column needed the hang indent, calibrated against
+ * `organization-chart--hier5.pptx` where that is true (`n=2`, both hang) -
+ * `organization-chart--hier8.pptx` (`n=5`, only 1 column hangs) showed
+ * applying the full reservation to all 5 columns' shared item size
+ * over-shrinks every item by ~4%. Scaling by `hangingColumns / n` fixes it
+ * (`hier8.pptx`: 867/(5+4*0.21+1*0.25*(1/5))=147.2 vs cached 148) while
+ * leaving every `hangingColumns === columns` caller (every fixture measured
+ * before SESSION 34) at fraction `1`, unchanged.
+ */
+export declare function fitItemBox(box: BoundingBox, columns: number, levels: number, sibSpRatio: number, aspectRatio: number, generationGapRatio: number, marginXRatio: number, marginYRatio: number, maxHangDepth?: number, clampToNaturalAspect?: boolean, maxHangRows?: number, allChildrenHang?: boolean, hangHeightRatio?: number, compositeChainHeightRatio?: number, hangingColumns?: number): {
+    boxW: number;
+    boxH: number;
+};
+//# sourceMappingURL=smartart-hierarchy-fit-item-box.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-fit-item-box.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-fit-item-box.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-fit-item-box.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAGH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,iCAAiC,CAAC;AAEnE;;;;;;;;;;;;;;;;;;;GAmBG;AACH,eAAO,MAAM,6BAA6B,SAAS,CAAC;AAEpD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2EG;AACH,wBAAgB,UAAU,CACzB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EACf,MAAM,EAAE,MAAM,EACd,UAAU,EAAE,MAAM,EAClB,WAAW,EAAE,MAAM,EACnB,kBAAkB,EAAE,MAAM,EAC1B,YAAY,EAAE,MAAM,EACpB,YAAY,EAAE,MAAM,EACpB,YAAY,SAAI,EAChB,oBAAoB,UAAO,EAC3B,WAAW,SAAe,EAC1B,eAAe,UAAQ,EACvB,eAAe,SAAoB,EACnC,yBAAyB,CAAC,EAAE,MAAM,EAClC,cAAc,SAAU,GACtB;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,CAgFhC"}

package/dist/diagram/hierarchy/smartart-hierarchy-fold-depth.d.ts

@@ -0,0 +1,44 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy per-generation "fold depth"
+ * detection.
+ *
+ * `arrangeHierarchy`'s `std`/`tailed` branches (`smartart-hierarchy-
+ * standard.ts`) recurse the ACTUAL data tree to its full depth by default,
+ * giving every descendant its own box - correct for the common "Hierarchy"/
+ * "Organization Chart" family, whose item template repeats a fresh
+ * `hierRoot`/`hierChild` pair at every generation. Some built-in layoutDefs
+ * (`hierarchy-list` - uniqueId `hierarchy3`, `Vertical Circle List`) instead
+ * declare only ONE generation's worth of per-item layoutNode (e.g.
+ * `childText`), whose own `dgm:presOf` is a COMPOUND axis ending in an
+ * UNBOUNDED `des`/`desOrSelf` hop (`axis="self desOrSelf" ... cnt="1 0"`,
+ * ECMA-376 21.4.7.5's "this point, plus every one of its own descendants,
+ * with no depth limit") - a genuine declarative signal that this generation
+ * is the LAST one the layout renders its own box for: any deeper descendant
+ * folds into that SAME box's text instead of getting a box of its own,
+ * matching PowerPoint's own cached drawing (`hierarchy-list--hier5.pptx`:
+ * cached 4 text-bearing shapes - root + 3 direct children - the interpreter
+ * previously gave a 5th, separate box to a GRANDCHILD one of those three
+ * children happened to have).
+ *
+ * This is a STRUCTURAL property of the layout definition (found once, up
+ * front), not a per-node runtime decision: `smartart-hierarchy-standard.ts`'s
+ * `placeAt` consults the resulting boolean to stop recursing past the first
+ * generation, and the pre-existing `collectFoldedDescendants`/`renderedIds`
+ * mechanism in `smartart-interpreter-drawing-bridge.ts` (already used by
+ * `lin`/`snake` for the SAME "a descendant added a level deeper via the text
+ * pane's Tab/Add Bullet" shape) automatically folds any node this arranger
+ * never gave a box to into its nearest rendered ancestor's text - no new
+ * text-joining logic needed here, only "stop creating boxes past this
+ * depth".
+ *
+ * Pure decision logic; no framework code, no DOM.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+/**
+ * Depth-first search of `node`'s whole subtree (mirroring
+ * `findHierarchyItemShape`'s traversal) for a per-item layoutNode whose own
+ * `presentationOf` ends in an unbounded `des`/`desOrSelf` hop - see the
+ * module doc comment.
+ */
+export declare function hierarchyLeafFoldsDescendants(node: DiagramLayoutNode | undefined): boolean;
+//# sourceMappingURL=smartart-hierarchy-fold-depth.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-fold-depth.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-fold-depth.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-fold-depth.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAmBlD;;;;;GAKG;AACH,wBAAgB,6BAA6B,CAAC,IAAI,EAAE,iBAAiB,GAAG,SAAS,GAAG,OAAO,CAQ1F"}

package/dist/diagram/hierarchy/smartart-hierarchy-generation-gap.d.ts

@@ -0,0 +1,60 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy generation-axis gap ratio.
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * `resolveGenerationGapRatio` itself, alongside its own fallback constant.
+ *
+ * Pure geometry/constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+import type { CompositeChildGeometry } from './smartart-hierarchy-composite-child.js';
+/**
+ * Generation-to-generation gap, as a fraction of the item's STACKING-axis
+ * size (`h` vertical, `w` transposed - see `smartart-hierarchy-
+ * orientation.ts`'s own module doc comment); falls back to
+ * `DEFAULT_GENERATION_GAP_RATIO` when undeclared.
+ *
+ * `sp` is not always declared relative to the stacking axis: "Hierarchy"
+ * itself declares it relative to `h` (the stacking axis), but "Organization
+ * Chart" declares it relative to `w` (`sp for=des forName=hierRoot1
+ * refType=w refFor=des refForName=rootComposite1 fact=0.21`) - a CROSS-axis
+ * reference. COM-verified against `organization-chart--flat3.pptx`: the raw
+ * `0.21` fed directly into the stacking-axis formula (the old bug: this
+ * function only ever checked `stackingAxis`, silently missing org-chart's
+ * own declaration and quietly falling back to the "Hierarchy" default of
+ * `0.25`) reproduces the WRONG generation pitch; converting via
+ * `aspectRatio` (the item's own `h:w`, already resolved by the caller) -
+ * `gap_stacking = declaredFact / aspectRatio` when declared on the cross
+ * axis, since a quantity expressed as a fraction of `w` needs multiplying by
+ * `w/h = 1/aspectRatio` to become a fraction of `h` - reproduces the cached
+ * generation pitch to within rounding on all three "Organization Chart"
+ * datasets (`flat3`/`hier5`/`hier8`).
+ *
+ * A SEPARATE correction applies when the layout declares a `composite`
+ * wrapper (`compositeChild` defined - see `smartart-hierarchy-composite-
+ * child.ts`): "Hierarchy"'s own `sp` (declared ON the stacking axis, `h`,
+ * `fact="0.25"`) references `composite`'s own `h`, not the RENDERED item's
+ * `h` - the SAME composite-vs-rendered-item mismatch `resolveAspectRatio`'s
+ * caller already corrects for the aspect ratio itself (`smartart-hierarchy-
+ * composite-child.ts`'s own module doc comment). Reading it unconverted (the
+ * pre-existing "same axis, no conversion needed" assumption) silently
+ * assumes `composite.h === renderedItem.h`, which is false whenever
+ * `compositeChild.widthFactor !== 1` (`composite` is WIDER than the
+ * rendered item, per its own `w` shrink). Converting: `composite.h =
+ * compositeAspect * composite.w = compositeAspect * (renderedItem.w /
+ * widthFactor)`, and `renderedItem.h = renderedAspect * renderedItem.w`, so
+ * `declaredFact * composite.h / renderedItem.h = declaredFact *
+ * compositeAspect / (widthFactor * renderedAspect^2)`. COM-verified against
+ * THREE independent depths of `hierarchy--{flat3,hier5,hier8}.pptx` (2/3/4
+ * generations): the row-to-row gap, measured directly from each fixture's
+ * own raw `dsp:sp` offsets (NOT the "solve to fill the box" quantity
+ * `computeAxisPitch` used to derive, which only coincidentally matches this
+ * for a fully-fanned tree - see that function's own doc comment), is
+ * `0.4580 * renderedItem.h` on ALL THREE samples exactly; this formula
+ * (`0.25 * 0.667 / (0.9 * 0.635^2)`) gives `0.4596` - within 0.35% of every
+ * sample, i.e. within the same rounding band every other ratio in this
+ * derivation chain shows, not a separate discrepancy.
+ */
+export declare function resolveGenerationGapRatio(constraints: DiagramLayoutNode['constraints'], stackingAxis: 'w' | 'h', aspectRatio: number, compositeChild?: CompositeChildGeometry, compositeAspect?: number, index?: ConstraintIndex, itemShapeName?: string): number;
+//# sourceMappingURL=smartart-hierarchy-generation-gap.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-generation-gap.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-generation-gap.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-generation-gap.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAC5E,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,sCAAsC,CAAC;AAyDnF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8CG;AACH,wBAAgB,yBAAyB,CACxC,WAAW,EAAE,iBAAiB,CAAC,aAAa,CAAC,EAC7C,YAAY,EAAE,GAAG,GAAG,GAAG,EACvB,WAAW,EAAE,MAAM,EACnB,cAAc,CAAC,EAAE,sBAAsB,EACvC,eAAe,CAAC,EAAE,MAAM,EACxB,KAAK,CAAC,EAAE,eAAe,EACvB,aAAa,CAAC,EAAE,MAAM,GACpB,MAAM,CAkDR"}

package/dist/diagram/hierarchy/smartart-hierarchy-generation-templates.d.ts

@@ -0,0 +1,106 @@
+/**
+ * SmartArt DiagramML interpreter - per-GENERATION hierarchy item TEMPLATE
+ * resolution (a distinctly-sized root vs every deeper generation).
+ *
+ * `resolveHierarchyItemNode` (`smartart-hierarchy-item-template.ts`, SESSION
+ * 29) already picks ONE template - the "majority" one every generation but a
+ * one-off root uses - for `fitItemBox`'s single uniform box. Two corpus
+ * fixtures declare a genuinely DIFFERENT box size for the root itself
+ * (`hierarchy-list--hier5.pptx`'s `rootText`/`rootComposite` vs `childText`;
+ * `horizontal-multi-level-hierarchy--hier5.pptx`'s `LevelOneTextNode` vs
+ * `LevelTwoTextNode`, the SAME pair `resolveHierarchyItemNode` already
+ * distinguishes as "first-found" vs "majority"). This module extends that
+ * single pick into a small root/descendant TABLE, with the root's own real
+ * size as a multiple of the descendant's, so a caller that CAN afford a
+ * differently-sized root box (`smartart-hierarchy-hanging-box.ts`) has the
+ * real declared numbers instead of forcing every row to the same size.
+ *
+ * ## Choose-wrapped `tx` candidates
+ *
+ * A candidate's own `dgm:alg type="tx"` is sometimes declared entirely
+ * inside a `dgm:choose` (mirroring `dir="norm"/"rev"` text alignment, e.g.
+ * `square-accent-list`'s own `Parent`/`Child` nodes) rather than as a direct
+ * child - `node.algorithm` stays `undefined` for those, so a plain
+ * `node.algorithm?.type === 'tx'` read (as `collectTxShapeNodes` in
+ * `smartart-hierarchy-item-template.ts` still does) silently finds ZERO
+ * candidates for them, and this module's own root/descendant split never
+ * fires. `collectScoped` resolves a choose-wrapped candidate's type via
+ * `chooseAlgorithmOfType` (a `tx`-only search, deliberately separate from
+ * `chooseAlgType`/`chooseAlgorithm`'s own structural whitelist - see that
+ * function's own doc comment for why arrangement DISPATCH must not be
+ * widened the same way) before falling back to `undefined`.
+ *
+ * ## Structural signal
+ *
+ * A candidate template is "root scope" when it is reached from
+ * `algorithmNode` WITHOUT crossing a NESTED `hierChild`-typed layoutNode
+ * (the recursive "every deeper generation" construct); "descendant scope"
+ * once such a boundary is crossed. `algorithmNode` itself (typically also
+ * `hierChild`-typed - the arranger's own top-level algorithm) does not count
+ * as a crossing; only a `hierChild` found STRICTLY BELOW it does -
+ * `horizontal-multi-level-hierarchy--hier5.pptx`'s own `level2hierChild`
+ * node is exactly this boundary; `hierarchy-list--hier5.pptx`'s own
+ * `childShape` node is the same shape (a DIRECT, non-`dgm:choose`-wrapped
+ * `dgm:alg type="hierChild"`, so `.algorithm.type` is readable without
+ * choose resolution).
+ *
+ * A genuine root/descendant split needs EXACTLY one candidate in each scope.
+ * `name-and-title-organization-chart--hier5.pptx`'s own second candidate
+ * (`titleText1`, a title role sharing `rootText1`'s OWN composite, cross-
+ * referencing it only via `primFontSz` - see `resolveHierarchyItemNode`'s
+ * own doc comment) sits in the SAME root scope as `rootText1` (neither
+ * candidate ever crosses a nested `hierChild`), so this module correctly
+ * finds no descendant-scope candidate there and returns no `root` entry -
+ * unlike a plain "first vs not-first" heuristic, which would misclassify
+ * `titleText1` as a distinct root template.
+ *
+ * ## Sizing
+ *
+ * `root.widthFactor`/`heightFactor`: the root candidate's own resolved
+ * `w`/`h`, as a multiple of the descendant candidate's, both resolved via
+ * `ConstraintIndex.resolveConstraint` (the SAME reference-chain walk every
+ * other declared-ratio read in this arranger uses) in the layout's own
+ * diagram-relative unit space - COM-verified against `hierarchy-list--
+ * hier5.pptx`'s own cached drawing: `rootText`/`rootComposite` resolve to
+ * `w=1, h=0.5` and `childText` to `w=0.8, h=0.5` in that unit space (the
+ * `diagram` node's own `w`/`h` default to `1`, the implicit whole-diagram
+ * unit - see `smartart-constraint-solver.ts`'s own module doc comment), so
+ * `widthFactor = 1/0.8 = 1.25`, `heightFactor = 0.5/0.5 = 1`. Multiplying a
+ * separately-fit descendant pixel size (`childText` cached `179x112`) by
+ * those factors gives `223.75x112` against the cached root box `224x112` -
+ * within a pixel of rounding, from nothing but the layout's own declared
+ * constraints.
+ *
+ * `undefined` (no `root` entry) whenever either resolved size is missing,
+ * non-positive, or the two are within 1% of each other on both axes (not a
+ * genuine size distinction - keeps callers on the existing single-box path
+ * for every ordinary layout unchanged).
+ *
+ * Pure geometry/constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+export interface HierarchyGenerationTemplate {
+    node: DiagramLayoutNode;
+    name: string;
+}
+export interface HierarchyRootTemplate extends HierarchyGenerationTemplate {
+    /** Root's own `w`/`h`, each as a multiple of `descendant`'s (same unit space). */
+    widthFactor: number;
+    heightFactor: number;
+}
+export interface HierarchyGenerationTemplates {
+    /** The template every generation but a distinctly-sized root uses (SESSION 29's existing majority pick, or the sole candidate). */
+    descendant: HierarchyGenerationTemplate;
+    /** The root's own distinct template, only when genuinely different-sized - see the module doc comment. */
+    root?: HierarchyRootTemplate;
+}
+/**
+ * Resolve the root-vs-descendant item template table for `algorithmNode` -
+ * see the module doc comment for the structural signal and sizing model.
+ * `undefined` only when `algorithmNode` declares no `tx`+shape descendant at
+ * all (mirrors `resolveHierarchyItemNode`'s own `undefined` contract).
+ */
+export declare function resolveHierarchyGenerationTemplates<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, index: ConstraintIndex, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): HierarchyGenerationTemplates | undefined;
+//# sourceMappingURL=smartart-hierarchy-generation-templates.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-generation-templates.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-generation-templates.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-generation-templates.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+EG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACzE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAG5E,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAMhE,MAAM,WAAW,2BAA2B;IAC3C,IAAI,EAAE,iBAAiB,CAAC;IACxB,IAAI,EAAE,MAAM,CAAC;CACb;AAED,MAAM,WAAW,qBAAsB,SAAQ,2BAA2B;IACzE,kFAAkF;IAClF,WAAW,EAAE,MAAM,CAAC;IACpB,YAAY,EAAE,MAAM,CAAC;CACrB;AAED,MAAM,WAAW,4BAA4B;IAC5C,mIAAmI;IACnI,UAAU,EAAE,2BAA2B,CAAC;IACxC,0GAA0G;IAC1G,IAAI,CAAC,EAAE,qBAAqB,CAAC;CAC7B;AAkDD;;;;;GAKG;AACH,wBAAgB,mCAAmC,CAAC,CAAC,EACpD,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,GAC/C,4BAA4B,GAAG,SAAS,CA8C1C"}

package/dist/diagram/hierarchy/smartart-hierarchy-hang-depth.d.ts

@@ -0,0 +1,133 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy generation-count shape, for
+ * `fitItemBox`'s own item-size solve.
+ *
+ * `fitItemBox` (`smartart-hierarchy-orientation.ts`) used the data tree's own
+ * FULL `treeDepth` as the generation-axis "row count" for every branch mode,
+ * which is correct for `std` (every generation genuinely fans, one row each)
+ * but WRONG for `tailed` (only the root's own children fan; everything
+ * deeper hangs in an indented column via `placeHangingForest`, a completely
+ * different vertical-consumption model - `HangingOptions.vGap`, not
+ * `fitItemBox`'s own `generationGapRatio`). COM-verified regression:
+ * `organization-chart--hier5.pptx`/`--hier8.pptx`/`--flat3.pptx` all measure
+ * a SMALLER real item box than `treeDepth`-based packing predicts, and the
+ * error does NOT scale uniformly with `treeDepth` alone (see this module's
+ * own derivation notes in `smartart-layout-interpreter-hierarchy.ts`'s
+ * `arrangeHierarchy` doc comment).
+ *
+ * `computeHangShape` walks the SAME fan/hang decision `smartart-hierarchy-
+ * standard.ts`'s `placeAt`/`smartart-hierarchy-fan.ts`'s `planFan` actually
+ * make (mirrored here as a pure "dry run", not a shared code path, to avoid
+ * a value-level import cycle with the render-context-bound `placeAt`) and
+ * returns:
+ *
+ *   - `fannedGenerations`: how many generations genuinely fan (root's own
+ *     children ALWAYS count as 2 minimum when the tree has any children at
+ *     all; a "solo chain link" - a node with no real siblings of its own
+ *     whose own child count matches its pre-allocated span - continues
+ *     fanning one generation deeper, exactly `placeAt`'s own rule, so this
+ *     can be 3+ for a fixture like `organization-chart--hier8.pptx`).
+ *   - `maxHangDepth`: the deepest hanging chain (in hops) ANYWHERE in the
+ *     tree, past whichever generation stops fanning - used ONLY for the
+ *     WIDTH axis (`HIER_TAIL_OFFSET_RATIO`'s own per-hop horizontal indent):
+ *     a hanging column only indents FURTHER when it nests deeper, never when
+ *     it merely gets wider at the SAME depth.
+ *   - `maxHangRows`: the tallest hanging branch's own ROW count, for the
+ *     HEIGHT axis - see `countDescendants`'s own doc comment for why this is
+ *     a DIFFERENT number from `maxHangDepth` (hop count) whenever a hanging
+ *     node has more than one ordinary child: `placeHangingTree` stacks EVERY
+ *     one of a hung node's own children in the SAME shared column, one row
+ *     each (see that module's own doc comment), so a hanging node with 3
+ *     sibling leaves consumes 3 rows of height at hang-DEPTH 1, not 1.
+ *     `maxHangDepth` and `maxHangRows` COINCIDE for a pure chain (each
+ *     hanging node has at most 1 ordinary child) - every fixture this module
+ *     was originally derived against (SESSION 8-10) happened to be a pure
+ *     chain, which is why the two were never distinguished until a COM
+ *     sweep (SESSION 22, `smartart-track-r-successor.md`) built trees with a
+ *     hanging node that has 2+ ordinary children and found the two numbers
+ *     genuinely diverge: `organization-chart`-style samples with a single
+ *     hanging branch of 2/3 sibling leaves measured a cached item width
+ *     that `maxHangDepth`-based height reservation could not reproduce
+ *     (+16.3%/-6.9% off with `maxHangDepth=1` either way, vs `maxHangDepth`-
+ *     only chain samples all landing within -7% of cached), while a SECOND,
+ *     INDEPENDENT sample with two hanging branches of 3 and 1 leaves each
+ *     measured the EXACT SAME cached width as the single 3-leaf-branch
+ *     sample - confirming the height driver is `max` over branches of each
+ *     branch's OWN row count, not `maxHangDepth`'s hop count.
+ *
+ * Pure decision logic (no rendering); mirrors `placeAt`'s CURRENT rules
+ * exactly - a future change to that fan/hang decision must update this
+ * module too, or the two will silently disagree on how big to size the item.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+/** Generation-count shape used by `fitItemBox`'s generation-axis solve. */
+export interface HierarchyHangShape {
+    /** Count of genuinely fanned generations (>= 2 whenever the tree has any children; 1 for a single lone root). */
+    fannedGenerations: number;
+    /** Deepest hanging chain (in hops past the fan boundary), 0 when nothing hangs - WIDTH axis only, see the module doc comment. */
+    maxHangDepth: number;
+    /** Tallest hanging branch's own row count, 0 when nothing hangs - HEIGHT axis only, see the module doc comment. */
+    maxHangRows: number;
+    /**
+     * True when EVERY one of the root's own direct children hangs (has its
+     * own ordinary descendants AND does not continue fanning) - a plain leaf
+     * child (no descendants at all) or a fan-continuing child (e.g. a solo
+     * chain link) both make this `false`. SESSION 23 COM finding: the WIDTH
+     * axis needs an ADDITIONAL reservation, past `maxHangDepth`'s own
+     * per-hop indent, specifically in this all-hang case - measured directly
+     * against `half-circle-organization-chart--hier5.pptx` (the SAME
+     * underlying `organization-chart--hier5.pptx` data shape, n=2, BOTH
+     * children hang exactly 1 leaf each - the first fixture where this axis
+     * is actually WIDTH-bound, exposing `widthFit`'s own residual for the
+     * first time; every other measured hang shape, including partial hangs
+     * with 2 of 3 or 2 of 4 branches hanging, needed NO such extra - see
+     * `ALL_CHILDREN_HANG_EXTRA_RATIO`'s own doc comment in `smartart-
+     * hierarchy-fit-item-box.ts`). NOT yet verified for `n>=3` (no clean COM
+     * sample exists where every one of 3+ branches hangs with none a leaf) -
+     * flagging this for a successor rather than silently extrapolating.
+     */
+    allChildrenHang: boolean;
+    /**
+     * Count of leaf columns (out of `totalLeaves`) whose path passes through a
+     * hang - one per `walk` call that returns via the HANG branch, summed (not
+     * maxed) across the forest. SESSION 34 (`organization-chart--hier8.pptx`,
+     * 8/8 matched but a uniform ~4% item under-size): `fitItemBox`'s WIDTH-axis
+     * `maxHangDepth * HIER_TAIL_OFFSET_RATIO` reservation was calibrated
+     * against `organization-chart--hier5.pptx` (`n=2`, BOTH columns hang - see
+     * `allChildrenHang`) and applied unscoped to every `tailed` fixture;
+     * `hier8.pptx` has `n=5` columns but only ONE passes through a hang, so the
+     * SAME absolute reservation over-shrinks all 5 items, not just that one.
+     * `fitItemBox` scales the reservation by `hangingColumns / columns`:
+     * `hier5.pptx` (`hangingColumns === columns === 2`) is unchanged (fraction
+     * `1`); `hier8.pptx` (`1/5`) lands within 0.6% of cached.
+     */
+    hangingColumns: number;
+}
+/**
+ * `t`'s own fan/hang outcome, mirroring `placeAt`'s `level >= 1` branch:
+ * `chPrefFanEligible` (a finite `chPref`/`chMax` row `t` itself fills) OR
+ * `t` being a "solo chain link" (no real siblings of its own) whose
+ * pre-allocated span exactly matches its own child count. Shared by `walk`
+ * (below, depth/hang-shape) and `buildFanAwareWidthMap` (width) so the two
+ * walks can never silently disagree on which nodes hang - see this module's
+ * own doc comment on why they are two separate passes over the same tree in
+ * the first place (avoiding a value-level import cycle with `placeAt`).
+ * `siblingCount` is `undefined` when `placeAt` would call `t` with no
+ * `siblingCxs` of its own (the tree root's immediate call, OR any child
+ * reached through `placeFannedRow`'s own fan-continuation - see that
+ * function's own call site, which never threads `siblingCxs` through) -
+ * `placeAt`'s own `isSoloChainLink` treats that identically to a literal
+ * 1-long array, so both collapse to the same "eligible" case here.
+ */
+export declare function fanContinues(t: TreeNode, perRow: number, orgChart: boolean, siblingCount: number | undefined, normalCount: number): boolean;
+/**
+ * Compute the fanned-generation count and deepest hang depth for a `tailed`
+ * (or `std`) hierarchy forest - see the module doc comment. For `std` mode
+ * (every generation fans, `hangingPlacer` never engaged), pass `perRow` and
+ * treat every node as if `level >= 1`'s hang branch never applies: callers
+ * should only invoke this for `tailed` mode; `std` mode keeps using the full
+ * `treeDepth` directly (this function is a no-op improvement there, see
+ * `arrangeHierarchy`'s own call site).
+ */
+export declare function computeHangShape(roots: readonly TreeNode[], orgChart: boolean, perRow: number): HierarchyHangShape;
+//# sourceMappingURL=smartart-hierarchy-hang-depth.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-hang-depth.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-hang-depth.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4DG;AAGH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAGxD,2EAA2E;AAC3E,MAAM,WAAW,kBAAkB;IAClC,iHAAiH;IACjH,iBAAiB,EAAE,MAAM,CAAC;IAC1B,iIAAiI;IACjI,YAAY,EAAE,MAAM,CAAC;IACrB,mHAAmH;IACnH,WAAW,EAAE,MAAM,CAAC;IACpB;;;;;;;;;;;;;;;;;OAiBG;IACH,eAAe,EAAE,OAAO,CAAC;IACzB;;;;;;;;;;;;;OAaG;IACH,cAAc,EAAE,MAAM,CAAC;CACvB;AAkBD;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,YAAY,CAC3B,CAAC,EAAE,QAAQ,EACX,MAAM,EAAE,MAAM,EACd,QAAQ,EAAE,OAAO,EACjB,YAAY,EAAE,MAAM,GAAG,SAAS,EAChC,WAAW,EAAE,MAAM,GACjB,OAAO,CAMT;AAoHD;;;;;;;;GAQG;AACH,wBAAgB,gBAAgB,CAC/B,KAAK,EAAE,SAAS,QAAQ,EAAE,EAC1B,QAAQ,EAAE,OAAO,EACjB,MAAM,EAAE,MAAM,GACZ,kBAAkB,CAepB"}

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

@@ -0,0 +1,28 @@
+/**
+ * SmartArt DiagramML interpreter - `mode==='hanging'` renderer dispatch.
+ *
+ * Split out of `smartart-layout-interpreter-hierarchy.ts` (the file-size
+ * budget): picks between the two renderers `mode==='hanging'` can reach.
+ *
+ * A FOREST (`roots.length > 1`, e.g. `square-accent-list`'s own top-level
+ * `hierChild` fanning one `hierRoot` instance per top-level data node) is N
+ * independent per-branch hanging columns under a fanned root row -
+ * structurally different from `arrangeFullyHangingTree`'s single-tree/
+ * single-column model (built for `hierarchy-list`'s own single-root shape) -
+ * see `smartart-hierarchy-fanned-hang.ts`'s own module doc comment. Falls
+ * back to the pre-existing single-column renderer whenever the fanned
+ * geometry itself does not resolve (e.g. no declared `sibSp`/root aspect),
+ * matching this arranger's pre-existing behaviour for every fixture that
+ * reaches `mode==='hanging'` today.
+ *
+ * Pure geometry dispatch; no framework code, no DOM.
+ */
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { DiagramLayoutNode, DiagramLayoutNodeShape, DiagramNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { CornerHangPlan } from './smartart-hierarchy-corner-plan.js';
+import type { BoundingBox, SmartArtLayoutResult } from '../layout/smartart-layout-types.js';
+export declare function dispatchHangingMode<R>(view: RawXmlView<R>, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, roots: TreeNode[], itemShape: DiagramLayoutNodeShape | undefined, connectorLabels: Map<string, string> | undefined, algorithmNode: DiagramLayoutNode<R> | undefined, index: ConstraintIndex, fontName: string | undefined, presLayoutVars: DiagramPresLayoutVars | undefined, orgChart: boolean, cornerPlan: CornerHangPlan | undefined): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-hierarchy-hang-dispatch.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-hang-dispatch.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-hang-dispatch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAChE,OAAO,KAAK,EACX,iBAAiB,EACjB,sBAAsB,EACtB,WAAW,EACX,qBAAqB,EACrB,MAAM,UAAU,CAAC;AAClB,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAC5E,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AACxD,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,kCAAkC,CAAC;AAGvE,OAAO,KAAK,EAAE,WAAW,EAAE,oBAAoB,EAAE,MAAM,iCAAiC,CAAC;AAEzF,wBAAgB,mBAAmB,CAAC,CAAC,EACpC,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,KAAK,EAAE,WAAW,EAAE,EACpB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,SAAS,EAAE,MAAM,EACjB,KAAK,EAAE,QAAQ,EAAE,EACjB,SAAS,EAAE,sBAAsB,GAAG,SAAS,EAC7C,eAAe,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,SAAS,EAChD,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,KAAK,EAAE,eAAe,EACtB,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,QAAQ,EAAE,OAAO,EACjB,UAAU,EAAE,cAAc,GAAG,SAAS,GACpC,oBAAoB,CAwCtB"}

package/dist/diagram/hierarchy/smartart-hierarchy-hanging-arrange.d.ts

@@ -0,0 +1,28 @@
+/**
+ * SmartArt DiagramML interpreter - `mode === 'hanging'` entry point.
+ *
+ * Split out of `smartart-hierarchy-hanging.ts` (the file-size budget): the
+ * box-sizing/context/result wiring around `placeHangingForest`
+ * (`smartart-hierarchy-hanging.ts`'s own row-placement recursion), for the
+ * `linDir`-only fallback branch (no `presLayoutVars.hierBranch` at all - see
+ * `smartart-layout-interpreter-hierarchy.ts`'s own module doc comment).
+ */
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { DiagramLayoutNode, DiagramLayoutNodeShape, DiagramNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { BoundingBox, SmartArtLayoutResult } from '../layout/smartart-layout-types.js';
+/**
+ * Full entry point for the `linDir`-only fallback `mode === 'hanging'`
+ * branch - the WHOLE tree hangs, one row per node, in a single column.
+ */
+export declare function arrangeFullyHangingTree<R>(view: RawXmlView<R>, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, roots: TreeNode[], itemShape: DiagramLayoutNodeShape | undefined, connectorLabels: Map<string, string> | undefined, algorithmNode: DiagramLayoutNode<R> | undefined, index: ConstraintIndex, fontName: string | undefined, linDir: string | undefined, orgChart: boolean, presLayoutVars: DiagramPresLayoutVars | undefined, 
+/**
+ * See `HangingOptions.columnAlign`'s own doc comment
+ * (`smartart-hierarchy-hanging.ts`) - `undefined` for every fixture but
+ * the declared corner-anchored construct (`arrangeHierarchy`'s own
+ * `resolveCornerHangSide`), which never engages for anything else.
+ */
+cornerSide?: 'left' | 'right'): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-hierarchy-hanging-arrange.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-hanging-arrange.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-hanging-arrange.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-hanging-arrange.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAChE,OAAO,KAAK,EACX,iBAAiB,EACjB,sBAAsB,EACtB,WAAW,EACX,qBAAqB,EACrB,MAAM,UAAU,CAAC;AAClB,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAC5E,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAQxD,OAAO,KAAK,EAAE,WAAW,EAAE,oBAAoB,EAAE,MAAM,iCAAiC,CAAC;AAIzF;;;GAGG;AACH,wBAAgB,uBAAuB,CAAC,CAAC,EACxC,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,KAAK,EAAE,WAAW,EAAE,EACpB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,SAAS,EAAE,MAAM,EACjB,KAAK,EAAE,QAAQ,EAAE,EACjB,SAAS,EAAE,sBAAsB,GAAG,SAAS,EAC7C,eAAe,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,SAAS,EAChD,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,KAAK,EAAE,eAAe,EACtB,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,MAAM,EAAE,MAAM,GAAG,SAAS,EAC1B,QAAQ,EAAE,OAAO,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS;AACjD;;;;;GAKG;AACH,UAAU,CAAC,EAAE,MAAM,GAAG,OAAO,GAC3B,oBAAoB,CA2EtB"}

package/dist/diagram/hierarchy/smartart-hierarchy-hanging-box.d.ts

@@ -0,0 +1,86 @@
+/**
+ * SmartArt DiagramML interpreter - `mode==='hanging'` box sizing, derived
+ * from the layoutDef's own declared constraints.
+ *
+ * `arrangeFullyHangingTree` (`smartart-hierarchy-hanging.ts`) used to size
+ * EVERY row with a fixed, container-relative guess (`min(w*0.42,160)` /
+ * `min(h*0.16,30)`, evidently calibrated against some other, unrecorded
+ * fixture - see `smartart-track-r-successor.md`'s SESSION 34 section).
+ * Measured against `hierarchy-list--hier5.pptx` (`867x533` box, 4 stacked
+ * rows): that guess gives `160x30`, the cached drawing's own descendant row
+ * (`childText`) is `179x112` - almost 4x too short. This module replaces the
+ * guess with a real fit-to-box solve.
+ *
+ * ## The equation
+ *
+ * `placeHangingForest`/`placeHangingTree` stack `rows` boxes in one column,
+ * `vGap` apart, so the whole column's height is `rows*itemH +
+ * (rows-1)*vGap`. The layout's own declared row gap
+ * (`resolveHangingRowGapRatio`, a `dgm:constr type="sibSp"` referencing the
+ * descendant item's own height - e.g. `hierarchy-list--hier5.pptx`'s
+ * `sibSp for="des" forName="childShape" refType="h" refFor="des"
+ * refForName="childText" fact="0.25"`) expresses `vGap` as a RATIO of the
+ * descendant row's own height, and a genuinely root-sized first row
+ * (`HierarchyGenerationTemplates.root`, see `smartart-hierarchy-generation-
+ * templates.ts`) contributes `heightFactor` row-heights instead of `1`.
+ * Substituting both into the column-height equation and solving for the
+ * descendant row's own height (the free scale variable) against the box's
+ * real pixel height:
+ *
+ * ```
+ * boxH = box.height / (rootHeightFactor + (rows - 1) * (1 + vGapRatio))
+ * ```
+ *
+ * (`rootHeightFactor` defaults to `1`, i.e. no distinct root template - the
+ * equation degrades to the plain `rows*(1+vGapRatio) - vGapRatio`
+ * denominator.) `boxW` follows from the descendant template's own declared
+ * `h:w` aspect (`resolveConstraint`-derived, not the narrower self-
+ * referential `resolveAspectRatio`: `hierarchy-list--hier5.pptx`'s own
+ * `childText` aspect is declared entirely via cross-references to
+ * `rootComposite`, which `resolveAspectRatio`'s self-reference-only search
+ * cannot read at all).
+ *
+ * COM-verified against `hierarchy-list--hier5.pptx`'s own cached drawing:
+ * `boxH = 533 / (1 + 3*1.25) = 112.21` against cached `childText.h=112`;
+ * `boxW = 112.21 / 0.625 = 179.5` against cached `childText.w=179`; the
+ * root's own box (`widthFactor=1.25, heightFactor=1` from
+ * `resolveHierarchyGenerationTemplates`) gives `224.4x112.21` against cached
+ * `rootText`/`rootComposite`'s `224x112` - all within a pixel of rounding,
+ * from nothing but the layout's own declared ratios. (Positioning - this
+ * fixture's cached drawing anchors the tree at a corner and cascades
+ * children down a FIXED x, not `placeHangingTree`'s own left-to-right column
+ * indent - remains a separate, unimplemented arrangement mode; see
+ * `smartart-track-r-successor.md`'s SESSION 34 section. This module only
+ * fixes how big each row is, not where the column sits.)
+ *
+ * Falls back to the pre-existing ad-hoc ratios whenever the layout's item
+ * template declares no resolvable `w`/`h` (every layoutDef this module
+ * cannot yet reach a declared size for) - zero behaviour change there, and
+ * for `rows < 1`.
+ *
+ * Pure geometry/constraint reading; no framework code.
+ */
+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 HangingBoxFit {
+    /** Descendant (every generation but a distinctly-templated root) row size. */
+    boxW: number;
+    boxH: number;
+    /** Root's own row size, only when the layout declares a genuinely different one - see `resolveHierarchyGenerationTemplates`. */
+    rootBoxW?: number;
+    rootBoxH?: number;
+    /** Row-to-row gap in px, for `placeHangingForest`'s own `vGap`. */
+    vGap: number;
+}
+/**
+ * Fit the hanging tree's row size to `box`, deriving every ratio from
+ * `algorithmNode`'s own declared constraints where possible. `rows` is the
+ * number of stacked item rows the caller's own placement pass will actually
+ * produce (current `placeHangingForest`/`placeHangingTree` recursion: one
+ * row per data node - folding deeper generations, as the `std`/`tailed`
+ * branches already do via `hierarchyLeafFoldsDescendants`, is not yet
+ * modelled for this mode).
+ */
+export declare function fitHangingBox<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, index: ConstraintIndex, w: number, h: number, rows: number, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): HangingBoxFit;
+//# sourceMappingURL=smartart-hierarchy-hanging-box.d.ts.map