ooxml-core 1.1.0 → 1.2.1

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-hanging-box.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-hanging-box.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6DG;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;AAa5E,MAAM,WAAW,aAAa;IAC7B,8EAA8E;IAC9E,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,gIAAgI;IAChI,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,mEAAmE;IACnE,IAAI,EAAE,MAAM,CAAC;CACb;AAqBD;;;;;;;;GAQG;AACH,wBAAgB,aAAa,CAAC,CAAC,EAC9B,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,KAAK,EAAE,eAAe,EACtB,CAAC,EAAE,MAAM,EACT,CAAC,EAAE,MAAM,EACT,IAAI,EAAE,MAAM,EACZ,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,aAAa,CAgDf"}

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

@@ -0,0 +1,36 @@
+/**
+ * SmartArt DiagramML interpreter - row count for the `mode==='hanging'`
+ * forest, honouring `foldDeeperGenerations` (see `smartart-hierarchy-fold-
+ * depth.ts`'s own module doc comment).
+ *
+ * `placeHangingTree`/`placeHangingForest` (`smartart-hierarchy-hanging.ts`)
+ * stop recursing into a node's own ordinary children once `level >= 1` when
+ * `foldDeeperGenerations` is set - the SAME "no per-generation item template
+ * past the root's direct children" signal `smartart-hierarchy-standard.ts`'s
+ * `placeAt` already consults, ported here so the `hanging` branch produces
+ * the SAME rendered row SET the `std`/`tailed` branches already do for this
+ * class of layout (`hierarchy-list--hier5.pptx`: cached 4 text-bearing
+ * shapes - root + 3 direct children - not 5, the raw data-node count).
+ *
+ * `fitHangingBox` (`smartart-hierarchy-hanging-box.ts`) needs this SAME
+ * count up front to size each row against the box (its own `rows` param),
+ * before `placeHangingForest` has run - this module is the single source
+ * both consult, so the two can never disagree on how many rows actually get
+ * placed. Mirrors `placeHangingTree`/`placeAssistants`'s own traversal
+ * exactly (one row per node placed there, none for a folded descendant): a
+ * node placed at `level >= 1` under a fold never recurses into ITS OWN
+ * ordinary children (matching `placeHangingTree`'s post-assistants fold
+ * check), but assistants themselves are always counted (`placeAssistants`
+ * places every assistant regardless of fold, and never recurses into an
+ * assistant's own children either way - see that function's own doc
+ * comment).
+ *
+ * Pure counting; no framework code, no DOM.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+/**
+ * Total rendered row count across the whole forest - see the module doc
+ * comment. Matches `placeHangingForest`'s own row-per-node output exactly.
+ */
+export declare function countHangingRows(roots: TreeNode[], orgChart: boolean, fold: boolean): number;
+//# sourceMappingURL=smartart-hierarchy-hanging-fold.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-hanging-fold.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-hanging-fold.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAkBxD;;;GAGG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,QAAQ,EAAE,EAAE,QAAQ,EAAE,OAAO,EAAE,IAAI,EAAE,OAAO,GAAG,MAAM,CAE5F"}

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

@@ -0,0 +1,118 @@
+/**
+ * SmartArt DiagramML interpreter - hanging hierarchy branches (`hierBranch`
+ * `hang`/`l`/`r`, and the tail of `init`).
+ *
+ * Renders the tree as an indented list (a depth-first "outline"), one row per
+ * node, rather than a fanned-out grid.
+ *
+ * `hierBranch`'s "Left"/"Right"/"Both Hanging" naming suggests the indent
+ * direction should differ (mirror for `l`, alternate per child for `hang`),
+ * but genuine PowerPoint output measured directly refutes that for the box
+ * offset itself: every sampled variant (`std`/`init`/`l`/`r`/`hang`, at both
+ * the second AND third generation - see the doc comment on
+ * `HIER_TAIL_OFFSET_RATIO` in `smartart-hierarchy-shared.ts`) hangs the SAME
+ * direction, and multiple ordinary children of one node always share ONE
+ * column rather than alternating sides. `hierBranch`'s actual visual
+ * difference between these variants lies elsewhere (their effect on the
+ * manager-level `hierAlign` centering, which this interpreter does not model)
+ * , not in this offset's direction or in per-sibling alternation. `direction`
+ * therefore only varies here for the unrelated `linDir`-only fallback (no
+ * `presLayoutVars.hierBranch` at all - see `smartart-layout-interpreter-hierarchy.ts`),
+ * which has no genuine-fixture measurement to contradict it.
+ *
+ * `orgChart` mode places an assistant (`dgm:pt/@type="asst"`) directly below
+ * its manager at the SAME x (no further indent, a short dashed stub
+ * connector), then continues the indented list with the manager's ordinary
+ * children. Pure geometry; no framework code, no DOM.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { HierContext } from './smartart-hierarchy-shared.js';
+/** Indent direction for one hanging-branch arrangement pass. */
+export type HangDirection = 'left' | 'right';
+export interface HangingOptions {
+    orgChart: boolean;
+    direction: HangDirection;
+    indent: number;
+    vGap: number;
+    /**
+     * See `smartart-hierarchy-hanging-fold.ts`'s own module doc comment: stops
+     * `placeHangingTree` recursing past a node's own direct children when set.
+     * `undefined`/`false` for every existing caller (the `tailed` family's own
+     * hanging tail via `smartart-hierarchy-tailed-placer.ts`'s
+     * `configureTailedHangingPlacer` never sets this) - behaviour-preserving
+     * there.
+     */
+    foldDeeperGenerations?: boolean | undefined;
+    /**
+     * The declared "corner-anchored" hierarchy shape (`hierAlign="tL"/"tR"`
+     * on a genuinely root-vs-descendant-templated hierarchy - see
+     * `smartart-hierarchy-dispatch-lindir.ts`'s own module doc comment and
+     * `smartart-layout-interpreter-hierarchy.ts`'s `resolveCornerHangAlign`):
+     * every row in the WHOLE forest (root and every descendant, at every
+     * level, regardless of its own width) shares ONE fixed column edge
+     * (`edgeX`), never `options.indent`'s per-generation cascading step -
+     * COM-verified against `hierarchy-list--hier5.pptx`'s own cached drawing:
+     * root (`224px` wide, the layout's own distinctly-templated root box) and
+     * every descendant row (`179px` wide) share the exact SAME right edge,
+     * the narrower descendant rows simply starting further right than the
+     * wider root. `side: 'right'` right-aligns every row to `edgeX` (this
+     * fixture's own shape); `'left'` left-aligns instead (the mirrored
+     * `hierAlign="tR"`/`chAlign="r"` branch - not yet corpus-verified, kept
+     * symmetric with the `dir="norm"`/`"rev"` mirroring every other hierarchy
+     * construct in this arranger already applies). `undefined` for every
+     * existing caller - behaviour-preserving there.
+     */
+    columnAlign?: {
+        edgeX: number;
+        side: 'left' | 'right';
+    } | undefined;
+}
+/** Running vertical write position, shared across an entire DFS pass. */
+export interface HangingCursor {
+    y: number;
+}
+/**
+ * Place `t` at `(x, cursor.y)` and recurse into its assistants (same column)
+ * then its ordinary children.
+ *
+ * ALL of `t`'s own ordinary children share ONE column at a single indented x
+ * (`options.direction`, resolved once per parent, not per child): measured
+ * against `smartart-orgchart-nested-hang.pptx` in the corpus, a node with two
+ * ordinary children hangs them in one shared column even under `hierBranch`
+ * "hang" ("Both Hanging"), the value whose name most suggests per-child
+ * alternation - see the module doc comment.
+ *
+ * `size` (optional): an explicit box size for THIS call only, used by
+ * `placeHangingForest`'s own top-level (forest-root) call when the layout
+ * declares a distinctly-sized root template (`smartart-hierarchy-generation-
+ * templates.ts` / `smartart-hierarchy-hanging-box.ts`) - `undefined` for
+ * every recursive descendant call, which keeps using `hc.boxW`/`hc.boxH` as
+ * before.
+ *
+ * `level` (default `0`, the forest root): mirrors `smartart-hierarchy-
+ * standard.ts`'s `placeAt` - once `options.foldDeeperGenerations` is set,
+ * a node reached at `level >= 1` still gets its own row, but its ordinary
+ * children do not; `smartart-interpreter-drawing-bridge.ts`'s own
+ * `collectFoldedDescendants` folds them into this node's text instead, the
+ * SAME mechanism the `std`/`tailed` branches already rely on. See
+ * `smartart-hierarchy-hanging-fold.ts` for the matching row-COUNT function
+ * `fitHangingBox`'s caller uses to size these rows before this function
+ * places them.
+ */
+export declare function placeHangingTree(hc: HierContext, t: TreeNode, x: number, options: HangingOptions, cursor: HangingCursor, size?: {
+    w: number;
+    h: number;
+}, level?: number): void;
+/**
+ * Entry point for a full `hang`/`l`/`r` branch pass over a forest, starting
+ * the running cursor at `startY` (an inset from the top of the box).
+ *
+ * `rootSize` (optional): passed through to EVERY top-level root's own
+ * `placeHangingTree` call (not to any recursive child call) - see that
+ * function's own doc comment.
+ */
+export declare function placeHangingForest(hc: HierContext, roots: TreeNode[], startX: number, startY: number, options: HangingOptions, rootSize?: {
+    w: number;
+    h: number;
+}): void;
+//# sourceMappingURL=smartart-hierarchy-hanging.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-hanging.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-hanging.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAGxD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;AAE/D,gEAAgE;AAChE,MAAM,MAAM,aAAa,GAAG,MAAM,GAAG,OAAO,CAAC;AAE7C,MAAM,WAAW,cAAc;IAC9B,QAAQ,EAAE,OAAO,CAAC;IAClB,SAAS,EAAE,aAAa,CAAC;IACzB,MAAM,EAAE,MAAM,CAAC;IACf,IAAI,EAAE,MAAM,CAAC;IACb;;;;;;;OAOG;IACH,qBAAqB,CAAC,EAAE,OAAO,GAAG,SAAS,CAAC;IAC5C;;;;;;;;;;;;;;;;;;OAkBG;IACH,WAAW,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAA;KAAE,GAAG,SAAS,CAAC;CACpE;AAED,yEAAyE;AACzE,MAAM,WAAW,aAAa;IAC7B,CAAC,EAAE,MAAM,CAAC;CACV;AAqBD;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,wBAAgB,gBAAgB,CAC/B,EAAE,EAAE,WAAW,EACf,CAAC,EAAE,QAAQ,EACX,CAAC,EAAE,MAAM,EACT,OAAO,EAAE,cAAc,EACvB,MAAM,EAAE,aAAa,EACrB,IAAI,CAAC,EAAE;IAAE,CAAC,EAAE,MAAM,CAAC;IAAC,CAAC,EAAE,MAAM,CAAA;CAAE,EAC/B,KAAK,SAAI,GACP,IAAI,CAwCN;AAED;;;;;;;GAOG;AACH,wBAAgB,kBAAkB,CACjC,EAAE,EAAE,WAAW,EACf,KAAK,EAAE,QAAQ,EAAE,EACjB,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,cAAc,EACvB,QAAQ,CAAC,EAAE;IAAE,CAAC,EAAE,MAAM,CAAC;IAAC,CAAC,EAAE,MAAM,CAAA;CAAE,GACjC,IAAI,CAKN"}

package/dist/diagram/hierarchy/smartart-hierarchy-item-template.d.ts

@@ -0,0 +1,64 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy item TEMPLATE selection when a
+ * layoutDef declares more than one per-node `tx` (text) shape template.
+ *
+ * `findHierarchyItemShape`/`findHierarchyItemName` (`smartart-hierarchy-
+ * shared.ts`) assume ONE item template for the whole tree: the first `tx`-alg
+ * descendant with its own `dgm:shape`, found depth-first. That is correct for
+ * every plain "Hierarchy"/"Organization Chart"-family layoutDef (exactly one
+ * such descendant exists), but `horizontal-multi-level-hierarchy--hier5.pptx`
+ * (`uniqueId=...HorizontalMultiLevelHierarchy`) declares TWO, cross-
+ * referencing each other's own dimension:
+ *
+ *   - `LevelOneTextNode` (the diagram's own single root item, ROTATED 90/270
+ *     degrees for a sideways "axis label" look - the rotation itself is not
+ *     resolved here, see the module's own "not attempted" note in
+ *     `smartart-track-r-successor.md`'s SESSION 29 section): `w for="des"
+ *     forName="LevelOneTextNode" refType="h" refFor="des"
+ *     refForName="LevelOneTextNode" fact="0.19"` - a plain SELF-referential
+ *     aspect, found FIRST by `findHierarchyItemNode`'s depth-first walk (it
+ *     sits directly under the root's own `hierRoot`, before the nested
+ *     `hierChild` that leads to every deeper generation).
+ *   - `LevelTwoTextNode` (every generation PAST the root - the SAME
+ *     layoutNode is reused recursively for generation 3+ via `dgm:forEach
+ *     ref="repeat"`, so it is the template for the VAST MAJORITY of rendered
+ *     nodes in any real tree): `h for="des" forName="LevelTwoTextNode"
+ *     refType="w" refFor="des" refForName="LevelOneTextNode"` (no `fact` -
+ *     LevelTwo's own height literally EQUALS LevelOne's own width) + `w
+ *     for="des" forName="LevelTwoTextNode" refType="h" refFor="des"
+ *     refForName="LevelTwoTextNode" fact="3.28"` (its own, separately
+ *     self-referential, aspect).
+ *
+ * `resolveHierarchyItemNode` generalises the selection: when TWO OR MORE
+ * `tx`-alg+shape descendants exist and one's own `h`/`w` constraint (in the
+ * arranger's top-level `hierChild` constrLst, `for="des"`) cross-references
+ * ANOTHER one's name, the CROSS-REFERENCING node (the "deeper"/majority
+ * template - `LevelTwoTextNode` here) is returned instead of the plain
+ * first-found node, since `fitItemBox`'s single uniform box needs to match
+ * the aspect the MAJORITY of generations actually use, not the one-off root.
+ * Falls back to the existing first-found behaviour whenever this pattern is
+ * absent (every other fixture in the 227-fixture gallery corpus - see the
+ * module's own colocated test for the `name-and-title-organization-chart`/
+ * `half-circle-organization-chart` negative case: their own composite
+ * declares a second `tx`+shape descendant, `titleText1`, but ITS cross-
+ * reference to `rootText1` is a `primFontSz` constraint, not `h`/`w`, and
+ * lives in the COMPOSITE's own local `constrLst`, `for="ch"` - not the
+ * `hierChild`-level, `for="des"` constraint this function reads - so the
+ * gate never fires for them).
+ *
+ * Deliberately does NOT attempt the root's own distinct box size (its
+ * `LevelOneTextNode` template still renders at the same uniform box every
+ * other node gets) - see the SESSION 29 successor notes for the remaining
+ * per-generation sizing and rotation-aware-bbox work.
+ *
+ * Pure geometry/constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+/**
+ * The item template's own layoutNode, preferring a cross-referencing
+ * "majority" template over a plain first-found one - see the module doc
+ * comment. `undefined` when `algorithmNode` declares no `tx`+shape descendant
+ * at all (unchanged from the pre-existing behaviour).
+ */
+export declare function resolveHierarchyItemNode(algorithmNode: DiagramLayoutNode | undefined): DiagramLayoutNode | undefined;
+//# sourceMappingURL=smartart-hierarchy-item-template.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-item-template.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-item-template.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAgDlD;;;;;GAKG;AACH,wBAAgB,wBAAwB,CACvC,aAAa,EAAE,iBAAiB,GAAG,SAAS,GAC1C,iBAAiB,GAAG,SAAS,CA2B/B"}

package/dist/diagram/hierarchy/smartart-hierarchy-orgchart-tree.d.ts

@@ -0,0 +1,53 @@
+/**
+ * SmartArt DiagramML interpreter - org-chart tree shaping helpers.
+ *
+ * Split out of `smartart-hierarchy-shared.ts` (the file-size budget):
+ * assistant-node detection/partitioning, effective (assistant-excluding) tree
+ * width, `chMax`/`chPref` row sizing, and the org-chart group-wrapper
+ * flattening pass. Pure geometry; no framework code, no DOM.
+ */
+import type { DiagramNode } from '../model/index.js';
+import type { TreeNode } from '../layout/smartart-tree.js';
+/** A `dgm:pt/@type="asst"` (assistant) data-model node. */
+export declare function isAssistant(node: DiagramNode): boolean;
+/** Split a tree node's children into assistants and ordinary subordinates. */
+export declare function partitionChildren(t: TreeNode, orgChart: boolean): {
+    assistants: TreeNode[];
+    normal: TreeNode[];
+};
+/**
+ * Tree width counting only ordinary (non-assistant) descendants: assistants
+ * are rendered as a side annotation near their parent, not a fan-out sibling,
+ * so they must not claim a normal sibling's share of the available width.
+ * Falls back to plain leaf-counting (matching `treeWidth`) when `orgChart` is
+ * off, so non-org-chart hierarchies are unaffected.
+ */
+export declare function effectiveWidth(t: TreeNode, orgChart: boolean): number;
+/** A resolved per-parent row size for `chMax`/`chPref` wrapping (`Infinity` = unbounded). */
+export declare function rowSize(childMax: number | undefined, childPreferred: number | undefined): number;
+/**
+ * Genuine PowerPoint org charts (`presLayoutVars.orgChart`) do NOT attach
+ * ordinary reports directly to their manager: even a manager with only 3
+ * direct reports (well within the default `chPref=3` threshold, no overflow)
+ * gets up to `chPref` synthetic, untyped, EMPTY content points as an
+ * intermediate "hierChild group" layer, with the real reports nested one
+ * level under whichever group slot got populated. Measured against
+ * `smartart-orgchart-hierbranch.pptx` in the corpus: every one of its four
+ * slides parses to 11 content points for a tree the author only typed 7 nodes
+ * into, the extra 4 being one empty assistant slot and three empty group
+ * points (only one of which has any children).
+ *
+ * Left alone, the hierarchy arranger renders those group wrappers as ordinary
+ * blank fanned-out boxes and their real children one generation too deep
+ * (landing on the hanging tail instead of the fan-out row PowerPoint itself
+ * shows). This flattens them out before the tree is built: an empty, untyped
+ * node's children are spliced into its own parent's child list in its place,
+ * and the wrapper itself is dropped (an empty, childless slot simply
+ * disappears, matching PowerPoint's own unpopulated group columns). Assistant
+ * points keep their role even when empty - only a plain untyped node with no
+ * text is a group wrapper - so a genuinely blank ordinary node is never lost:
+ * that shape does not occur in a real org chart's data model. A no-op when
+ * `orgChart` is not set, or when no such wrapper is present.
+ */
+export declare function flattenOrgChartGroupWrappers<S>(nodes: DiagramNode<S>[], orgChart: boolean): DiagramNode<S>[];
+//# sourceMappingURL=smartart-hierarchy-orgchart-tree.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-orgchart-tree.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-orgchart-tree.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-orgchart-tree.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AAC5C,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAExD,2DAA2D;AAC3D,wBAAgB,WAAW,CAAC,IAAI,EAAE,WAAW,GAAG,OAAO,CAEtD;AAED,8EAA8E;AAC9E,wBAAgB,iBAAiB,CAChC,CAAC,EAAE,QAAQ,EACX,QAAQ,EAAE,OAAO,GACf;IAAE,UAAU,EAAE,QAAQ,EAAE,CAAC;IAAC,MAAM,EAAE,QAAQ,EAAE,CAAA;CAAE,CAUhD;AAED;;;;;;GAMG;AACH,wBAAgB,cAAc,CAAC,CAAC,EAAE,QAAQ,EAAE,QAAQ,EAAE,OAAO,GAAG,MAAM,CAUrE;AAED,6FAA6F;AAC7F,wBAAgB,OAAO,CAAC,QAAQ,EAAE,MAAM,GAAG,SAAS,EAAE,cAAc,EAAE,MAAM,GAAG,SAAS,GAAG,MAAM,CAQhG;AAOD;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,4BAA4B,CAAC,CAAC,EAC7C,KAAK,EAAE,WAAW,CAAC,CAAC,CAAC,EAAE,EACvB,QAAQ,EAAE,OAAO,GACf,WAAW,CAAC,CAAC,CAAC,EAAE,CAoBlB"}

package/dist/diagram/hierarchy/smartart-hierarchy-orientation-resolve.d.ts

@@ -0,0 +1,36 @@
+/**
+ * SmartArt DiagramML interpreter - resolve `arrangeHierarchy`'s own
+ * orientation + effective (possibly axis-swapped) box, one call site.
+ *
+ * Split out of `smartart-layout-interpreter-hierarchy.ts` (the file-size
+ * budget): `orientation.transposed` ("Horizontal Hierarchy" and its
+ * siblings - see `smartart-hierarchy-orientation.ts`'s own module doc
+ * comment) AND the SEPARATE `axisSwapped` construct (`hierAlign="lCtrCh"/
+ * "rCtrCh"`, see `smartart-hierarchy-centered-fan-axis.ts`) both run the
+ * WHOLE std/tailed placement algorithm against a box with width/height
+ * swapped, then map the result back at the very end (`transposeResult`):
+ * the fan axis is always "X"/`cellW`/`boxW`'s own width and the generation
+ * axis always "Y" from `placeStandardTree`'s own point of view, whichever
+ * real screen axis that maps to. They differ only in WHICH ratios size the
+ * item: `orientation.transposed` also switches `resolveHierarchyOrientation`'s
+ * own margin/aspect formula; `axisSwapped` alone leaves that formula on the
+ * STD branch throughout, only re-deriving the axis-relative fields
+ * `adjustOrientationForAxisSwap` names (see its own doc comment).
+ *
+ * Pure geometry; 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 { HierarchyOrientation } from './smartart-hierarchy-orientation-types.js';
+import type { BoundingBox } from '../layout/smartart-layout-types.js';
+export interface HierarchyEffectiveOrientation {
+    orientation: HierarchyOrientation;
+    /** `true` when this arranger runs against `effectiveBox` and needs a final `transposeResult` pass. */
+    swapAxes: boolean;
+    /** `{width: box.height, height: box.width}` when `swapAxes`, `box` unchanged otherwise. */
+    effectiveBox: BoundingBox;
+}
+/** See the module doc comment. */
+export declare function resolveHierarchyEffectiveOrientation<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, index: ConstraintIndex, mode: 'std' | 'tailed' | 'hanging', nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined, box: BoundingBox): HierarchyEffectiveOrientation;
+//# sourceMappingURL=smartart-hierarchy-orientation-resolve.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-orientation-resolve.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-orientation-resolve.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-orientation-resolve.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;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,oBAAoB,EAAE,MAAM,wCAAwC,CAAC;AAEnF,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,iCAAiC,CAAC;AAEnE,MAAM,WAAW,6BAA6B;IAC7C,WAAW,EAAE,oBAAoB,CAAC;IAClC,sGAAsG;IACtG,QAAQ,EAAE,OAAO,CAAC;IAClB,2FAA2F;IAC3F,YAAY,EAAE,WAAW,CAAC;CAC1B;AAED,kCAAkC;AAClC,wBAAgB,oCAAoC,CAAC,CAAC,EACrD,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,KAAK,EAAE,eAAe,EACtB,IAAI,EAAE,KAAK,GAAG,QAAQ,GAAG,SAAS,EAClC,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,GAAG,EAAE,WAAW,GACd,6BAA6B,CA0B/B"}

package/dist/diagram/hierarchy/smartart-hierarchy-orientation-types.d.ts

@@ -0,0 +1,81 @@
+/**
+ * SmartArt DiagramML interpreter - the `HierarchyOrientation` descriptor.
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * the interface itself, alongside its own field-by-field doc comments.
+ * `resolveHierarchyOrientation` (that module) is the only producer; every
+ * other consumer imports the type from here or the re-export there.
+ *
+ * Pure types; no runtime code.
+ */
+export interface HierarchyOrientation {
+    /** True when the fan axis is Y (siblings stack vertically) and generations stack along X. */
+    transposed: boolean;
+    sibSpRatio: number;
+    /** `h:w` when `!transposed`; the axes are swapped inside `arrangeHierarchy` when `transposed`, so this is always the ratio to apply to the FAN-axis size to get the CROSS-axis size in "logical" (post-swap) space. */
+    aspectRatio: number;
+    /** Generation-to-generation gap the DECLARED `sp` fact, no `composite`-cell correction applied - see `smartart-hierarchy-generation-gap.ts`. Used by `fitItemBox` to SIZE the item; that solve already matched cached geometry with this raw value, see the call site's own comment. */
+    generationGapRatio: number;
+    /** The SAME gap, `composite`-cell-corrected (mirrors `compositeWidthFactor`'s own cell-vs-item split on the fan axis) - used by `computeHierarchyAxisPitches` to POSITION composite cells, the ones actually centred/pitched. Identical to `generationGapRatio` whenever no `composite` wrapper is declared (every `tailed`/`transposed` layout checked). */
+    compositeGenerationGapRatio: number;
+    /**
+     * SESSION 32: the per-hang-row gap ratio a `tailed` hierarchy's SIZING
+     * (`fitItemBox`) and POSITIONING (`smartart-hierarchy-standard.ts`'s own
+     * hang transition, `smartart-hierarchy-axis-pitch.ts`'s own `fanHeight`
+     * reservation - all three MUST move together, see their own SESSION 32 doc
+     * comments) use for the gap between the last fanned generation and the
+     * first hanging row. Normally identical to `generationGapRatio` (COM-
+     * verified: `organization-chart--hier5.pptx`'s own raw `dsp:sp` offsets
+     * show the SAME gap ratio governs both the fan->fan AND fan->hang
+     * transitions) - `undefined` only for the rare "compound, multi-role text
+     * box" shape (`smartart-hierarchy-composite-child.ts`'s own
+     * `compositeDeclaresCompoundTextRole`, e.g. `name-and-title-organization-
+     * chart`), where `generationGapRatio` is not a trustworthy stand-in
+     * (COM-verified regression otherwise), so callers fall back to the fixed
+     * `HANG_HEIGHT_RATIO` measured constant instead.
+     */
+    hangHeightRatio: number | undefined;
+    /** Outer margin (fraction of the effective box) on the FAN axis - see `OUTER_MARGIN_X_RATIO`'s doc comment: 0 when `transposed`. */
+    marginXRatio: number;
+    /** Outer margin (fraction of the effective box) on the GENERATION axis - see `OUTER_MARGIN_X_RATIO`'s doc comment: 0 when `transposed`. */
+    marginYRatio: number;
+    /**
+     * The rendered item's own width as a fraction of the WRAPPING `composite`
+     * cell's width, when the layout declares one (`smartart-hierarchy-
+     * composite-child.ts`'s own `widthFactor`) - `undefined` for a layoutDef
+     * with no such wrapper (e.g. "Horizontal Hierarchy"). The FAN axis needs
+     * to centre `composite` CELLS (not the smaller rendered item) using the
+     * layout's own unconverted `sibSpRatio` - see `smartart-layout-
+     * interpreter-hierarchy.ts`'s own fan-axis wiring.
+     */
+    compositeWidthFactor?: number | undefined;
+    /**
+     * The generation-axis mirror of `compositeWidthFactor` - the rendered
+     * item's own height as a fraction of the WRAPPING `composite` cell's own
+     * height, when the layout's own "parent-relative" shape declares one
+     * (`smartart-hierarchy-composite-child.ts`'s own `heightFactor`, SESSION
+     * 28) - `undefined` otherwise (including the self-referential composite
+     * shape, where no caller has yet needed the distinction).
+     */
+    compositeHeightFactor?: number | undefined;
+    /**
+     * SESSION 32: the rendered item's TRUE height, as a ratio of `fitItemBox`'s
+     * own `widthFit` (the WRAPPING `composite` cell's width, un-shrunk - see
+     * `fitItemBox`'s own doc comment on `compositeChainHeightRatio`), for the
+     * "parent-relative" composite-child shape only (`compositeHeightFactor`
+     * defined - e.g. `circle-picture-hierarchy`): `compositeAspect *
+     * compositeHeightFactor` (`composite.h = compositeW * compositeAspect`,
+     * `renderedItem.h = composite.h * compositeHeightFactor`). `undefined`
+     * whenever `compositeHeightFactor` is (every other layout, including the
+     * self-referential composite shape - "Hierarchy" itself), so `fitItemBox`
+     * keeps its existing `heightFit`-clamped sizing for every other caller.
+     */
+    compositeChainHeightRatio?: number | undefined;
+    /**
+     * The rendered item's own constant "3D card" offset from its `composite`
+     * cell's own leading edge, as a fraction of the `composite` cell's width
+     * - 0 when no `composite` wrapper is declared (nothing to offset from).
+     */
+    cardOffsetXRatio: number;
+}
+//# sourceMappingURL=smartart-hierarchy-orientation-types.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-orientation-types.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-orientation-types.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-orientation-types.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,MAAM,WAAW,oBAAoB;IACpC,6FAA6F;IAC7F,UAAU,EAAE,OAAO,CAAC;IACpB,UAAU,EAAE,MAAM,CAAC;IACnB,uNAAuN;IACvN,WAAW,EAAE,MAAM,CAAC;IACpB,wRAAwR;IACxR,kBAAkB,EAAE,MAAM,CAAC;IAC3B,6VAA6V;IAC7V,2BAA2B,EAAE,MAAM,CAAC;IACpC;;;;;;;;;;;;;;;OAeG;IACH,eAAe,EAAE,MAAM,GAAG,SAAS,CAAC;IACpC,oIAAoI;IACpI,YAAY,EAAE,MAAM,CAAC;IACrB,2IAA2I;IAC3I,YAAY,EAAE,MAAM,CAAC;IACrB;;;;;;;;OAQG;IACH,oBAAoB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IAC1C;;;;;;;OAOG;IACH,qBAAqB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IAC3C;;;;;;;;;;;OAWG;IACH,yBAAyB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IAC/C;;;;OAIG;IACH,gBAAgB,EAAE,MAAM,CAAC;CACzB"}

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

@@ -0,0 +1,78 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy axis orientation.
+ *
+ * `smartart-layout-interpreter-hierarchy.ts`'s `fitItemBox`/`placeStandardTree`
+ * assume the classic org-chart orientation: siblings fan along X, generations
+ * stack down Y. "Horizontal Hierarchy" (and its
+ * `horizontal-multi-level-hierarchy`/`horizontal-labeled-hierarchy` siblings)
+ * is the SAME `hierChild`/`hierRoot` algorithm with the axes swapped -
+ * COM-verified against `horizontal-hierarchy--flat3.pptx` (root flush LEFT,
+ * its two children stacked in a column at the right, not the
+ * top-center/bottom-row shape "Hierarchy" renders).
+ *
+ * The declarative signal: "Horizontal Hierarchy"'s `layout1.xml` expresses
+ * the item's free-variable `w`/`h` pair, `sibSp` (fan-axis gap) and `sp`
+ * (generation-axis gap) all relative to `h` (`<dgm:constr type="w" ...
+ * refType="h" fact="2"/>`, `<dgm:constr type="sibSp" refType="h" .../>`)
+ * where "Hierarchy" expresses the same trio relative to `w`
+ * (`h refType="w" fact="0.667"`, `sibSp refType="w"`). Reading which axis
+ * `sibSp` references is a genuine declarative transposition signal, not a
+ * guess keyed off the layout's name, and reading the `w:h`/`sp` facts
+ * directly (rather than hardcoding "Hierarchy"'s own 0.667/0.25) generalises
+ * to any hierarchy-family layout with its own aspect/gap.
+ *
+ * Implementation: rather than teach `placeStandardTree` a second, mirrored
+ * code path, `arrangeHierarchy` runs the WHOLE existing (X-fans/Y-stacks)
+ * algorithm against a `{width: box.height, height: box.width}` "logical" box
+ * when transposed, then `transposeResult` swaps every rendered node's/
+ * connector's x<->y (and width<->height) back into the real box's coordinate
+ * system as a final pass - zero duplicated placement logic, and a future fix
+ * to `placeStandardTree` benefits both orientations for free.
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+import type { HierarchyOrientation } from './smartart-hierarchy-orientation-types.js';
+export { findByReference } from './smartart-hierarchy-constraint-lookup.js';
+/**
+ * Outer margin around the whole tree, as a fraction of the diagram box, for
+ * a NON-TRANSPOSED hierarchy (plain "Hierarchy" itself). COM-verified (not
+ * declared by any `layout1.xml` constraint under either name checked):
+ * solving the fan-packing equation below for TWO independent genuine samples
+ * with different sibling counts (`hierarchy--flat3.pptx`, a 2-wide fan, and
+ * `hierarchy--hier8.pptx`, a 5-wide fan) against the SAME `sibSp` ratio
+ * yields a consistent margin on both axes, so it is treated as a fixed
+ * diagram-edge inset rather than folded into the packing ratio.
+ *
+ * A TRANSPOSED hierarchy ("Horizontal Hierarchy" and its siblings) needs NO
+ * such margin at all - COM-verified against TWO independent genuine samples
+ * on EACH axis (`horizontal-hierarchy--flat3.pptx`, 2-wide fan/2 generations,
+ * and `--hier5.pptx`, the SAME 2-wide fan but 3 generations): plugging the
+ * layout's own declared `sibSp`/`sp` facts directly into the packing
+ * equation with ZERO outer margin reproduces both fixtures' cached item
+ * size on BOTH axes to within rounding (fan axis: 247.9 vs cached 248 on
+ * both; generation axis: 361.25 vs cached 361 for 2 generations, 228.16 vs
+ * cached 228 for 3 generations). This is a real, measured difference
+ * between the two orientations (not yet explained from first principles -
+ * `layout1.xml` declares no margin-shaped constraint for either family, so
+ * it is presumably an artifact of how the two orientations' own connector
+ * routing consumes space), keyed off the SAME declarative `transposed`
+ * signal `resolveHierarchyOrientation` already derives from `sibSp`'s own
+ * `referenceType` - not a per-layout-name guess.
+ */
+export declare const OUTER_MARGIN_X_RATIO = 0.0491;
+export declare const OUTER_MARGIN_Y_RATIO = 0.0707;
+export type { HierarchyOrientation };
+/**
+ * Resolve whether `algorithmNode` is a transposed (horizontal-fan) hierarchy
+ * and every ratio `fitItemBox` needs, all read from its own declared
+ * constraints where possible (see the module doc comment for the exact
+ * `dgm:constr` shapes distinguishing the two orientations).
+ */
+export declare function resolveHierarchyOrientation<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, index: ConstraintIndex, mode?: 'std' | 'tailed' | 'hanging', itemShapeName?: string): HierarchyOrientation;
+export { transposeResult } from './smartart-hierarchy-transpose.js';
+export { fitItemBox } from './smartart-hierarchy-fit-item-box.js';
+export { applyChildOrder } from './smartart-hierarchy-child-order.js';
+//# sourceMappingURL=smartart-hierarchy-orientation.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-orientation.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-orientation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAChE,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAElD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAY5E,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,wCAAwC,CAAC;AAInF,OAAO,EAAE,eAAe,EAAE,MAAM,wCAAwC,CAAC;AAIzE;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,eAAO,MAAM,oBAAoB,SAAS,CAAC;AAC3C,eAAO,MAAM,oBAAoB,SAAS,CAAC;AAK3C,YAAY,EAAE,oBAAoB,EAAE,CAAC;AAErC;;;;;GAKG;AACH,wBAAgB,2BAA2B,CAAC,CAAC,EAC5C,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,KAAK,EAAE,eAAe,EACtB,IAAI,GAAE,KAAK,GAAG,QAAQ,GAAG,SAAiB,EAC1C,aAAa,CAAC,EAAE,MAAM,GACpB,oBAAoB,CA2JtB;AAKD,OAAO,EAAE,eAAe,EAAE,MAAM,gCAAgC,CAAC;AAKjE,OAAO,EAAE,UAAU,EAAE,MAAM,mCAAmC,CAAC;AAK/D,OAAO,EAAE,eAAe,EAAE,MAAM,kCAAkC,CAAC"}