ooxml-core 1.1.0 → 1.2.0

package/dist/diagram/engine/shape-transform.d.ts

@@ -0,0 +1,14 @@
+/**
+ * The drawing transform of a laid-out node. A layout box is the node's
+ * footprint on the canvas; a `dgm:shape rot` of 90 or 270 degrees stands the
+ * shape on its side inside that footprint, so the unrotated shape (what a
+ * DrawingML `a:xfrm` records before applying `rot`) has the footprint's width
+ * and height swapped about the same centre.
+ */
+import type { Box, EngineNode } from './engine-node.js';
+export interface ShapeTransform extends Box {
+    /** Clockwise rotation in degrees, normalised to [0, 360). */
+    rotation: number;
+}
+export declare function shapeTransform(node: EngineNode): ShapeTransform | undefined;
+//# sourceMappingURL=shape-transform.d.ts.map

package/dist/diagram/engine/shape-transform.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shape-transform.d.ts","sourceRoot":"","sources":["../../../diagram/engine/shape-transform.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,OAAO,KAAK,EAAE,GAAG,EAAE,UAAU,EAAE,MAAM,eAAe,CAAC;AAErD,MAAM,WAAW,cAAe,SAAQ,GAAG;IAC1C,6DAA6D;IAC7D,QAAQ,EAAE,MAAM,CAAC;CACjB;AAED,wBAAgB,cAAc,CAAC,IAAI,EAAE,UAAU,GAAG,cAAc,GAAG,SAAS,CAa3E"}

package/dist/diagram/engine/snake-rule-fit.d.ts

@@ -0,0 +1,34 @@
+/**
+ * A `snake` whose cells a `dgm:rule` may shrink (ECMA-376 Part 1, 21.4.2.x
+ * `dgm:rule`: "Meet the Team"'s `<dgm:rule type="w" for="ch"
+ * forName="compNode" val="50"/>`), and whose cells grow to their content
+ * (`<dgm:rule type="h" val="INF"/>` on the cell). Such a grid does not scale
+ * uniformly: the cell's photo scales with its width but its name and role
+ * lines are fixed millimetre heights, so the grid is re-laid at each
+ * candidate width.
+ *
+ * PowerPoint finds the width by bisection between the rule's `val` and the
+ * cell's constrained width, FIVE probes, keeping the last probe that fits
+ * (or the rule's `val` when none does), breaking lines when the canvas edge
+ * is reached (`bkpt="endCnv"`, the default). Measured on the gallery's
+ * cached drawings, EMU-exact: "Meet the Team" flat3 (3 cells from 100mm:
+ * probes 75, 62.5, 68.75, 71.88, 73.44mm, kept 73.44mm = 2643750 EMU) and
+ * hier5 (4 cells from the 650pt frame width: the fifth probe, 2001719 EMU,
+ * is the first that fits, one row of four); hier8 (6 cells) never fits a
+ * probe and lands on the 50mm floor, two rows of four and two.
+ */
+import type { Box, EngineNode } from './engine-node.js';
+export interface SnakeCellFit {
+    cellW: number;
+    cellH: number;
+    along: number;
+    across: number;
+    cols: number;
+}
+/**
+ * The cell size and line length a rule-shrunk snake settles on, or
+ * `undefined` when the node has no such rule (or its cells do not grow), for
+ * the uniform-scale path in `alg-snake.ts`.
+ */
+export declare function fitSnakeByRule(node: EngineNode, box: Box, cells: EngineNode[], spacers: EngineNode[], row: boolean): SnakeCellFit | undefined;
+//# sourceMappingURL=snake-rule-fit.d.ts.map

package/dist/diagram/engine/snake-rule-fit.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"snake-rule-fit.d.ts","sourceRoot":"","sources":["../../../diagram/engine/snake-rule-fit.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;GAkBG;AAIH,OAAO,KAAK,EAAE,GAAG,EAAE,UAAU,EAAE,MAAM,eAAe,CAAC;AAQrD,MAAM,WAAW,YAAY;IAC5B,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,IAAI,EAAE,MAAM,CAAC;CACb;AAwFD;;;;GAIG;AACH,wBAAgB,cAAc,CAC7B,IAAI,EAAE,UAAU,EAChB,GAAG,EAAE,GAAG,EACR,KAAK,EAAE,UAAU,EAAE,EACnB,OAAO,EAAE,UAAU,EAAE,EACrB,GAAG,EAAE,OAAO,GACV,YAAY,GAAG,SAAS,CAmC1B"}

package/dist/diagram/engine/style-label.d.ts

@@ -0,0 +1,24 @@
+/**
+ * The presentation style label (`presStyleLbl`) of an engine node: the label
+ * PowerPoint records on the node's presentation point, and the quick-style /
+ * colour-transform label its shape is styled with.
+ *
+ * A layout node's own `@styleLbl` wins, then the nearest ancestor's. Most
+ * built-in layouts declare none on their main shapes, and PowerPoint then
+ * derives one from the point the node presents (checked against every
+ * presentation point of the 3D ground-truth deck's eight layouts):
+ *
+ * - a content point at data depth `d` (the diagram's top-level items are depth
+ *   1) is `node<d>`: Basic Pyramid's `level` is `node1`, Organization Chart's
+ *   second-level `rootText` is `node2`;
+ * - a sibling transition is `sibTrans2D1` (or `sibTrans1D1` for a 1-D
+ *   connector): Basic Process / Basic Cycle arrows and their `connectorText`;
+ * - a parent transition is `parChTrans<dim><d>`, `d` being the child's depth:
+ *   Organization Chart's and Basic Radial's lines are `parChTrans1D2`.
+ *
+ * Labels are capped at 4, the deepest level a quick style defines.
+ */
+import type { EngineNode } from './engine-node.js';
+/** The style label of an engine node's shape, or `undefined` when none applies. */
+export declare function engineStyleLabel(node: EngineNode): string | undefined;
+//# sourceMappingURL=style-label.d.ts.map

package/dist/diagram/engine/style-label.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"style-label.d.ts","sourceRoot":"","sources":["../../../diagram/engine/style-label.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAGH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,eAAe,CAAC;AAyChD,mFAAmF;AACnF,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,UAAU,GAAG,MAAM,GAAG,SAAS,CAOrE"}

package/dist/diagram/engine/text-fit.d.ts

@@ -0,0 +1,61 @@
+/**
+ * Per-node text fitting for the per-point layout engine's output stage
+ * (ECMA-376 Part 1, 21.4.2.x: a `tx` node's `primFontSz` constraint is the
+ * STARTING size, and a `dgm:rule type="primFontSz"` lets PowerPoint shrink
+ * it, down to the rule's `val`, until the node's text fits its own text
+ * box). Equalisation across nodes (`op="equ"` groups, `op="lte"` links)
+ * happens one level up, in `font-groups.ts`; this module answers the
+ * single-node question "what is the largest whole point this node's text
+ * fits at?".
+ *
+ * All arithmetic is in POINTS, matching the engine's internal coordinate
+ * space. The paragraph model itself (line pitch, folded descendants,
+ * spacing) lives in `text-measure.ts`; this module supplies the node-level
+ * inputs: the preset's text rectangle, the margins and the size bounds.
+ */
+import type { EngineNode } from './engine-node.js';
+import type { NodeText, TextMetrics } from './text-measure.js';
+export type { NodeText, TextMetrics } from './text-measure.js';
+export { sizingVariable } from './layout-font.js';
+/** Starting size (points) for a text node with no `primFontSz` constraint. */
+export declare const DEFAULT_START_PT = 65;
+/** Another node's current font size, for a margin that references it (undefined: use the fitted node's own). */
+export type FontSizeOf = (node: EngineNode) => number | undefined;
+/** Whole-point bounds a node's size may take before any cross-node equalisation. */
+export interface FontBoundsPt {
+    start: number;
+    floor: number;
+}
+/**
+ * The node's starting size (its `primFontSz` constraint value, capped by any
+ * literal `op="lte"` bound) and its shrink floor (the lowest `primFontSz`
+ * rule reaching it). With no rule, PowerPoint does not shrink the text at
+ * all, so the floor is the start itself.
+ */
+export declare function nodeFontBounds(node: EngineNode): FontBoundsPt;
+export declare function nodeTextBox(node: EngineNode): {
+    w: number;
+    h: number;
+} | undefined;
+/** {@link nodeTextBox} for a `w` x `h` footprint (a size the node is being grown to). */
+export declare function textBoxAt(node: EngineNode, boxW: number, boxH: number): {
+    w: number;
+    h: number;
+};
+type MarginSide = 'lMarg' | 'rMarg' | 'tMarg' | 'bMarg';
+/**
+ * Per-side margins (points) at candidate size `sizePt`: a margin referencing
+ * a font size (`refType="primFontSz"`, or `"secFontSz"` on a node whose text
+ * follows its `secFontSz`) scales with that font (`fact x size`, where a
+ * reference to ANOTHER node reads that node's size via `refSize`: "Circle
+ * Arrow Process"'s 18pt child boxes inset `0.05 x` their 23pt parent's
+ * size, 1.15pt, not 0.9pt), a literal one is
+ * fixed, and a node declaring none gets PowerPoint's default proportional
+ * inset.
+ */
+export declare function nodeMarginsPt(node: EngineNode, sizePt: number, refSize?: FontSizeOf): Record<MarginSide, number>;
+/** Whether `text` fits `node`'s text box at whole-point size `sizePt`. */
+export declare function textFitsAt(node: EngineNode, text: NodeText, sizePt: number, metrics: TextMetrics, refSize?: FontSizeOf): boolean;
+/** Largest whole point in `[bounds.floor, bounds.start]` at which `text` fits (the floor when nothing does). */
+export declare function fitNodeFontPt(node: EngineNode, text: NodeText, bounds: FontBoundsPt, metrics: TextMetrics, refSize?: FontSizeOf): number;
+//# sourceMappingURL=text-fit.d.ts.map

package/dist/diagram/engine/text-fit.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"text-fit.d.ts","sourceRoot":"","sources":["../../../diagram/engine/text-fit.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AAIH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,eAAe,CAAC;AAGhD,OAAO,KAAK,EAAE,QAAQ,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAC;AAG5D,YAAY,EAAE,QAAQ,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAC;AAC5D,OAAO,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAE/C,8EAA8E;AAC9E,eAAO,MAAM,gBAAgB,KAAK,CAAC;AAgBnC,gHAAgH;AAChH,MAAM,MAAM,UAAU,GAAG,CAAC,IAAI,EAAE,UAAU,KAAK,MAAM,GAAG,SAAS,CAAC;AAElE,oFAAoF;AACpF,MAAM,WAAW,YAAY;IAC5B,KAAK,EAAE,MAAM,CAAC;IACd,KAAK,EAAE,MAAM,CAAC;CACd;AA2BD;;;;;GAKG;AACH,wBAAgB,cAAc,CAAC,IAAI,EAAE,UAAU,GAAG,YAAY,CAmB7D;AAkBD,wBAAgB,WAAW,CAAC,IAAI,EAAE,UAAU,GAAG;IAAE,CAAC,EAAE,MAAM,CAAC;IAAC,CAAC,EAAE,MAAM,CAAA;CAAE,GAAG,SAAS,CAYlF;AAED,yFAAyF;AACzF,wBAAgB,SAAS,CAAC,IAAI,EAAE,UAAU,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,GAAG;IAAE,CAAC,EAAE,MAAM,CAAC;IAAC,CAAC,EAAE,MAAM,CAAA;CAAE,CAchG;AAED,KAAK,UAAU,GAAG,OAAO,GAAG,OAAO,GAAG,OAAO,GAAG,OAAO,CAAC;AAGxD;;;;;;;;;GASG;AACH,wBAAgB,aAAa,CAC5B,IAAI,EAAE,UAAU,EAChB,MAAM,EAAE,MAAM,EACd,OAAO,CAAC,EAAE,UAAU,GAClB,MAAM,CAAC,UAAU,EAAE,MAAM,CAAC,CAgB5B;AAED,0EAA0E;AAC1E,wBAAgB,UAAU,CACzB,IAAI,EAAE,UAAU,EAChB,IAAI,EAAE,QAAQ,EACd,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,WAAW,EACpB,OAAO,CAAC,EAAE,UAAU,GAClB,OAAO,CAYT;AAED,gHAAgH;AAChH,wBAAgB,aAAa,CAC5B,IAAI,EAAE,UAAU,EAChB,IAAI,EAAE,QAAQ,EACd,MAAM,EAAE,YAAY,EACpB,OAAO,EAAE,WAAW,EACpB,OAAO,CAAC,EAAE,UAAU,GAClB,MAAM,CAOR"}

package/dist/diagram/engine/text-grow.d.ts

@@ -0,0 +1,33 @@
+/**
+ * Text-driven node sizing (ECMA-376 Part 1, 21.4.2.x `dgm:rule`): a `tx`
+ * node whose rule list lets its height grow (`<dgm:rule type="h"
+ * val="INF"/>`) is as tall as its constraints make it OR as its text needs
+ * at the size the layout is being built around, whichever is larger.
+ * "Vertical Bullet List"'s `parentText` is `0.52 x primFontSz` tall until a
+ * wrapped label needs more; "Vertical Box List"'s `childText` grows past its
+ * `0.7 x primFontSz` for a child line under its `1.64 x primFontSz` top
+ * margin.
+ *
+ * The grown height is the text's measured height (`text-measure.ts`) plus
+ * its margins, inside the preset's own text rectangle, plus a small
+ * `GROW_SLACK_EM`: across the cached drawings a grown box is 0.03-0.06em
+ * taller than the fitted text's own block (single lines at 30, 35 and 46pt:
+ * 0.043, 0.040, 0.040em; two lines at 40pt 0.033em; two bullet paragraphs at
+ * 27pt 0.040em).
+ *
+ * Only runs inside a font search (the node's font must be known); see
+ * `font-search.ts`.
+ */
+import type { EngineNode } from './engine-node.js';
+import type { Size } from './preferred-size.js';
+export declare const GROW_SLACK_EM = 0.04;
+/** Whether a rule reaching `node` lets its `type` grow without bound. */
+export declare function canGrow(node: EngineNode, type: 'w' | 'h'): boolean;
+/**
+ * The height `node`'s text needs at width `w`, or `undefined` when its font
+ * is not known yet, it has no text, or a word is wider than its line.
+ */
+export declare function textNeedHeight(node: EngineNode, w: number, h: number): number | undefined;
+/** `size` grown to fit `node`'s text where its rules allow (see module doc). */
+export declare function grownSize(node: EngineNode, size: Size): Size;
+//# sourceMappingURL=text-grow.d.ts.map

package/dist/diagram/engine/text-grow.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"text-grow.d.ts","sourceRoot":"","sources":["../../../diagram/engine/text-grow.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAGH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,eAAe,CAAC;AAEhD,OAAO,KAAK,EAAE,IAAI,EAAE,MAAM,kBAAkB,CAAC;AAI7C,eAAO,MAAM,aAAa,OAAO,CAAC;AAElC,yEAAyE;AACzE,wBAAgB,OAAO,CAAC,IAAI,EAAE,UAAU,EAAE,IAAI,EAAE,GAAG,GAAG,GAAG,GAAG,OAAO,CAqBlE;AAED;;;GAGG;AACH,wBAAgB,cAAc,CAAC,IAAI,EAAE,UAAU,EAAE,CAAC,EAAE,MAAM,EAAE,CAAC,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS,CA8BzF;AAED,gFAAgF;AAChF,wBAAgB,SAAS,CAAC,IAAI,EAAE,UAAU,EAAE,IAAI,EAAE,IAAI,GAAG,IAAI,CAS5D"}

package/dist/diagram/engine/text-measure.d.ts

@@ -0,0 +1,77 @@
+/**
+ * Paragraph measurement for the per-point engine's text fit: does a node's
+ * text, at a candidate whole-point size, fit a given width and height?
+ *
+ * The model, each part measured against the gallery corpus's cached
+ * drawings or PowerPoint itself (COM):
+ *
+ * - Glyph advances come from the COM-measured tables
+ *   (`font-advance-widths.generated.ts`), greedy word-wrapped per paragraph
+ *   (`smartart-text-wrap-fit.ts`), in CSS pixels so each advance snaps to
+ *   PowerPoint's 1/6-px hinting grid.
+ * - Line pitch: `lnSpc 90%` of the font's own line height, plus a fixed
+ *   extra per text block (`smartart-line-pitch.ts` has the COM numbers).
+ * - A folded descendant renders at `round(0.78 x size)` in a hanging-indented
+ *   column (`descendantIndentPt`); paragraphs are separated by their
+ *   `spcAft` (35% after the node's own, 15% after a folded descendant, 20% in
+ *   a descendant-only box), never after the last paragraph.
+ */
+import type { FontAdvanceTable } from '../../text/font-metrics/font-advance-widths.generated';
+/** A folded descendant paragraph's size relative to the node's own text (cached corpus: 54/56 pairs). */
+export declare const DESCENDANT_FONT_SCALE = 0.78;
+/**
+ * The text one rendered node shows, as PowerPoint lays it out. Paragraph
+ * levels follow the `tx` algorithm's parameters (ECMA-376 21.4.2.x):
+ * `stBulletLvl` is the first (1-based) level drawn as a bullet, default 2,
+ * `0` meaning none; an anchored node's own paragraph is level 1 and every
+ * folded descendant level 2, a descendant-only box's paragraphs are all
+ * level 1. `lnSpAfParP`/`lnSpAfChP` are the percent spacing after a plain
+ * and a bullet paragraph (defaults 35 and 15). Cached corpus: "Basic Block
+ * List" (defaults: bullets at 0.78x after a 35% gap), "Vertical Bullet
+ * List"'s `childText` (`stBulletLvl=1`, `lnSpAfChP=20`: every paragraph a
+ * bullet), "Descending Block List"'s `childText` (default: level-1 plain
+ * paragraphs, no indent), "Vertical Action List" (`stBulletLvl=0`).
+ */
+export interface NodeText {
+    /** The node's own (level 1) paragraph, when its `presOf` includes the point itself. */
+    own?: string;
+    descendants: string[];
+    /** `tx` `stBulletLvl` (default 2; 0 = no bullets). */
+    bulletLevel?: number | undefined;
+    /** Percent `spcAft` after a plain / a bullet paragraph. */
+    spaceAfterParent?: number | undefined;
+    spaceAfterChild?: number | undefined;
+    /**
+     * `secFontSz` as a multiple of `primFontSz`: 0.78 by default (cached
+     * corpus, 54 of 56 folded pairs), 1 where the node declares
+     * `primFontSz refType="secFontSz"` and is sized by `secFontSz` itself.
+     */
+    secondaryScale?: number | undefined;
+}
+/** Font metrics a fit runs against. */
+export interface TextMetrics {
+    table: FontAdvanceTable;
+    /** Line height in em before the 90% SmartArt line spacing. */
+    lineEm: number;
+}
+/** Metrics for text measured with `table` (see `smartart-line-pitch.ts` for the line height). */
+export declare function textMetricsFor(table: FontAdvanceTable): TextMetrics;
+/**
+ * Bullet paragraphs and every folded descendant render at the node's
+ * `secFontSz`, plain level-1 paragraphs at its `primFontSz`: "Gear"'s child
+ * box (`stBulletLvl=1`, equalised with the gear at 17pt) draws its bullets
+ * at 13pt, "Circle Arrow Process"'s bulleted children 18pt under a 23pt cap,
+ * while "Descending Block List"'s unbulleted child text stays at 33pt.
+ */
+export declare function paragraphSizesPt(text: NodeText, sizePt: number): {
+    first: number;
+    secondary: number;
+};
+/**
+ * The height (points) `text` takes at `sizePt` wrapped to `availW` points,
+ * or `undefined` when a word is wider than the line (no wrap can fit it).
+ */
+export declare function paragraphsHeight(text: NodeText, sizePt: number, availW: number, metrics: TextMetrics): number | undefined;
+/** Whether `text` at `sizePt` fits `availW` x `availH` points (net of margins). */
+export declare function paragraphsFit(text: NodeText, sizePt: number, availW: number, availH: number, metrics: TextMetrics): boolean;
+//# sourceMappingURL=text-measure.d.ts.map

package/dist/diagram/engine/text-measure.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"text-measure.d.ts","sourceRoot":"","sources":["../../../diagram/engine/text-measure.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,uDAAuD,CAAC;AAW9F,yGAAyG;AACzG,eAAO,MAAM,qBAAqB,OAAO,CAAC;AAE1C;;;;;;;;;;;;GAYG;AACH,MAAM,WAAW,QAAQ;IACxB,uFAAuF;IACvF,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,EAAE,CAAC;IACtB,sDAAsD;IACtD,WAAW,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACjC,2DAA2D;IAC3D,gBAAgB,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACtC,eAAe,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACrC;;;;OAIG;IACH,cAAc,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;CACpC;AAMD,uCAAuC;AACvC,MAAM,WAAW,WAAW;IAC3B,KAAK,EAAE,gBAAgB,CAAC;IACxB,8DAA8D;IAC9D,MAAM,EAAE,MAAM,CAAC;CACf;AAED,iGAAiG;AACjG,wBAAgB,cAAc,CAAC,KAAK,EAAE,gBAAgB,GAAG,WAAW,CAEnE;AASD;;;;;;GAMG;AACH,wBAAgB,gBAAgB,CAC/B,IAAI,EAAE,QAAQ,EACd,MAAM,EAAE,MAAM,GACZ;IAAE,KAAK,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,MAAM,CAAA;CAAE,CAMtC;AAuBD;;;GAGG;AACH,wBAAgB,gBAAgB,CAC/B,IAAI,EAAE,QAAQ,EACd,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,WAAW,GAClB,MAAM,GAAG,SAAS,CAkBpB;AAED,mFAAmF;AACnF,wBAAgB,aAAa,CAC5B,IAAI,EAAE,QAAQ,EACd,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,OAAO,EAAE,WAAW,GAClB,OAAO,CAGT"}

package/dist/diagram/hierarchy/index.d.ts

@@ -0,0 +1,5 @@
+export { arrangeHierarchy } from './smartart-layout-interpreter-hierarchy.js';
+export { resolveHierarchyDispatchChAlign, resolveHierarchyDispatchLinDir, resolveHierarchyRootAlign, } from './smartart-hierarchy-dispatch-lindir.js';
+export { resolveHierarchyGenerationTemplates, type HierarchyGenerationTemplate, type HierarchyGenerationTemplates, type HierarchyRootTemplate, } from './smartart-hierarchy-generation-templates.js';
+export { tailedHierarchyDeclaresChAlign } from './smartart-hierarchy-tailed-transpose.js';
+//# sourceMappingURL=index.d.ts.map

package/dist/diagram/hierarchy/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/index.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,gBAAgB,EAAE,MAAM,yCAAyC,CAAC;AAC3E,OAAO,EACN,+BAA+B,EAC/B,8BAA8B,EAC9B,yBAAyB,GACzB,MAAM,sCAAsC,CAAC;AAC9C,OAAO,EACN,mCAAmC,EACnC,KAAK,2BAA2B,EAChC,KAAK,4BAA4B,EACjC,KAAK,qBAAqB,GAC1B,MAAM,2CAA2C,CAAC;AACnD,OAAO,EAAE,8BAA8B,EAAE,MAAM,uCAAuC,CAAC"}

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

@@ -0,0 +1,65 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy fan/generation axis pitch.
+ *
+ * Split out of `smartart-layout-interpreter-hierarchy.ts` (the file-size
+ * budget): the `cellW`/`cellH` derivation itself (`compositeFanPitch`/
+ * `computeAxisPitch` wiring), alongside the doc comments explaining WHY the
+ * two axes use genuinely different models. `cellW`/`cellH` as a naive
+ * `dimension/count` split distributes leftover space EQUALLY on both ends
+ * ("space-around"); real PowerPoint treats the two axes DIFFERENTLY instead:
+ * generation axis - fixed leading margin (top), trailing edge flush against
+ * the far box edge; fan axis - CENTRED (no margin, a fixed `sibSp` gap,
+ * slack split evenly). `pitch` plugs in as `cellW`/`cellH`; `shift` corrects
+ * the position afterwards via `translateResult`.
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { HierarchyHangShape } from './smartart-hierarchy-hang-depth.js';
+import type { HierarchyOrientation } from './smartart-hierarchy-orientation.js';
+import type { AxisPitch } from './smartart-hierarchy-pitch.js';
+import type { BoundingBox } from '../layout/smartart-layout-types.js';
+export interface HierarchyAxisPitches {
+    xPitch: AxisPitch;
+    yPitch: AxisPitch;
+}
+/**
+ * Resolve the fan-axis (`x`) and generation-axis (`y`) pitch/shift together.
+ *
+ * A TRANSPOSED hierarchy needs no GENERATION-axis leading margin (its item
+ * size already fills the box edge-to-edge, so a nonzero margin double-counts
+ * space that was never there - measured regression:
+ * `horizontal-hierarchy--flat3.pptx`'s root rendered 61px off the box's left
+ * edge instead of flush). `tailed` mode: a pitch fill against the WHOLE
+ * `effectiveBox` assumes `totalLeaves`/`depth` items genuinely span it -
+ * true for `std` (every generation fans), false here (only
+ * `fannedGenerations` rows fan; the REST is reserved for the hanging tail
+ * via its own separate `vGap`/indent mechanism, already sized via
+ * `fitItemBox`'s own `maxHangDepth` term). Filling the WHOLE box using only
+ * the fanned count double-reserves that space as one giant inter-row gap
+ * (COM-verified regression: `organization-chart--hier5.pptx`'s own
+ * generation-1 row rendered ~200px too far down) - scoped to just the
+ * FAN-share instead. `fanHeight` reserves `maxHangRows` rows (the tallest
+ * hanging branch's own ROW count, not `maxHangDepth`'s hop count - see
+ * `HierarchyHangShape.maxHangRows`'s doc comment in `smartart-hierarchy-
+ * hang-depth.ts`), matching `fitItemBox`'s own height-axis term.
+ *
+ * The FAN axis is CENTRED (`compositeFanPitch`), not a leading-margin/
+ * trailing-flush pack (`compositeWidthFactor` is `undefined` for
+ * `tailedPitch` mode: org-chart's own `rootText1` is never shrunk relative
+ * to its own composite wrapper - see `smartart-hierarchy-composite-
+ * child.ts`). Used UNCONDITIONALLY for `tailedPitch` too: empirically
+ * byte-identical to the OLD `computeAxisPitch(fanWidth, 0, boxW,
+ * totalLeaves)` fill-exactly formula across all 7 org-chart-family fixtures
+ * - a real equivalence, not a guess; the remaining org-chart residual is
+ * therefore NOT a fan-axis bug, see `smartart-track-r-successor.md`'s own
+ * SESSION 9.
+ *
+ * `orientation.generationGapRatio` (COM-verified fixed ratio - see
+ * `smartart-hierarchy-generation-gap.ts`) replaces the OLD "solve to fill
+ * the box" GENERATION-axis gap ONLY for plain, non-transposed, non-tailed
+ * "Hierarchy": `transposed`/`tailed` are unchanged, not yet re-measured
+ * against this same fixed-vs-solved distinction (see `smartart-track-r-
+ * successor.md`'s SESSION 10).
+ */
+export declare function computeHierarchyAxisPitches(effectiveBox: BoundingBox, orientation: HierarchyOrientation, boxW: number, boxH: number, totalLeaves: number, depth: number, hangShape: HierarchyHangShape, tailedPitch: boolean, cascadeReserveOffsetPx?: number): HierarchyAxisPitches;
+//# sourceMappingURL=smartart-hierarchy-axis-pitch.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-axis-pitch.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-axis-pitch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAEH,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AAC1E,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,kCAAkC,CAAC;AAC7E,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,4BAA4B,CAAC;AAO5D,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,iCAAiC,CAAC;AAEnE,MAAM,WAAW,oBAAoB;IACpC,MAAM,EAAE,SAAS,CAAC;IAClB,MAAM,EAAE,SAAS,CAAC;CAClB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AACH,wBAAgB,2BAA2B,CAC1C,YAAY,EAAE,WAAW,EACzB,WAAW,EAAE,oBAAoB,EACjC,IAAI,EAAE,MAAM,EACZ,IAAI,EAAE,MAAM,EACZ,WAAW,EAAE,MAAM,EACnB,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,kBAAkB,EAC7B,WAAW,EAAE,OAAO,EACpB,sBAAsB,CAAC,EAAE,MAAM,GAC7B,oBAAoB,CAwKtB"}

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

@@ -0,0 +1,68 @@
+/**
+ * SmartArt DiagramML interpreter - re-derive `HierarchyOrientation`'s
+ * axis-relative fields for the "centred-on-children, axis-swapped"
+ * construct (`smartart-hierarchy-centered-fan-axis.ts`).
+ *
+ * `resolveHierarchyOrientation`'s STD branch resolves `aspectRatio` as a
+ * plain real-space "h:w" ratio, and `generationGapRatio`/
+ * `compositeGenerationGapRatio`/`hangHeightRatio` by searching for a `sp`
+ * constraint declared relative to the item's own HEIGHT (`'h'`) - both
+ * correct for the classic (fan=X, generation=Y) convention that branch
+ * assumes. `arrangeHierarchy`'s `axisSwapped` mode runs the SAME
+ * std-branch-sized algorithm but through the SAME `effectiveBox`-swap +
+ * `transposeResult` post-pass `orientation.transposed` already uses for the
+ * unrelated "Horizontal Hierarchy" family (see that field's own module doc
+ * comment) - which means the item's LOGICAL width (pre-swap) becomes its
+ * FINAL height, and vice versa. Two fields need re-deriving for this reason:
+ *
+ *   - `aspectRatio` must be INVERTED (mirroring
+ *     `resolveHierarchyOrientation`'s own transposed-branch `1 / hToW`): the
+ *     STD branch's `h = aspectRatio * w` becomes, after the swap,
+ *     `w_final = h_logical = aspectRatio * w_logical = aspectRatio *
+ *     h_final` - backwards. Feeding `1 / aspectRatio` into the LOGICAL solve
+ *     restores the intended real-space relationship after the swap.
+ *   - `generationGapRatio`/`compositeGenerationGapRatio`/`hangHeightRatio`
+ *     search for a `sp` constraint on the item's STACKING axis - the STD
+ *     branch always searches `'h'` (its own generation axis, in real
+ *     terms), but `horizontal-labeled-hierarchy--hier5.pptx`'s own layout
+ *     declares this gap relative to `'w'` instead (`<dgm:constr type="sp"
+ *     for="des" refType="w" refFor="des" refForName="level1Shape"
+ *     fact="0.4"/>`, on an ancestor `mainComposite` wrapper) - because ITS
+ *     generation axis's real-space extent IS the item's width (the whole
+ *     point of the construct). Re-resolved here with stacking axis `'w'`
+ *     via the SAME general `resolveGenerationGapRatio` (including its own
+ *     ancestor-index fallback, `smartart-hierarchy-generation-gap.ts`), not
+ *     a per-layout special case.
+ *
+ * `marginXRatio`/`marginYRatio`/`sibSpRatio`/`compositeWidthFactor`/
+ * `compositeHeightFactor`/`cardOffsetXRatio`/`compositeChainHeightRatio` need
+ * NO adjustment: `fitItemBox`'s own "X" parameter role is always the FAN
+ * axis regardless of which real-space axis that maps to (see
+ * `smartart-layout-interpreter-hierarchy.ts`'s own module doc comment), and
+ * `sibSpRatio`/the composite factors are plain declared ratios, not tied to
+ * a specific real `w`/`h` label.
+ *
+ * No `compositeChild`-aware correction (unlike `resolveHierarchyOrientation`'s
+ * own calls): no corpus fixture reaching this construct declares a
+ * `composite` wrapper around its item template yet (`horizontal-labeled-
+ * hierarchy--hier5.pptx`'s own `level1Shape`/`level2Shape` nest directly
+ * under their `hierRoot`) - a successor adding one can re-derive
+ * `compositeChild` the same way `resolveHierarchyOrientation` does and
+ * thread it through, generalising this function rather than special-casing.
+ *
+ * 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 { HierarchyOrientation } from './smartart-hierarchy-orientation-types.js';
+/**
+ * Adjust `orientation` (already resolved by `resolveHierarchyOrientation`'s
+ * STD branch) for the axis-swapped construct - see the module doc comment.
+ * Returns `orientation` unchanged when it is already `transposed` (the
+ * "Horizontal Hierarchy" branch resolves its own ratios for its own later
+ * swap; this construct's own gate, `hierarchyDeclaresCenteredFanAxisSwap`,
+ * never fires for that family anyway, but this keeps the function safe to
+ * call unconditionally).
+ */
+export declare function adjustOrientationForAxisSwap(orientation: HierarchyOrientation, algorithmNode: DiagramLayoutNode | undefined, index: ConstraintIndex, itemShapeName: string | undefined): HierarchyOrientation;
+//# sourceMappingURL=smartart-hierarchy-axis-swap-orientation.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-axis-swap-orientation.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-axis-swap-orientation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqDG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,UAAU,CAAC;AAClD,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAE5E,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,wCAAwC,CAAC;AAEnF;;;;;;;;GAQG;AACH,wBAAgB,4BAA4B,CAC3C,WAAW,EAAE,oBAAoB,EACjC,aAAa,EAAE,iBAAiB,GAAG,SAAS,EAC5C,KAAK,EAAE,eAAe,EACtB,aAAa,EAAE,MAAM,GAAG,SAAS,GAC/B,oBAAoB,CAuBtB"}

package/dist/diagram/hierarchy/smartart-hierarchy-branch-mode.d.ts

@@ -0,0 +1,54 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy `hierBranch`/`linDir`/`chPref`
+ * mode resolution.
+ *
+ * Split out of `smartart-layout-interpreter-hierarchy.ts` (the file-size
+ * budget): pure decision helpers deciding WHICH placement mode
+ * (`std`/`tailed`/`hanging`), tail direction, and per-row size
+ * `arrangeHierarchy` should use, all read from `presLayoutVars`/`linDir` -
+ * see that module's own doc comment for the full derivation and the
+ * genuine-fixture measurements behind each rule.
+ *
+ * Pure decision logic; no framework code, no DOM.
+ */
+import type { DiagramPresLayoutVars } from '../model/index.js';
+import type { HangDirection } from './smartart-hierarchy-hanging.js';
+/**
+ * `std`: literal ECMA-376 standard branch, no hanging tail anywhere (every
+ *        generation fans). Reachable only from an explicit hand-built
+ *        `hierarchyBranch: 'std'` - see the module doc comment.
+ * `tailed`: the root's own children fan out (same as `std`), but every
+ *        deeper generation hangs. Selected by `init`/`hang`/`l`/`r`.
+ * `hanging`: the WHOLE tree hangs, including the root's own children. Only
+ *        reached via the `linDir` fallback (no `presLayoutVars.hierBranch` at
+ *        all) - see the module doc comment.
+ */
+export type BranchMode = 'std' | 'tailed' | 'hanging';
+export declare function branchMode(presLayoutVars: DiagramPresLayoutVars | undefined, linDir: string | undefined): BranchMode;
+/**
+ * Tail direction for `tailed` mode (the root's own children are unaffected).
+ *
+ * `l`/`hang`/`r`/`init` all measure identically as 'right' against genuine
+ * PowerPoint output - see `smartart-layout-interpreter-hierarchy.ts`'s module
+ * doc comment and `HIER_TAIL_OFFSET_RATIO` in `smartart-hierarchy-shared.ts`.
+ * Kept as a function (rather than a bare constant) so a future genuine-fixture
+ * measurement that DOES find a real per-branch difference has a single place
+ * to encode it.
+ */
+export declare function tailDirection(_presLayoutVars: DiagramPresLayoutVars | undefined): HangDirection;
+/**
+ * Direction for `hanging` mode, reached ONLY via the `linDir` fallback (no
+ * `presLayoutVars.hierBranch` at all): `fromR` grows the tree leftward
+ * (children lead away from the right edge), `fromL` grows it rightward.
+ */
+export declare function linDirHangDirection(linDir: string | undefined): HangDirection;
+/**
+ * Resolve `chPref`/`chMax` into one per-row size (`Infinity` = unbounded).
+ * `<= 1` is treated as unbounded: `hierarchy--hier8.pptx` declares `chPref
+ * val="1"` (root-scoped, not scoped to the generation that fans 5-wide two
+ * levels down) yet cached output fans all 5 in ONE row, not five 1-item
+ * rows - a literal "wrap to 1" would be worse than a hanging column, which
+ * `std` never selects. Every existing wrapping unit test uses `>= 2`.
+ */
+export declare function resolveRowSize(presLayoutVars: DiagramPresLayoutVars | undefined): number;
+//# sourceMappingURL=smartart-hierarchy-branch-mode.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-branch-mode.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-branch-mode.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-branch-mode.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,8BAA8B,CAAC;AAElE;;;;;;;;;GASG;AACH,MAAM,MAAM,UAAU,GAAG,KAAK,GAAG,QAAQ,GAAG,SAAS,CAAC;AAoBtD,wBAAgB,UAAU,CACzB,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,MAAM,EAAE,MAAM,GAAG,SAAS,GACxB,UAAU,CASZ;AAED;;;;;;;;;GASG;AACH,wBAAgB,aAAa,CAAC,eAAe,EAAE,qBAAqB,GAAG,SAAS,GAAG,aAAa,CAE/F;AAED;;;;GAIG;AACH,wBAAgB,mBAAmB,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,GAAG,aAAa,CAE7E;AAED;;;;;;;GAOG;AACH,wBAAgB,cAAc,CAAC,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAAG,MAAM,CAUxF"}

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

@@ -0,0 +1,58 @@
+/**
+ * SmartArt DiagramML interpreter - the declared "cascade" hierarchy shape
+ * (SESSION 28).
+ *
+ * Split out of `smartart-layout-interpreter-hierarchy.ts` (the file-size
+ * budget): `half-circle-organization-chart`/`name-and-title-organization-
+ * chart` declare a `composite` wrapper whose own height genuinely differs
+ * from the rendered item's (`orientation.compositeHeightFactor`, `smartart-
+ * hierarchy-orientation.ts`) AND a `sp` (generation gap) relative to that
+ * SAME composite width - together, the layout's own declared constraints
+ * describe an EVEN, box-filling cascade across every generation (root,
+ * fanned children, and the row past that), not a fanned-row-plus-
+ * independent-hanging-tail shape: local-coordinate analysis of `half-circle-
+ * organization-chart--hier5.pptx`'s own cached `dsp:sp` geometry (867x533
+ * box, `Node One`/`Two`+`Three`/`Four`+`Five`) shows THREE rows an equal
+ * ~197px pitch apart, spanning almost the full box height with zero
+ * leading/trailing margin - not the smaller, independently-sized
+ * `HANG_HEIGHT_RATIO` gap `placeAt`'s `hangingPlacer` branch applies to
+ * every other `tailed` layout, and a FIXED `alignOff`-driven rightward
+ * nudge (`dgm:constr type="alignOff" val="0.65"`, declared identically on
+ * every `hierRoot` branch past the root itself) for the row past the fan,
+ * not the mirrored per-branch-direction indent `HIER_TAIL_OFFSET_RATIO`
+ * models for every other `tailed` layout.
+ *
+ * Detected structurally (`compositeHeightFactor` only exists for this
+ * declared shape, corpus-checked to be unique to these two fixtures), not by
+ * layout name: reusing the SAME `cellH` pitch for the row past the fan
+ * (instead of routing it through `hangingPlacer`), plus the fixed rightward
+ * nudge, reproduces `half-circle-organization-chart--hier5.pptx`'s own
+ * geometry to within measurement rounding (full corpus regen:
+ * `maxDeltaFraction` 0.0844 -> 0.0646, zero regressions elsewhere -
+ * `name-and-title-organization-chart--hier5.pptx` itself never actually
+ * engages `heightFactor`/this plan, see `smartart-hierarchy-composite-
+ * child.ts`'s own `hasCompoundTextRole` guard).
+ *
+ * Pure geometry/decision logic; no framework code, no DOM.
+ */
+import type { HierarchyHangShape } from './smartart-hierarchy-hang-depth.js';
+import type { HierarchyOrientation } from './smartart-hierarchy-orientation.js';
+export interface CascadePlan {
+    /** True only for the declared cascade shape - every other layout is unaffected. */
+    active: boolean;
+    /** `depth` for `computeHierarchyAxisPitches`: the row past the fan counts as its own generation when `active`. */
+    pitchDepth: number;
+    /** `hangShape` for `computeHierarchyAxisPitches`: no separate hang-row reservation when `active` (the row past the fan is a NORMAL pitch row). */
+    pitchHangShape: HierarchyHangShape;
+    /** `StandardOptions.cascadeOffsetX` - `undefined` when not `active`. */
+    cascadeOffsetX?: {
+        fromLevel: number;
+        offsetPx: number;
+    };
+}
+/**
+ * Resolve whether the declared cascade shape applies, and every value its
+ * two call sites (`computeHierarchyAxisPitches`, `StandardOptions`) need.
+ */
+export declare function resolveCascadePlan(mode: 'std' | 'tailed' | 'hanging', orientation: HierarchyOrientation, depth: number, hangShape: HierarchyHangShape, boxW: number): CascadePlan;
+//# sourceMappingURL=smartart-hierarchy-cascade.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-cascade.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-cascade.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoCG;AAEH,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,iCAAiC,CAAC;AAC1E,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,kCAAkC,CAAC;AAK7E,MAAM,WAAW,WAAW;IAC3B,mFAAmF;IACnF,MAAM,EAAE,OAAO,CAAC;IAChB,kHAAkH;IAClH,UAAU,EAAE,MAAM,CAAC;IACnB,kJAAkJ;IAClJ,cAAc,EAAE,kBAAkB,CAAC;IACnC,wEAAwE;IACxE,cAAc,CAAC,EAAE;QAAE,SAAS,EAAE,MAAM,CAAC;QAAC,QAAQ,EAAE,MAAM,CAAA;KAAE,CAAC;CACzD;AAED;;;GAGG;AACH,wBAAgB,kBAAkB,CACjC,IAAI,EAAE,KAAK,GAAG,QAAQ,GAAG,SAAS,EAClC,WAAW,EAAE,oBAAoB,EACjC,KAAK,EAAE,MAAM,EACb,SAAS,EAAE,kBAAkB,EAC7B,IAAI,EAAE,MAAM,GACV,WAAW,CAcb"}

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

@@ -0,0 +1,63 @@
+/**
+ * SmartArt DiagramML interpreter - the declared "centred-on-children,
+ * axis-swapped" hierarchy arrangement mode (`hierAlign="lCtrCh"/"rCtrCh"`).
+ *
+ * `horizontal-labeled-hierarchy--hier5.pptx` (and any layoutDef sharing the
+ * same structural shape) declares a REAL fanned hierarchy tree - the SAME
+ * `std`-mode fan/generation MACHINERY as the plain "Hierarchy" family (a
+ * parent centred over the span of its own children - `placeStandardTree`'s
+ * own existing default behaviour, `cx = (xOffset + spanW / 2) * cellW`) -
+ * but rendered with the fan and generation axes SWAPPED: generations run
+ * left-to-right (not top-to-bottom), and each generation's own siblings fan
+ * top-to-bottom (not side-to-side).
+ *
+ * COM-verified against the cached drawing: three GENERATION columns at
+ * x=53/372/691 (an 867-wide box), each generation's own siblings fanned
+ * along y (a 533-tall box) - `Node One` (the sole gen-0 root) sits
+ * vertically CENTRED on the y-span its two gen-1 children (`Node Two`/
+ * `Node Three`, y=264/395) occupy, exactly matching `placeStandardTree`'s
+ * own "parent centred over its fan" behaviour, rotated 90 degrees. Before
+ * this module existed, the interpreter placed this tree with the un-swapped
+ * axes (generations stacking Y, siblings fanning X) - a structurally
+ * coherent but WRONG tree shape, `maxDeltaFraction` 0.4787.
+ *
+ * Distinct from BOTH the plain fanning family (no `hierAlign` declared at
+ * all - X is already the fan axis, no swap needed) and the "Horizontal
+ * Hierarchy" family (`resolveHierarchyOrientation`'s own `transposed`
+ * branch, triggered by an UNSCOPED `sibSp refType="h"` - a genuinely
+ * different declared shape whose own margin/aspect ratios are calibrated
+ * for ITS OWN simple, directly-declared `w`/`h`/`sibSp` constraint set, not
+ * this family's font-driven, autofit item sizing): this construct keeps the
+ * STD branch's own ratio/margin resolution entirely unchanged (its own item
+ * SIZE is already close to correct under that resolution, measured: a
+ * 3.2%/3.7% w/h residual, versus 38-48% x/y residuals from the wrong axis
+ * assignment alone) and swaps ONLY the two axes' final placement, via the
+ * SAME `effectiveBox`-swap + `transposeResult` post-pass `arrangeHierarchy`
+ * already runs for `orientation.transposed`, for the unrelated reason above.
+ *
+ * `hierarchyDeclaresCenteredFanAxisSwap` is the gate: narrow and
+ * structural, not a per-layout name check, mirroring `resolveCornerHangPlan`'s
+ * own two-part discipline (`smartart-hierarchy-corner-plan.ts`):
+ *
+ *   1. the tree's own root item declares `hierAlign="lCtrCh"`/`"rCtrCh"`
+ *      (never `tL`/`tR` - the corner-anchored single-column construct that
+ *      module owns - or absent, the plain fanning family, already correctly
+ *      on the X-fan axis with no swap needed);
+ *   2. root's own nested `hierChild` (the "children of root" generation)
+ *      declares a VERTICAL `linDir` (`fromT`/`fromB` - "this generation
+ *      runs top-to-bottom", i.e. the fan axis this construct swaps onto Y).
+ *
+ * No third "distinct root template" gate (unlike `resolveCornerHangPlan`'s
+ * own gate 3): this construct's root uses the SAME item template as every
+ * other generation (`horizontal-labeled-hierarchy--hier5.pptx`'s own
+ * `level1Shape`/`level2Shape` are structurally identical plain `tx` leaves,
+ * sized entirely by autofit, no distinct root size declared) -
+ * `resolveHierarchyGenerationTemplates` correctly returns no `root` entry
+ * for it, so gating on that would wrongly EXCLUDE this construct rather
+ * than include it.
+ */
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { DiagramLayoutNode, DiagramPresLayoutVars } from '../model/index.js';
+/** See the module doc comment. `true` only when both conditions hold. */
+export declare function hierarchyDeclaresCenteredFanAxisSwap<R>(view: RawXmlView<R>, algorithmNode: DiagramLayoutNode<R> | undefined, nodeCount: number, presLayoutVars: DiagramPresLayoutVars | undefined): boolean;
+//# sourceMappingURL=smartart-hierarchy-centered-fan-axis.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-centered-fan-axis.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-centered-fan-axis.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAyDG;AAEH,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAChE,OAAO,KAAK,EAAE,iBAAiB,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AASzE,yEAAyE;AACzE,wBAAgB,oCAAoC,CAAC,CAAC,EACrD,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,aAAa,EAAE,iBAAiB,CAAC,CAAC,CAAC,GAAG,SAAS,EAC/C,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,GAC/C,OAAO,CAUT"}