ooxml-core 1.1.0 → 1.2.0

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

@@ -0,0 +1,140 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy axis pitch/margin.
+ *
+ * `smartart-layout-interpreter-hierarchy.ts`'s `cellW`/`cellH` used to be a
+ * naive `box.dimension / count` split, which distributes any leftover space
+ * as an EQUAL margin on both ends ("space-around"). Real PowerPoint does two
+ * GENUINELY DIFFERENT things per axis (live-COM-verified round 11/SESSION 8
+ * against `hierarchy--flat3.pptx`/`--hier5.pptx`/`--hier8.pptx`'s cached
+ * `dsp:sp` geometry, corrected from an EARLIER derivation that was measured
+ * against a since-fixed cached-reader bug and got the fan axis wrong - see
+ * `smartart-layout-interpreter-hierarchy.ts`'s own module doc comment for the
+ * full correction history):
+ *
+ *   - The GENERATION (stacking) axis is CENTRED (`computeAxisPitch`, SESSION
+ *     16 correction), with a small constant top bias: slack (`dimension -
+ *     n*itemSize - (n-1)*gap`) splits evenly between the leading and trailing
+ *     edge, and `margin` (a fraction of the ITEM's OWN height, NOT the box's -
+ *     see `GENERATION_MARGIN_RATIO`'s own doc comment) shifts HALF of itself
+ *     from the trailing edge to the leading edge on top of that centring, not
+ *     an absolute leading-only margin against a trailing-flush pack (the
+ *     PRE-SESSION-16 model - see `computeAxisPitch`'s own doc comment for why
+ *     that was only ever a coincidental match for a 2-3 generation tree that
+ *     happens to nearly fill `dimension`, and the 4-sample COM measurement
+ *     that overturned it for anything taller).
+ *   - The FAN (sibling) axis is CENTRED instead (`centeredAxisPitch`, NEW in
+ *     round 11/SESSION 8): a FIXED gap ratio (the layout's own declared
+ *     `sibSp`), with whatever slack remains split EVENLY on both sides -
+ *     `hierarchy--flat3.pptx`/`--hier5.pptx` both show their own cached
+ *     content span leaving REAL slack on this axis (the generation axis is
+ *     what fills the frame), centred, never flush against one edge. An
+ *     EARLIER derivation of this axis (superseded, kept only as history: a
+ *     `FAN_MARGIN_RATIO=0.1115` leading-margin constant) was measured against
+ *     a cached-reader bug that silently rescaled content to fill the frame,
+ *     making the fan axis LOOK trailing-flush like the generation axis; once
+ *     the reader was fixed, the fan axis's own real slack turned out to be
+ *     centred, not flush - a structurally different model, not just a
+ *     different number.
+ *
+ * `placeStandardTree`'s existing `cx=(offset+w/2)*cellW` /
+ * `cy=level*cellH+cellH/2` formulas already implement "space-around" when
+ * `cellW`/`cellH` is the full pitch (item + gap): the first item centres at
+ * `cellW/2`, i.e. half a pitch in - which is a margin of `gap/2`, not either
+ * axis's own real margin. Both `computeAxisPitch` and `centeredAxisPitch`
+ * return that same `pitch` (unchanged use as `cellW`/`cellH`) plus a `shift`
+ * - the constant offset that corrects the implicit `gap/2` leading margin
+ * into the real one - which `translateResult` applies to the WHOLE computed
+ * layout as a final pass, the same "compute plainly, then correct with a
+ * pass" shape `smartart-hierarchy-orientation.ts`'s `transposeResult` uses.
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { SmartArtLayoutResult } from '../layout/smartart-layout-types.js';
+/** COM-verified leading-margin ratio for the generation (stacking) axis, as a fraction of the item's OWN size on that axis - see the module doc comment. */
+export declare const GENERATION_MARGIN_RATIO = 0.1675;
+export interface AxisPitch {
+    /** Item size + inter-item gap - use directly as `cellW`/`cellH`. */
+    pitch: number;
+    /** Constant offset `translateResult` applies to correct the leading margin. */
+    shift: number;
+}
+/**
+ * A leading-margin/trailing-flush pack - see the module doc comment. Used
+ * for the GENERATION axis always (`margin = GENERATION_MARGIN_RATIO *
+ * itemSize`, `itemSize = boxH`, `count = depth`), and for `tailed`-mode
+ * (org-chart family)'s own FAN axis with `margin=0` (not yet re-verified
+ * against live COM this round - see `smartart-layout-interpreter-
+ * hierarchy.ts`'s own call site comment). `dimension`: the axis's own box
+ * size (already orientation-swapped by the caller when transposed).
+ *
+ * `fixedGapRatio` (optional, every existing caller that omits it is
+ * byte-identical - see this function's own regression tests): when given,
+ * the gap is `itemSize * fixedGapRatio` directly instead of SOLVED to fill
+ * `dimension` exactly. The solved gap is only a correct model for a tree
+ * that genuinely spans every generation with a real fan at each one - for
+ * `hierarchy--hier8.pptx` (a `sibSp`/`sp`-declaring composite-wrapped
+ * layout whose deepest generation is a lone descendant past the main fan,
+ * not itself fanned), the solved gap (forcing the row stack to fill the
+ * whole box) measures 49.86px against the fixture's own real, independently
+ * measured (raw `dsp:sp` offsets) 41.98px - `hierarchy--flat3.pptx`/
+ * `--hier5.pptx` (2/3 generations, no such lone tail) show the SOLVED gap
+ * coincidentally equals `itemSize * 0.4580` almost exactly, which is why
+ * this bug was invisible until a 4-generation, unevenly-fanned sample
+ * existed to distinguish the two models - see
+ * `resolveGenerationGapRatio`'s own doc comment in `smartart-hierarchy-
+ * orientation.ts` for the declarative derivation of this ratio. Passing it
+ * does NOT by itself fix `hierarchy--hier8.pptx`'s own leading margin
+ * (`GENERATION_MARGIN_RATIO` remains unvalidated past 3 generations - see
+ * `smartart-track-r-successor.md`'s own SESSION 10) - it only corrects the
+ * GAP between rows to the genuine, multi-sample-confirmed constant, turning
+ * a deviation that GREW with generation depth into a constant one.
+ */
+export declare function computeAxisPitch(dimension: number, margin: number, itemSize: number, count: number, fixedGapRatio?: number): AxisPitch;
+/**
+ * The FAN axis's own real positioning (round 11/SESSION 8 correction):
+ * unlike the generation axis (`computeAxisPitch`, a genuine leading-margin/
+ * trailing-flush pack), the fan axis is CENTRED - a FIXED gap ratio (the
+ * layout's own declared `sibSp`, not a margin solved to fill the box), with
+ * whatever slack remains after packing at that ratio split EVENLY on both
+ * sides. COM-verified against `hierarchy--hier5.pptx`/`--flat3.pptx`: their
+ * own cached content span (`n*boxW + (n-1)*sibSp`) leaves REAL slack on the
+ * fan axis (the generation axis is what fills the frame - see
+ * `smartart-layout-interpreter-hierarchy.ts`'s module doc comment), and that
+ * slack sits as an EQUAL margin on both ends, never flush against one edge
+ * the way `computeAxisPitch`'s own "solve gap to fill exactly" model forces
+ * it to be when handed a `margin=0` (which is what every non-tailed caller
+ * was passing for the fan axis pre-correction - the bug this function
+ * fixes: forcing an artificially STRETCHED gap to fill the box, instead of
+ * using the item's own real, much smaller `sibSp` gap and centring the
+ * genuine leftover slack).
+ */
+export declare function centeredAxisPitch(dimension: number, itemSize: number, gapRatio: number, count: number): AxisPitch;
+/**
+ * The FAN axis's own pitch when the layout declares a `composite` wrapper
+ * (round 11/SESSION 9: `smartart-hierarchy-composite-child.ts`) - the CELLS
+ * being centred are the WRAPPING `composite`'s own (`compositeW =
+ * boxW/compositeWidthFactor`, LARGER than the rendered `boxW`), not the
+ * rendered item. `placeStandardTree`'s own `cx=(offset+0.5)*pitch+shift`
+ * formula renders each item (width `boxW`) CENTRED on `cx`, which is only
+ * correct when the rendered item sits centred within its own composite cell
+ * too - it does not (it is offset by the layout's own "3D card"
+ * `cardOffsetXRatio*compositeW`), so the plain `centeredAxisPitch` shift
+ * needs a further correction (`+cardOffsetX+boxW/2-pitch/2`) to land the
+ * RENDERED item's own centre exactly where the real, offset item sits -
+ * solved by equating `cx(i) = compositeCellLeftEdge(i)+cardOffsetX+boxW/2`
+ * for every `i` and matching coefficients. `compositeWidthFactor`
+ * `undefined` (no wrapper declared, e.g. "Horizontal Hierarchy") falls back
+ * to centring the rendered item directly (`compositeW=boxW`,
+ * `cardOffsetXRatio` ignored) - the SAME correction term still applies then
+ * (it accounts for `cx`'s own pitch-based, not itemSize-based, centring),
+ * and empirically improves that family too (not just the composite-wrapper
+ * one - see `smartart-track-r-successor.md`'s own SESSION 9).
+ */
+export declare function compositeFanPitch(dimension: number, boxW: number, compositeWidthFactor: number | undefined, cardOffsetXRatio: number, sibSpRatio: number, count: number): AxisPitch;
+/**
+ * Shift a whole `SmartArtLayoutResult` by a constant `(dx, dy)` - see the
+ * module doc comment for why `computeAxisPitch`'s `shift` needs this instead
+ * of threading an offset through `placeStandardTree`/`placeAt` directly.
+ */
+export declare function translateResult(result: SmartArtLayoutResult, dx: number, dy: number): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-hierarchy-pitch.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-pitch.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-pitch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AAEH,OAAO,KAAK,EAGX,oBAAoB,EACpB,MAAM,iCAAiC,CAAC;AAEzC,4JAA4J;AAC5J,eAAO,MAAM,uBAAuB,SAAS,CAAC;AAE9C,MAAM,WAAW,SAAS;IACzB,oEAAoE;IACpE,KAAK,EAAE,MAAM,CAAC;IACd,+EAA+E;IAC/E,KAAK,EAAE,MAAM,CAAC;CACd;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AACH,wBAAgB,gBAAgB,CAC/B,SAAS,EAAE,MAAM,EACjB,MAAM,EAAE,MAAM,EACd,QAAQ,EAAE,MAAM,EAChB,KAAK,EAAE,MAAM,EACb,aAAa,CAAC,EAAE,MAAM,GACpB,SAAS,CAiDX;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,iBAAiB,CAChC,SAAS,EAAE,MAAM,EACjB,QAAQ,EAAE,MAAM,EAChB,QAAQ,EAAE,MAAM,EAChB,KAAK,EAAE,MAAM,GACX,SAAS,CAWX;AAED;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,wBAAgB,iBAAiB,CAChC,SAAS,EAAE,MAAM,EACjB,IAAI,EAAE,MAAM,EACZ,oBAAoB,EAAE,MAAM,GAAG,SAAS,EACxC,gBAAgB,EAAE,MAAM,EACxB,UAAU,EAAE,MAAM,EAClB,KAAK,EAAE,MAAM,GACX,SAAS,CAMX;AAmDD;;;;GAIG;AACH,wBAAgB,eAAe,CAC9B,MAAM,EAAE,oBAAoB,EAC5B,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,GACR,oBAAoB,CAUtB"}

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

@@ -0,0 +1,131 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy arranger shared render context.
+ *
+ * The per-run render context and the rect/connector factories shared by the
+ * standard/init tree placer (`smartart-hierarchy-standard.ts`) and the
+ * hanging-column placer (`smartart-hierarchy-hanging.ts`). Org-chart tree
+ * shaping (assistant partitioning, group-wrapper flattening, effective
+ * width) lives in `smartart-hierarchy-orgchart-tree.ts` (split out for the
+ * file-size budget). Pure geometry; no framework code, no DOM.
+ */
+import type { DiagramLayoutNode, DiagramLayoutNodeShape, DiagramNode } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { StyleContext } from '../layout/smartart-layout-interpreter-render.js';
+import type { RenderedConnector, RenderedNode } from '../layout/smartart-layout-types.js';
+/**
+ * Find the actual per-node preset geometry a hierarchy item box should carry.
+ *
+ * Every genuine org-chart-family item is itself a small `composite` (a
+ * genuine fixture's `rootComposite` -> `rootText` (`alg="tx"`, the real
+ * `dgm:shape` - e.g. `rect`) + `rootConnector` (`alg="sp"`, a hidden spacer)):
+ * this arranger renders that whole per-node composite as ONE box, so the
+ * preset that must reach the save-pipeline bridge
+ * (`smartart-interpreter-drawing-bridge.ts`) is the `tx`-algorithm
+ * descendant's own shape, not the wrapping `composite` node's (which never
+ * declares a `@type`, only `hierRoot`/`hierChild`'s first child directly).
+ * Depth-first, first `tx` node with a shape wins - UNLESS a second `tx`+shape
+ * template exists that cross-references the first one's own dimension by
+ * name, in which case the cross-referencing (majority-generation) template
+ * wins instead - see `resolveHierarchyItemNode`'s own module doc comment in
+ * `smartart-hierarchy-item-template.ts`. `undefined` when the arranger's item
+ * template declares no shape anywhere (falls back to `presetBoxNode`'s own
+ * family default).
+ */
+export declare function findHierarchyItemShape(node: DiagramLayoutNode | undefined): DiagramLayoutNodeShape | undefined;
+/**
+ * The item template's own layoutNode NAME (e.g. `level1Shape`, `rootText1`)
+ * - the SAME node `findHierarchyItemShape` finds, but its `name` rather than
+ * its `shape`. SESSION 24: used to search a `ConstraintIndex` for a
+ * generation-gap `sp` constraint declared on an ANCESTOR of `hierChild`
+ * (see `resolveGenerationGapFromIndex`'s own doc comment in `smartart-
+ * hierarchy-generation-gap.ts`) that references this exact name - a
+ * constraint reachable only by name, not by tree position.
+ */
+export declare function findHierarchyItemName(node: DiagramLayoutNode | undefined): string | undefined;
+/**
+ * The org-chart-family "hierRoot" algorithm's root-box alignment offset
+ * (`dgm:param type="hierAlign"` / `dgm:constr type="alignOff"` in the built-in
+ * "Organization Chart" layoutDef), as a fraction of one box's width.
+ *
+ * Measured directly against genuine PowerPoint cached `dsp:drawing` output
+ * (not derived from the ECMA-376 constraint text, which this interpreter does
+ * not solve generically): every sampled hanging-generation transition offsets
+ * the child column by EXACTLY 0.25x the box width from its parent's own left
+ * edge, regardless of `hierBranch` (`std`/`init`/`l`/`r`/`hang` all measured
+ * identical) and regardless of generation depth:
+ *
+ *   - `smartart-orgchart-hierbranch.pptx` slides 1-4 (Standard/Both/Left/Right
+ *     Hanging): Report One -> Analyst One, every variant, ratio 0.25 exactly.
+ *   - `smartart-orgchart-many.pptx`: a flattened report-group's real children
+ *     offset 0.25 from the (dropped) group-wrapper's own fanned slot.
+ *   - `smartart-orgchart-nested-hang.pptx` (Standard AND Both Hanging):
+ *     Team One's own hanging children (Team Four/Five, a THIRD generation)
+ *     offset 0.25 from Team One, confirming the ratio recurses unchanged at
+ *     deeper generations, and that "Both Hanging" does NOT alternate side for
+ *     multiple ordinary children of the SAME parent (they share one column,
+ *     same as every other `hierBranch` value) - see the doc comment on
+ *     `placeHangingTree` in `smartart-hierarchy-hanging.ts`.
+ *
+ * Used both for the first hop out of a fanned/flattened parent (see
+ * `smartart-hierarchy-standard.ts`'s `hangingPlacer` invocation) and for every
+ * further hop within the hanging tail itself (`HangingOptions.indent` in
+ * `smartart-hierarchy-hanging.ts`).
+ */
+export declare const HIER_TAIL_OFFSET_RATIO = 0.25;
+/**
+ * Extra vertical gap between consecutive hanging-tail boxes, as a fraction of
+ * the item's own height (`HangingOptions.vGap` in `smartart-hierarchy-
+ * hanging.ts`, and `arrangeHierarchy`'s own `vGap` setup in
+ * `smartart-layout-interpreter-hierarchy.ts`). Also consumed by `fitItemBox`
+ * (`smartart-hierarchy-orientation.ts`) to size the item box AROUND the
+ * generation-axis room a hanging tail will actually need - see
+ * `smartart-hierarchy-hang-depth.ts`'s module doc comment for the
+ * COM-verified derivation (`organization-chart--hier5.pptx`/`--hier8.pptx`).
+ */
+export declare const HANG_HEIGHT_RATIO = 0.55;
+/** Mutable render state threaded through one hierarchy arrangement pass. */
+export interface HierContext {
+    elementId: string;
+    palette: string[];
+    style: DiagramStyleIntensity;
+    ctx: StyleContext;
+    total: number;
+    boxW: number;
+    boxH: number;
+    nodes: RenderedNode[];
+    connectors: RenderedConnector[];
+    counter: {
+        value: number;
+    };
+    /**
+     * Connector text keyed `${parentNodeId}>${childNodeId}`, resolved from
+     * each `parOf` connection's linked `parTrans` point (see
+     * `PptxSmartArtConnection.label`). Looked up by {@link elbowConnector}.
+     */
+    connectorLabels?: Map<string, string> | undefined;
+    /** The item template's own preset override; see {@link findHierarchyItemShape}. */
+    itemShape?: DiagramLayoutNodeShape | undefined;
+    /**
+     * ONE shared font size (pixels), pre-fit across every node's text at the
+     * uniform `boxW`/`boxH` this run places every item at - see
+     * `smartart-layout-interpreter-hierarchy.ts`'s `resolveHierarchyItemFontSizePx`
+     * doc comment for why this must be resolved BEFORE any node is pushed.
+     * `undefined` (no `algorithmNode`, or nothing fits) keeps `pushNode`'s
+     * previous behaviour: `presetBoxNode`'s own crude per-node char-width
+     * fallback.
+     */
+    itemFontSizePx?: number | undefined;
+}
+export declare function baseContext(nodeCount: number, elementId: string, palette: string[], style: DiagramStyleIntensity, boxW: number, boxH: number, connectorLabels?: Map<string, string>, itemShape?: DiagramLayoutNodeShape, itemFontSizePx?: number): HierContext;
+export declare function pushNode(hc: HierContext, node: DiagramNode, x: number, y: number, width?: number, height?: number): number;
+/**
+ * Elbow connector (drop, then across, then drop) used for a normal child.
+ *
+ * @param toId - The child node's id, used with `fromId` to look up this
+ *               edge's connector text in `hc.connectorLabels`, when the
+ *               caller has it (every genuine parent/child edge does).
+ */
+export declare function elbowConnector(hc: HierContext, fromId: string, fx: number, fy: number, cx: number, cy: number, toId?: string): void;
+/** Short straight stub connector, visually distinct from `elbowConnector`. */
+export declare function stubConnector(hc: HierContext, fromId: string, fx: number, fy: number, cx: number, cy: number): void;
+//# sourceMappingURL=smartart-hierarchy-shared.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-shared.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-shared.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,sBAAsB,EAAE,WAAW,EAAE,MAAM,UAAU,CAAC;AACvF,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AAItD,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,8CAA8C,CAAC;AACjF,OAAO,KAAK,EAAE,iBAAiB,EAAE,YAAY,EAAE,MAAM,iCAAiC,CAAC;AAEvF;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,sBAAsB,CACrC,IAAI,EAAE,iBAAiB,GAAG,SAAS,GACjC,sBAAsB,GAAG,SAAS,CAEpC;AAED;;;;;;;;GAQG;AACH,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,iBAAiB,GAAG,SAAS,GAAG,MAAM,GAAG,SAAS,CAE7F;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AACH,eAAO,MAAM,sBAAsB,OAAO,CAAC;AAE3C;;;;;;;;;GASG;AACH,eAAO,MAAM,iBAAiB,OAAO,CAAC;AAEtC,4EAA4E;AAC5E,MAAM,WAAW,WAAW;IAC3B,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,KAAK,EAAE,qBAAqB,CAAC;IAC7B,GAAG,EAAE,YAAY,CAAC;IAClB,KAAK,EAAE,MAAM,CAAC;IACd,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,YAAY,EAAE,CAAC;IACtB,UAAU,EAAE,iBAAiB,EAAE,CAAC;IAChC,OAAO,EAAE;QAAE,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC;IAC3B;;;;OAIG;IACH,eAAe,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,SAAS,CAAC;IAClD,mFAAmF;IACnF,SAAS,CAAC,EAAE,sBAAsB,GAAG,SAAS,CAAC;IAC/C;;;;;;;;OAQG;IACH,cAAc,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;CACpC;AAED,wBAAgB,WAAW,CAC1B,SAAS,EAAE,MAAM,EACjB,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,IAAI,EAAE,MAAM,EACZ,IAAI,EAAE,MAAM,EACZ,eAAe,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,EACrC,SAAS,CAAC,EAAE,sBAAsB,EAClC,cAAc,CAAC,EAAE,MAAM,GACrB,WAAW,CAgBb;AAED,wBAAgB,QAAQ,CACvB,EAAE,EAAE,WAAW,EACf,IAAI,EAAE,WAAW,EACjB,CAAC,EAAE,MAAM,EACT,CAAC,EAAE,MAAM,EACT,KAAK,SAAU,EACf,MAAM,SAAU,GACd,MAAM,CAqBR;AAED;;;;;;GAMG;AACH,wBAAgB,cAAc,CAC7B,EAAE,EAAE,WAAW,EACf,MAAM,EAAE,MAAM,EACd,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,IAAI,CAAC,EAAE,MAAM,GACX,IAAI,CAQN;AAED,8EAA8E;AAC9E,wBAAgB,aAAa,CAC5B,EAAE,EAAE,WAAW,EACf,MAAM,EAAE,MAAM,EACd,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,GACR,IAAI,CAMN"}

package/dist/diagram/hierarchy/smartart-hierarchy-standard-options.d.ts

@@ -0,0 +1,91 @@
+/**
+ * SmartArt DiagramML interpreter - "standard" hierarchy branch options type.
+ *
+ * Split out of `smartart-hierarchy-standard.ts` (the file-size budget) so
+ * `smartart-hierarchy-standard-rows.ts` can reference it without an import
+ * cycle back into that module.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { HierContext } from './smartart-hierarchy-shared.js';
+/** Resolved options for one standard-branch arrangement pass. */
+export interface StandardOptions {
+    orgChart: boolean;
+    /** Resolved `chPref`/`chMax` row size; `Infinity` when unbounded. */
+    perRow: number;
+    /**
+     * Fan-aware column-span override (`tailed` mode only - see
+     * `buildFanAwareWidthMap`'s doc comment in `smartart-hierarchy-fan-aware-width.ts`):
+     * when present, every span/offset computation in this module and
+     * `smartart-hierarchy-standard-rows.ts` consults THIS instead of plain
+     * `effectiveWidth` (via `spanOf` below) - a node that is about to HANG (not
+     * fan) collapses its entire subtree to exactly one column regardless of its
+     * own descendant count, matching `placeHangingTree`'s own single
+     * shared-column behaviour. `std` mode (no `hangingPlacer`) never sets this
+     * and keeps using plain `effectiveWidth` everywhere, unaffected.
+     */
+    resolveSpan?: ((t: TreeNode) => number) | undefined;
+    /**
+     * Present for `hierBranch` `init`/`hang`/`l`/`r`: places every generation
+     * past the root's direct children as a hanging column instead of
+     * continuing the standard fan-out. Takes the FULL sibling list (not one
+     * subtree at a time): genuine PowerPoint output stacks a node's several
+     * ordinary children in ONE shared column at a single x, not one
+     * side-by-side column per child - see `smartart-orgchart-hierbranch.pptx`
+     * in the corpus, where a manager's own two-report tail (each report having
+     * further children of its own) still lands both reports at the same x.
+     * That shared column itself starts offset from `t` by
+     * `HIER_TAIL_OFFSET_RATIO` (the `hierAlign`/`alignOff` root-box alignment;
+     * see its doc comment), not flush with `t`'s own left edge.
+     */
+    hangingPlacer?: ((hc: HierContext, subtrees: TreeNode[], anchorX: number, anchorY: number) => void) | undefined;
+    /**
+     * The gap between a hanging parent's own bottom edge and its tail's first
+     * box, as a fraction of the item's own height (`HANG_HEIGHT_RATIO` by
+     * default when unset - see that constant's doc comment). SESSION 25: a
+     * TRANSPOSED tailed hierarchy (e.g. "Horizontal Organization Chart") needs
+     * `orientation.generationGapRatio` here instead - see `fitItemBox`'s own
+     * `hangHeightRatio` doc comment (`smartart-hierarchy-fit-item-box.ts`) for
+     * the full derivation; this is the SAME ratio, applied at the actual
+     * hang-tail placement site instead of the size/pitch solve.
+     */
+    hangHeightRatio?: number | undefined;
+    /**
+     * True when the layout definition's own per-item template folds every
+     * descendant beyond the root's direct children into that SAME box's text
+     * (`hierarchyLeafFoldsDescendants`, `smartart-hierarchy-fold-depth.ts`) -
+     * `hierarchy-list--hier5.pptx`'s shape, where only ONE generation past the
+     * root gets its own box and anything deeper folds in via the pre-existing
+     * `collectFoldedDescendants` bridge mechanism (see that module's doc
+     * comment). `placeAt` stops recursing into a node's own children once
+     * `level >= 1` when this is set - the common "Hierarchy"/"Organization
+     * Chart" family (recursive `hierRoot`/`hierChild` nesting, one generation
+     * per data depth) leaves this `false` and is unaffected.
+     */
+    foldDeeperGenerations?: boolean | undefined;
+    /**
+     * SESSION 28: the declared cascade construct's own directional nudge
+     * (`cascadeAllGenerations`, `smartart-layout-interpreter-hierarchy.ts`) -
+     * every node at `level >= fromLevel` shifts by a FIXED `offsetPx` on the
+     * fan axis, on top of its own otherwise-normal fanned/centred position.
+     * `half-circle-organization-chart--hier5.pptx`'s own `layout1.xml`
+     * declares `dgm:constr type="alignOff" val="0.65"` on every `hierRoot`
+     * branch past the root itself - local-coordinate analysis of the
+     * fixture's own cached geometry confirms each row-past-the-fan node sits
+     * exactly `0.65 * compositeW` to the right of its own immediate parent
+     * (`181px` measured against a `278px` composite, `0.65*278=180.7`),
+     * REGARDLESS of which branch (left/right) that parent took - not a
+     * mirrored hang-tail indent (`HIER_TAIL_OFFSET_RATIO`'s own existing
+     * per-branch-direction model), a single constant direction. Since every
+     * node this cascade places past the fan is a SOLO child of its own parent
+     * (`spanW===1`), its otherwise-default fan-centred `cx` already equals
+     * its parent's own `cx` - adding this constant reproduces the declared
+     * offset exactly without needing to thread parent position separately.
+     */
+    cascadeOffsetX?: {
+        fromLevel: number;
+        offsetPx: number;
+    } | undefined;
+}
+/** `t`'s own column span, honouring `options.resolveSpan` when set (see its doc comment). */
+export declare function spanOf(t: TreeNode, options: StandardOptions): number;
+//# sourceMappingURL=smartart-hierarchy-standard-options.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-standard-options.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-standard-options.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-standard-options.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAExD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;AAE/D,iEAAiE;AACjE,MAAM,WAAW,eAAe;IAC/B,QAAQ,EAAE,OAAO,CAAC;IAClB,qEAAqE;IACrE,MAAM,EAAE,MAAM,CAAC;IACf;;;;;;;;;;OAUG;IACH,WAAW,CAAC,EAAE,CAAC,CAAC,CAAC,EAAE,QAAQ,KAAK,MAAM,CAAC,GAAG,SAAS,CAAC;IACpD;;;;;;;;;;;;OAYG;IACH,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;IACb;;;;;;;;;OASG;IACH,eAAe,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACrC;;;;;;;;;;;OAWG;IACH,qBAAqB,CAAC,EAAE,OAAO,GAAG,SAAS,CAAC;IAC5C;;;;;;;;;;;;;;;;;;OAkBG;IACH,cAAc,CAAC,EAAE;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,CAAA;KAAE,GAAG,SAAS,CAAC;CACrE;AAED,6FAA6F;AAC7F,wBAAgB,MAAM,CAAC,CAAC,EAAE,QAAQ,EAAE,OAAO,EAAE,eAAe,GAAG,MAAM,CAEpE"}

package/dist/diagram/hierarchy/smartart-hierarchy-standard-rows.d.ts

@@ -0,0 +1,21 @@
+/**
+ * SmartArt DiagramML interpreter - "standard" hierarchy branch row placers.
+ *
+ * Split out of `smartart-hierarchy-standard.ts` (the file-size budget): the
+ * assistant-row and flat (unwrapped) sibling-row placers, both leaf helpers
+ * with no recursive fan/hang decision of their own - `placeAt` (that module)
+ * calls back into `placeAt` itself for each child placed here via the
+ * `placeChild` callback, avoiding an import cycle.
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { HierContext } from './smartart-hierarchy-shared.js';
+import type { StandardOptions } from './smartart-hierarchy-standard-options.js';
+/** Render a manager's assistant row directly beneath it (`orgChart` mode). */
+export declare function placeAssistantRow(hc: HierContext, parentId: string, cx: number, cy: number, assistants: TreeNode[]): void;
+/** One child placement, as `placeAt` itself implements (passed in to avoid an import cycle). */
+export type PlaceChild = (hc: HierContext, t: TreeNode, cx: number, cy: number, xOffset: number, spanW: number, level: number, cellW: number, cellH: number, options: StandardOptions, siblingCxs?: number[]) => void;
+/** Place one generation's ordinary children in a single row (no wrapping). */
+export declare function placeFlatChildren(hc: HierContext, parentId: string, normal: TreeNode[], cx: number, cy: number, xOffset: number, level: number, cellW: number, cellH: number, options: StandardOptions, placeChild: PlaceChild): void;
+//# sourceMappingURL=smartart-hierarchy-standard-rows.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-standard-rows.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-standard-rows.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-standard-rows.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAExD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;AAE/D,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,uCAAuC,CAAC;AAI7E,8EAA8E;AAC9E,wBAAgB,iBAAiB,CAChC,EAAE,EAAE,WAAW,EACf,QAAQ,EAAE,MAAM,EAChB,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,UAAU,EAAE,QAAQ,EAAE,GACpB,IAAI,CAcN;AAED,gGAAgG;AAChG,MAAM,MAAM,UAAU,GAAG,CACxB,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,eAAe,EACxB,UAAU,CAAC,EAAE,MAAM,EAAE,KACjB,IAAI,CAAC;AAEV,8EAA8E;AAC9E,wBAAgB,iBAAiB,CAChC,EAAE,EAAE,WAAW,EACf,QAAQ,EAAE,MAAM,EAChB,MAAM,EAAE,QAAQ,EAAE,EAClB,EAAE,EAAE,MAAM,EACV,EAAE,EAAE,MAAM,EACV,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,OAAO,EAAE,eAAe,EACxB,UAAU,EAAE,UAAU,GACpB,IAAI,CAkDN"}

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

@@ -0,0 +1,36 @@
+/**
+ * SmartArt DiagramML interpreter - "standard" hierarchy branch (`hierBranch`
+ * `std`/`init`).
+ *
+ * The classic org-chart tree: a parent centred above its children, which fan
+ * out evenly across the row below. Three behaviours `presLayoutVars` can turn
+ * on, previously ignored entirely (see `smartart-layout-interpreter-hierarchy.ts`):
+ *
+ *   - `orgChart` (with `dgm:pt/@type="asst"` points present): assistant nodes
+ *     render in a small row directly under their manager, connected with a
+ *     short dashed stub, and do not consume a normal sibling's share of the
+ *     row's width (`effectiveWidth`, `smartart-hierarchy-shared.ts`).
+ *   - `chMax` / `chPref`: when a parent has more ordinary children than the
+ *     resolved per-row size, they wrap into multiple rows stacked within the
+ *     same generation's vertical band instead of stretching one row across
+ *     the whole width.
+ *   - `hierBranch="init"`: the ROOT's own children use this standard fan-out,
+ *     but every deeper generation switches to a hanging column (delegated to
+ *     `placeHangingTree` via `hangingPlacer`), matching how a real "Hierarchy"
+ *     layout keeps its first level wide and its detail levels compact.
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { HierContext } from './smartart-hierarchy-shared.js';
+import type { StandardOptions } from './smartart-hierarchy-standard-options.js';
+export type { StandardOptions } from './smartart-hierarchy-standard-options.js';
+/**
+ * Place a whole standard-branch tree rooted at `t`, whose own slot spans
+ * `[xOffset, xOffset + spanOf(t, options))` cells at `level` - `spanOf`
+ * honours `options.resolveSpan` (`tailed` mode's fan-aware width) when set,
+ * plain `effectiveWidth` otherwise. See `StandardOptions.resolveSpan`'s doc
+ * comment.
+ */
+export declare function placeStandardTree(hc: HierContext, t: TreeNode, xOffset: number, level: number, cellW: number, cellH: number, options: StandardOptions): void;
+//# sourceMappingURL=smartart-hierarchy-standard.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-standard.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-standard.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AASxD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;AAE/D,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,uCAAuC,CAAC;AAO7E,YAAY,EAAE,eAAe,EAAE,MAAM,uCAAuC,CAAC;AA6L7E;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAChC,EAAE,EAAE,WAAW,EACf,CAAC,EAAE,QAAQ,EACX,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,KAAK,EAAE,MAAM,EACb,OAAO,EAAE,eAAe,GACtB,IAAI,CASN"}

package/dist/diagram/hierarchy/smartart-hierarchy-tailed-placer.d.ts

@@ -0,0 +1,20 @@
+/**
+ * SmartArt DiagramML interpreter - wire the `tailed` (org-chart) family's own
+ * hanging tail placer.
+ *
+ * Split out of `smartart-hierarchy-hanging.ts` (the file-size budget): pure
+ * relocation, no behaviour change.
+ */
+import type { DiagramPresLayoutVars } from '../model/index.js';
+import type { CascadePlan } from './smartart-hierarchy-cascade.js';
+import type { StandardOptions } from './smartart-hierarchy-standard.js';
+/**
+ * Wire `standardOptions.hangingPlacer` for the `tailed` (org-chart) family's
+ * own hanging tail. A no-op (leaves `standardOptions.hangingPlacer` unset)
+ * for `std`/`hanging` mode and for the SESSION 28 cascade construct
+ * (`cascadePlan.active`): see that field's own call-site doc comment history
+ * for why the cascade shape needs `placeAt`'s DEFAULT fanned-row branch
+ * instead of this placer.
+ */
+export declare function configureTailedHangingPlacer(standardOptions: StandardOptions, mode: 'std' | 'tailed' | 'hanging', cascadePlan: Pick<CascadePlan, 'active'>, boxW: number, boxH: number, presLayoutVars: DiagramPresLayoutVars | undefined, orgChart: boolean): void;
+//# sourceMappingURL=smartart-hierarchy-tailed-placer.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-tailed-placer.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-tailed-placer.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-tailed-placer.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AAEtD,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,8BAA8B,CAAC;AAGhE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,+BAA+B,CAAC;AAErE;;;;;;;GAOG;AACH,wBAAgB,4BAA4B,CAC3C,eAAe,EAAE,eAAe,EAChC,IAAI,EAAE,KAAK,GAAG,QAAQ,GAAG,SAAS,EAClC,WAAW,EAAE,IAAI,CAAC,WAAW,EAAE,QAAQ,CAAC,EACxC,IAAI,EAAE,MAAM,EACZ,IAAI,EAAE,MAAM,EACZ,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,QAAQ,EAAE,OAAO,GACf,IAAI,CAmBN"}

package/dist/diagram/hierarchy/smartart-hierarchy-tailed-transpose.d.ts

@@ -0,0 +1,50 @@
+/**
+ * SmartArt DiagramML interpreter - `tailed` (org-chart family) hierarchy
+ * transposition detection.
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * this module answers ONE narrow question - does `algorithmNode`'s own
+ * TOP-LEVEL `hierChild` algorithm (the arranger governing the tree ROOT's
+ * direct-children fan, always live regardless of `hierBranch`/`dir` - see
+ * `smartart-layout-interpreter-hierarchy.ts`'s own module doc comment)
+ * declare a `chAlign` param.
+ *
+ * Why this can't just be `algorithmParam(algorithmNode, 'chAlign')`: a
+ * genuine org-chart-family layoutDef wraps its ROOT `hierChild` algorithm in
+ * a `dgm:choose` (mirroring `dir="norm"`/`"rtl"`), and `discoverArrangement`
+ * (`smartart-layout-interpreter-model.ts`) deliberately keeps the ORIGINAL,
+ * choose-wrapped node as `hierarchy` - never the param-carrying resolved
+ * copy - because hierarchy code elsewhere compares nodes by REFERENCE
+ * against the original tree (see that function's own comment). So
+ * `algorithmNode.algorithm` is `undefined` for every real org-chart fixture,
+ * and every `dgm:param` the ROOT's own choose declares needs its own reader,
+ * same as `chooseAlgorithm` does for the winning branch's `linDir`/`grDir`/
+ * etc - except this one does not need a winning branch: the `dir="norm"`/
+ * `"rtl"` mirror pair always declares the SAME `chAlign` family (present in
+ * both branches, or absent from both - COM-verified against `organization-
+ * chart`/`half-circle-organization-chart`/`name-and-title-organization-
+ * chart`/`horizontal-organization-chart`'s own `layout1.xml`: the first
+ * three declare no `chAlign` at this level in EITHER branch, only a mirrored
+ * `linDir` `fromL`/`fromR` pair; `horizontal-organization-chart` alone
+ * declares `chAlign` `l`/`r` in both), so reading whichever branch is first
+ * in document order (`when[0]`, or `otherwise` when there is no `if`) is
+ * sufficient - unlike a `dgm:rule`/deeper-generation `chAlign` gated on
+ * `hierBranch` (see `smartart-hierarchy-orientation.ts`'s own module doc
+ * comment), this one is NOT decision-dependent.
+ *
+ * Pure XML/geometry reading; no framework code, no DOM.
+ */
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { DiagramLayoutNode } from '../model/index.js';
+/**
+ * `true` when `algorithmNode`'s own top-level `hierChild` algorithm (direct
+ * or choose-wrapped) declares a `chAlign` param - the `tailed`-family
+ * transposition signal ("Horizontal Organization Chart" and its siblings, if
+ * any share this shape) distinct from the `std` "Hierarchy" family's `sibSp`
+ * referencing `h` (see `smartart-hierarchy-orientation.ts`'s own module doc
+ * comment). Only meaningful for `mode==='tailed'` callers; always `false`
+ * for a `std`/`hanging` hierarchy, which never declares `chAlign` at this
+ * level at all.
+ */
+export declare function tailedHierarchyDeclaresChAlign<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined): boolean;
+//# sourceMappingURL=smartart-hierarchy-tailed-transpose.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-tailed-transpose.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-tailed-transpose.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-tailed-transpose.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AAEH,OAAO,KAAK,EAAqB,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAEnF,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAyBlD;;;;;;;;;GASG;AACH,wBAAgB,8BAA8B,CAAC,CAAC,EAC/C,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,GAC7C,OAAO,CAiBT"}

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

@@ -0,0 +1,23 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy axis transposition (post-pass).
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * `arrangeHierarchy` runs its WHOLE `std`/`tailed` placement algorithm
+ * against a `{width: box.height, height: box.width}` "logical" box when
+ * `resolveHierarchyOrientation` (that module) detects a transposed
+ * hierarchy ("Horizontal Hierarchy" and its siblings), then maps the result
+ * back into the real box's coordinate system as a final pass - this module
+ * is that pass. See `smartart-hierarchy-orientation.ts`'s own doc comment
+ * for why a post-pass, rather than a second mirrored placement code path.
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { SmartArtLayoutResult } from '../layout/smartart-layout-types.js';
+/**
+ * Map a whole `SmartArtLayoutResult` computed against a `{width: box.height,
+ * height: box.width}` "logical" box back into the real box's coordinate
+ * system - see the module doc comment for why this is a post-pass rather
+ * than a second `placeStandardTree` code path.
+ */
+export declare function transposeResult(result: SmartArtLayoutResult, realWidth: number, realHeight: number): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-hierarchy-transpose.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-transpose.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-transpose.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,OAAO,KAAK,EAGX,oBAAoB,EACpB,MAAM,iCAAiC,CAAC;AAwDzC;;;;;GAKG;AACH,wBAAgB,eAAe,CAC9B,MAAM,EAAE,oBAAoB,EAC5B,SAAS,EAAE,MAAM,EACjB,UAAU,EAAE,MAAM,GAChB,oBAAoB,CAOtB"}

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

@@ -0,0 +1,22 @@
+/**
+ * SmartArt DiagramML interpreter - the TRANSPOSED branch of
+ * `resolveHierarchyOrientation` ("Horizontal Hierarchy" and its siblings).
+ *
+ * Split out of `smartart-hierarchy-orientation.ts` (the file-size budget):
+ * `buildTransposedOrientation`, the `HierarchyOrientation` this construct
+ * resolves to - see that module's own doc comment for the declarative
+ * signal deciding whether a hierarchy takes this branch at all.
+ *
+ * Pure geometry/constraint reading; no framework code.
+ */
+import type { DiagramLayoutNode } from '../model/index.js';
+import type { HierarchyOrientation } from './smartart-hierarchy-orientation-types.js';
+/**
+ * The fan axis's own size is `h`; the stacking axis is `w`, and the item's
+ * cross-axis (logical "cross") size comes from `w:h` resolved as a ratio TO
+ * `h` (i.e. `w = aspectRatio * h`), which `resolveAspectRatio` already gives
+ * as `h:w` - inverted here so callers always multiply the fan-axis size to
+ * get the cross size.
+ */
+export declare function buildTransposedOrientation(constraints: DiagramLayoutNode['constraints'], itemShapeName: string | undefined, sibSpRatio: number): HierarchyOrientation;
+//# sourceMappingURL=smartart-hierarchy-transposed-orientation.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-transposed-orientation.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-transposed-orientation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAGlD,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,wCAAwC,CAAC;AAEnF;;;;;;GAMG;AACH,wBAAgB,0BAA0B,CACzC,WAAW,EAAE,iBAAiB,CAAC,aAAa,CAAC,EAC7C,aAAa,EAAE,MAAM,GAAG,SAAS,EACjC,UAAU,EAAE,MAAM,GAChB,oBAAoB,CA8BtB"}