Need help in processing SmartArt layout.xml of diagram template "Picture Strips"

Regina Henschel 346 Reputation points
2026-07-14T19:49:09.7333333+00:00

Start a now document in PowerPoint. Insert a SmartArt of diagram template "Picture Strips". Use a list of three dummy items (e.g. One, Two, Three) and add small pictures to the list. Set the background of the SmartArt to some light color, to make it easier to see the size of the diagram area.

Set the height of the SmartArt diagram to 8.0cm.

Make a copy of the file, unpack it and examine the layout1.xml file in folder drawings.

Set the width of the SmartArt diagram to 6.0cm. You get the three items stacked. Increase the width to 6.21cm. For me the items are still stacked. With diagram width 6.21cm the drawing touches all four edges of the diagram area.

It seems that the distance between the items is determined by using the diagram height as reference. That would fit to the markup

        <dgm:constr type="h" for="ch" forName="composite" refType="h"/>

        <dgm:constr type="sp" refType="h" refFor="ch" refForName="composite" op="equ" fact="0.1"/>

        <dgm:constr type="h" for="ch" forName="sibTrans" refType="h" refFor="ch" refForName="composite" op="equ" fact="0.1"/>

Now set the width of the diagram to 6.22cm. The items are still stacked, but there is a margin at top and bottom and the distance between the items has become smaller. It looks as if now the actual size of the composite node is used, whose height is restricted by the aspect ratio parameter ar.

Why are 6.21cm and 6.22cm handled differently? I have expected, that the drawing still fits to the entire height of the diagram, only there will be some free area left and right when the diagram width increases.

Increase the width of the diagram to 14.40cm. The drawing becomes slightly larger. But I cannot derive the underlying calculation from the markup in layout1.xml. Any help?

Increase the width of the diagram to 14.41cm. The layout jumps to an arrangement with two columns. Why does this happen at exactly this width? Can someone explain to me, how it is calculated? I would expect, that it switched to a 2-column layout, if the diagram width is so large, that there is room enough for a second column and the distance between the columns, given by sp or sibTrans node (not really clear which from both to use).

[I know the OOXML standard and the older documentation in https://learn.microsoft.com/en-us/previous-versions/office/developer/office-2007/dd439462(v=office.12)].

Microsoft 365 and Office | Open Specifications
Microsoft 365 and Office | Open Specifications

Technical documents for protocols, computer languages, standards support, and data portability. The goal with Open Specifications is to help developers open new opportunities to interoperate with Windows, SQL, Office, and SharePoint.

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Mike Bowen 2,146 Reputation points Microsoft Employee Moderator
    2026-07-23T17:13:12.3766667+00:00

    Hi @Regina Henschel,

    After investigating the SmartArt diagram layout rendering I found the explanation below for why the layout jumps around.

    TLDR:

    • SmartArt computes composite size two ways: (1) fit to full diagram height, derive width via aspect ratio; (2) fit to available width, derive height via aspect ratio. It picks whichever fits without overflowing - solution 2 can only be ≤ solution 1.
    • At 6.21cm the height-driven width still fits -> solution 1 (full height) wins. At 6.22cm it just barely doesn't -> solver flips to solution 2 (width-driven, shorter height, hence margins + tighter spacing). It's a hard branch switch ( min() of two functions), not a gradual blend, so the change looks abrupt even for a 0.01cm difference.
    • The 1 -> 2 column jump works the same way but for column count: it's an integer choice, so as soon as the available width crosses the exact point where 2 columns (+ spacing) first fit, it snaps discretely - no gradual transition possible.

    Full answer:

    Why 6.21cm vs 6.22cm flips behavior

    The solver evaluates two competing solutions for the composite node size and picks whichever one satisfies all constraints (doesn't exceed available bounds):

    1. Height-driven solution: composite height = parent (ch) height derived from diagram height (per your type="h" refType="h" constraint). Composite width is then derived from that height via the node's fixed aspect ratio (ar). This is the "primary" solution the layout prefers.
    2. Width-driven fallback: if the height-driven composite's width would exceed the width actually available in the column, the solver instead pins composite width to the available column width and derives composite height from that via the same ar . This always produces an equal or smaller height than solution 1 (that's mathematically why fitting to width instead of height can only shrink it, not grow it).

    At 6.21cm the height-driven width still fits inside the (slightly larger) available column width, so solution 1 wins - full height used, spacing (sp / sibTrans, pegged at 0.1× the composite/parent height) is at its "full" value, drawing touches all four edges.

    At 6.22cm the increment is tiny, but it's just enough that the available width now barely exceeds what's needed - except floating-point/rounding in the solver flips which branch is feasible, or more likely: your 6.21cm case was actually already width-constrained by a hair and rounding masked it, and 6.22 is the first value where the width-derived (smaller) composite is unambiguously chosen. Because the switch between "solution 1" and "solution 2" is a discrete branch selection (min of two piecewise-continuous functions), not a continuous blend, there's a visible kink exactly at the crossover width - hence margins appearing suddenly and spacing shrinking (since sp / sibTrans are fact="0.1" of whatever height solution 2 now computes, which is smaller than solution 1's height).

    This matches your own diagnosis - you had it right. The "surprise" is simply that the solver's branch choice is a hard min(), not a smooth interpolation, so there's no continuum where "extra space appears left/right while height stays maxed" - once width becomes the binding constraint, height must drop to satisfy ar, even by a hair.

    14.40 -> 14.41cm column jump

    That threshold is the diagram-level dgm:choose / dgm:if logic (evaluated on the overall available width vs. the space needed for N columns + (N-1)× spacing at the minimum viable per-item height). I don't have your layout.xml file, so I can't give you the exact val= threshold, but the mechanism is: the algorithm computes, for each candidate column count, the resulting per-item height under that arrangement, checks it against a minimum ar /minimum-size floor, and picks the highest column count that still satisfies the floor and fits the width. The jump is sharp (not gradual) because column count is an integer choice - there's no "3.9 columns" - so as available width crosses the exact point where 2 columns' total required width (2×item-width-at-min-height + 1×spacing) first fits, the layout snaps discretely from 1 -> 2 columns.

    Let me know if that answers your question.

    Best regards,

    Michael Bowen

    Sr. Escalation Engineer - Microsoft® Corporation

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.