ooxml-core 1.1.0 → 1.2.1

package/dist/diagram/hierarchy/smartart-hierarchy-wrapped-groups.d.ts

@@ -0,0 +1,93 @@
+/**
+ * SmartArt DiagramML interpreter - "hierChild group" wrap-into-row-or-column
+ * decision, used by `placeWrappedChildren` in `smartart-hierarchy-standard.ts`
+ * when a generation's ordinary children exceed the resolved `chPref`/`chMax`
+ * row size.
+ *
+ * Closes the residual documented (until now) in `docs/guide/limitations.md`'s
+ * "SmartArt layout" row: a manager row that is NOT exactly `chPref` wide (2,
+ * 4 or 5 siblings, one or two of which separately have `chPref` reports of
+ * their own). Measured against the genuine, COM-authored
+ * `smartart-orgchart-fan-variants.pptx` corpus fixture (11 slides: row widths
+ * 2/4/5, the chPref-reaching manager at every position - first/middle/last -
+ * plus two-manager variants at width 2 and 4).
+ *
+ * The root cause is NOT a rendering-time "fan" decision at all: it is that
+ * PowerPoint's own org-chart data model does not attach a manager's reports
+ * to the manager once its own "hierChild group" wrapper still has room.
+ * `SmartArtNode.AddNode()` fills the CURRENT wrapper (capacity `chPref`,
+ * matching `flattenOrgChartGroupWrappers`'s doc comment) regardless of which
+ * node's `.Nodes` collection the call targets, so a manager only keeps its
+ * own DIRECT child once its wrapper is full; earlier "reports" are spliced in
+ * as the manager's own ROW SIBLINGS instead. `flattenOrgChartGroupWrappers`
+ * already reconstructs this (each wrapper's members become flat siblings of
+ * the wrapper's own parent), so by the time `placeWrappedChildren` sees the
+ * flat list, wrapper boundaries have already been reconstructible: because a
+ * wrapper always fills to `chPref` before the next one starts (this is simply
+ * how repeated `.Nodes.Add()` calls behave), re-chunking the FLAT list
+ * sequentially into `chPref`-sized groups (exactly what `placeWrappedChildren`
+ * already does for its column grouping) reproduces the ORIGINAL wrapper
+ * boundaries exactly. Verified against all 11 fixture slides.
+ *
+ * What was missing is the PER-GROUP row-vs-column choice. Measured: when a
+ * group's members are all leaves (no ordinary children of their own) -
+ * `smartart-orgchart-many.pptx`'s shape - PowerPoint compacts the group into
+ * one hanging COLUMN (already modelled). But when ANY member of a group has
+ * its own ordinary children (needs vertical room below it), PowerPoint fans
+ * the WHOLE group inline across the shared ROW instead, contiguous with
+ * neighbouring groups - never partially, and never per-member: a group with
+ * one "heavy" member and two plain leaves still fans all three. Confirmed
+ * across every combination in the fixture (manager first/middle/last within
+ * its own group, two managers in the same row, groups of size 1/2/3).
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { TreeNode } from '../layout/smartart-tree.js';
+import type { PlaceAtFn } from './smartart-hierarchy-fan.js';
+import type { HierContext } from './smartart-hierarchy-shared.js';
+/** One `chPref`-sized (or smaller, if trailing) chunk of a wrapped generation. */
+export interface WrappedGroup {
+    readonly members: readonly TreeNode[];
+    /**
+     * True when at least one member has its own ordinary children: the whole
+     * group fans inline across the shared row instead of compacting into a
+     * hanging column. See the module doc comment.
+     */
+    readonly fansAsRow: boolean;
+}
+/**
+ * Chunk `children` sequentially into `perColumn`-sized groups (the last may
+ * be smaller) and classify each as a row-fan or a leaf-only column.
+ */
+export declare function planWrappedGroups(children: readonly TreeNode[], perColumn: number, orgChart: boolean): WrappedGroup[];
+/**
+ * How many shared-row column units this group's plan consumes: every
+ * member's own `effectiveWidth` for a row-fan group (each gets its own
+ * column, same as an ordinary flat child), or exactly one shared unit for a
+ * leaf-only column (its extra members stack below that one unit, they never
+ * widen the row).
+ */
+export declare function wrappedGroupSlotCount(group: WrappedGroup, orgChart: boolean): number;
+/** The options shape `placeWrappedChildren` needs from its caller's own options object. */
+export interface WrappedChildrenOptions {
+    orgChart: boolean;
+    /** Resolved `chPref`/`chMax` row size; must be finite when this is called. */
+    perRow: number;
+}
+/**
+ * Place one generation's ordinary children (already known to exceed
+ * `options.perRow`) as `chPref`-sized GROUPS, side by side, in the shared row.
+ * Each group is either fanned inline as ordinary row members (at least one
+ * member has its own ordinary children) or compacted into one hanging COLUMN
+ * (all its members are leaves) - see the module doc comment for the
+ * measurement. `placeAtFn` is injected (rather than imported) to avoid a
+ * value-level import cycle with `smartart-hierarchy-standard.ts`, which is
+ * this function's only caller and owns `placeAt`.
+ *
+ * A wrapped child's own descendants still resolve onto the normal per-level
+ * grid: the virtual `xOffset` handed to its own recursion is solved so
+ * `(xOffset + childW / 2) * cellW` reproduces the position already used here,
+ * keeping `cellW`/`cellH` uniform for every generation past this one.
+ */
+export declare function placeWrappedChildren<TOptions extends WrappedChildrenOptions>(hc: HierContext, parentId: string, normal: TreeNode[], cx: number, cy: number, xOffset: number, spanW: number, level: number, cellW: number, cellH: number, options: TOptions, placeAtFn: PlaceAtFn<TOptions>): void;
+//# sourceMappingURL=smartart-hierarchy-wrapped-groups.d.ts.map

package/dist/diagram/hierarchy/smartart-hierarchy-wrapped-groups.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-hierarchy-wrapped-groups.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-hierarchy-wrapped-groups.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2CG;AAEH,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AACxD,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,0BAA0B,CAAC;AAG1D,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;AAE/D,kFAAkF;AAClF,MAAM,WAAW,YAAY;IAC5B,QAAQ,CAAC,OAAO,EAAE,SAAS,QAAQ,EAAE,CAAC;IACtC;;;;OAIG;IACH,QAAQ,CAAC,SAAS,EAAE,OAAO,CAAC;CAC5B;AAED;;;GAGG;AACH,wBAAgB,iBAAiB,CAChC,QAAQ,EAAE,SAAS,QAAQ,EAAE,EAC7B,SAAS,EAAE,MAAM,EACjB,QAAQ,EAAE,OAAO,GACf,YAAY,EAAE,CAQhB;AAED;;;;;;GAMG;AACH,wBAAgB,qBAAqB,CAAC,KAAK,EAAE,YAAY,EAAE,QAAQ,EAAE,OAAO,GAAG,MAAM,CAKpF;AAED,2FAA2F;AAC3F,MAAM,WAAW,sBAAsB;IACtC,QAAQ,EAAE,OAAO,CAAC;IAClB,8EAA8E;IAC9E,MAAM,EAAE,MAAM,CAAC;CACf;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,oBAAoB,CAAC,QAAQ,SAAS,sBAAsB,EAC3E,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,KAAK,EAAE,MAAM,EACb,OAAO,EAAE,QAAQ,EACjB,SAAS,EAAE,SAAS,CAAC,QAAQ,CAAC,GAC5B,IAAI,CA4CN"}

package/dist/diagram/hierarchy/smartart-layout-interpreter-hierarchy.d.ts

@@ -0,0 +1,49 @@
+/**
+ * SmartArt DiagramML interpreter - hierarchy (`hierRoot` / `hierChild`) arranger.
+ *
+ * Arranges the data-model node tree as an org-chart / hierarchy, consulting
+ * `presLayoutVars` (`dgm:presLayoutVars`/`dgm:varLst`) for every hint:
+ *
+ *   - `hierBranch` (`std`/`init`/`hang`/`l`/`r`): the root's OWN direct
+ *     children ALWAYS fan out via the standard branch, whatever `hierBranch`
+ *     says - measured against four genuine PowerPoint org charts (one slide
+ *     per `SmartArtNode.OrgChartLayout` value): the manager's direct reports
+ *     stay in one fanned row for Standard, Both/Left/Right Hanging alike.
+ *     `hierBranch` only changes generations PAST the first, and only for
+ *     `init`/`hang`/`l`/`r` (literal `std` fans every generation, matching
+ *     base ECMA-376, likely unreachable from real PowerPoint - an unset root
+ *     `hierBranch` resolves to `init`, not `std`). `init`/`hang`/`l`/`r` all
+ *     hang the tail the SAME direction, never alternating per sibling,
+ *     despite the "Left"/"Both Hanging" naming - see `HIER_TAIL_OFFSET_RATIO`'s
+ *     doc comment in `smartart-hierarchy-shared.ts`. Each hanging hop
+ *     (including the first, out of the fanned generation) offsets by that
+ *     measured ratio of the box width, modelling `hierAlign`/`alignOff`.
+ *   - `orgChart`: when set, `dgm:pt/@type="asst"` assistant nodes render in a
+ *     dedicated row/slot next to their manager instead of fanning out as an
+ *     ordinary subordinate.
+ *   - `chMax`/`chPref`: group ordinary children exceeding this size into that
+ *     many side-by-side hanging COLUMNS instead of one fanned row (standard
+ *     branch only; a hanging column has no "row" to group). See
+ *     `smartart-hierarchy-standard.ts`'s `placeWrappedChildren`.
+ *
+ * When `presLayoutVars.hierBranch` is ABSENT, a THIRD mode (`mode==='hanging'`,
+ * the WHOLE tree in one hanging column) is reachable, but ONLY for the
+ * declared "corner-anchored" construct (`hierAlign="tL"/"tR"` on a genuinely
+ * root-vs-descendant-templated hierarchy) - see `smartart-hierarchy-corner-
+ * plan.ts`'s own module doc comment for the full gate and why the plain
+ * fanning family and the centred-on-children "Horizontal Hierarchy" family
+ * both correctly stay on the `std`/`tailed` path below instead. See
+ * `smartart-hierarchy-orientation.ts` for the SEPARATE fan/generation axis
+ * transposition (`sibSp` referencing `h`, e.g. "Horizontal Hierarchy") that
+ * `std`/`tailed` path applies.
+ *
+ * Pure geometry; no framework code, no DOM.
+ */
+import type { DiagramLayoutNode, DiagramNode, DiagramPresLayoutVars } from '../model/index.js';
+import type { DiagramStyleIntensity } from '../types.js';
+import type { RawXmlView } from '../layout/smartart-choose-xml.js';
+import type { ConstraintIndex } from '../layout/smartart-constraint-solver.js';
+import type { BoundingBox, SmartArtLayoutResult } from '../layout/smartart-layout-types.js';
+/** Execute the hierarchy algorithm over the data-model node tree. */
+export declare function arrangeHierarchy<R>(view: RawXmlView<R>, nodes: DiagramNode[], box: BoundingBox, palette: string[], style: DiagramStyleIntensity, elementId: string, presLayoutVars: DiagramPresLayoutVars | undefined, connectorLabels?: Map<string, string>, algorithmNode?: DiagramLayoutNode<R>, index?: ConstraintIndex, childOrder?: Map<string, number>, fontName?: string): SmartArtLayoutResult;
+//# sourceMappingURL=smartart-layout-interpreter-hierarchy.d.ts.map

package/dist/diagram/hierarchy/smartart-layout-interpreter-hierarchy.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"smartart-layout-interpreter-hierarchy.d.ts","sourceRoot":"","sources":["../../../diagram/hierarchy/smartart-layout-interpreter-hierarchy.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AAEH,OAAO,KAAK,EAAE,iBAAiB,EAAE,WAAW,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtF,OAAO,KAAK,EAAE,qBAAqB,EAAE,MAAM,UAAU,CAAC;AACtD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,+BAA+B,CAAC;AAChE,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,sCAAsC,CAAC;AAqB5E,OAAO,KAAK,EACX,WAAW,EAGX,oBAAoB,EACpB,MAAM,iCAAiC,CAAC;AAEzC,qEAAqE;AACrE,wBAAgB,gBAAgB,CAAC,CAAC,EACjC,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,EACnB,KAAK,EAAE,WAAW,EAAE,EACpB,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,MAAM,EAAE,EACjB,KAAK,EAAE,qBAAqB,EAC5B,SAAS,EAAE,MAAM,EACjB,cAAc,EAAE,qBAAqB,GAAG,SAAS,EACjD,eAAe,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,EACrC,aAAa,CAAC,EAAE,iBAAiB,CAAC,CAAC,CAAC,EACpC,KAAK,GAAE,eAAwC,EAC/C,UAAU,CAAC,EAAE,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,EAChC,QAAQ,CAAC,EAAE,MAAM,GACf,oBAAoB,CAoMtB"}