Master items and stamping

Stamping is the render-time pass that copies a master's items onto each body page that names it, beneath the page's own content.

In short: A master item never appears in a body page's XML — it lives in the master file, and the renderer reconstructs the page by stamping the master's items onto it. The pass resolves the page's AppliedMaster, picks the matching master page, routes each item to the page it belongs to, and offsets it onto the body page's origin. It runs before the page's own items, so master furniture lands at the back of the display list and body content paints on top. This page is the reference for that pass: what it copies, where it puts it, and which attributes steer it.

A master item never appears in a body page's XML. When you open a Spreads/Spread_*.xml you see only the items the user drew on that page; the header rule that visibly sits behind them lives in the MasterSpreads/*.xml file the page's AppliedMaster points at. The renderer reconstructs the page by stamping the master's items onto it. This page is the reference for that stamping pass: what it copies, where it puts it, and which attributes steer it.

If you have not yet seen that a MasterSpread is parsed by the same reader as a Spread, read Master spreads first — this page picks up where it ends.

The stamping pass, in order

The renderer runs the master pass before it emits a page's own items. That ordering is the whole reason master furniture sits behind body content: items emitted first land at the back of the page's display list, and the page's own items, emitted afterwards, paint on top. A master header rule therefore shows through behind the body copy without any explicit z-index — back-to-front order does the work, exactly as it does for page items within a spread.

For each body page that names a master, the pass does four things:

1. Resolves the master. The page's AppliedMaster is looked up against the table of parsed masters. The lookup is forgiving about the prefix: a page may write umaster or MasterSpread/umaster and both resolve to the same master. If no master matches, the page is left with only its own items.
2. Picks the matching master page. A master can hold more than one page (a facing-pages master with a distinct left and right page). The body page takes items from the master page at its same ordinal — left from left, right from right — not from every master page at once.
3. Routes each item to the page it belongs to. Within the chosen master page, the pass keeps an item when its centre lands on that master page, or when the item is large enough to be a full-page background that overlaps it. This is what stops a master's navy left-page panel from also stamping onto every right page.
4. Offsets and emits. Each kept item is copied, shifted so the master page's origin lands on the body page's origin (plus any MasterPageTransform offset — see below), and emitted into the body page's display list.

Items the body page has overridden are skipped in step 4; that is the subject of Override resolution.

What gets stamped, and what does not

The pass copies the master's items per shape type: text frames, rectangles, ovals, graphic lines, and polygons are each walked and stamped. A master text frame that hosts a story (a running header, a page-number footer) is relocated and its story is re-flowed onto the body page, so the folio shows the body page's number rather than the master's placeholder.

Two structural caveats are worth stating plainly, because they differ from how a body spread's own items are handled:

• Master items are stamped by shape-type bucket, not in document order. A body spread's own items render in the single frames_in_order list, so their XML order is their z-order. The master pass does not consult that list; it walks each shape vector in turn. For the typical master — a background, then a rule, then a folio frame — the result is indistinguishable, but a master that relies on interleaved cross-type stacking is not guaranteed to keep it. Parsed, not yet renderedMaster items stamped per shape-type, not via frames_in_order
• A Group on the master is not stamped. The pass has no group arm, so a cluster the user grouped on the master (to share one opacity or drop shadow) does not reach the body page as a group. Author master furniture as top-level shapes, not groups, until this is wired. Not yet parsedMaster-spread Groups are not stamped onto body pages

The attributes that steer stamping

On the body Page

These are the Page attributes the stamping pass reads. They are documented in full on Spreads and pages; the notes here are about their role in stamping specifically.

On the MasterSpread

A MasterSpread shares all of a Spread's structure; the parser reads its Self and ItemTransform exactly as for any spread. Beyond that it carries a few master-only naming attributes that document spreads do not have. The parser reads the Self id (so AppliedMaster can match it) and treats the rest as informational.

MasterPageTransform: the master overlay offset

A master holds its items in its own spread coordinates. To land them on a body page, the renderer computes the offset from the master page's origin to the body page's origin and shifts every stamped item by it. MasterPageTransform is the extra nudge that lets one specific body page slide its master overlay — InDesign's "master page overlay" control.

The current pass reads the full six-number matrix but consumes only its translation (tx, ty), adding it to the master→body offset. For the overwhelmingly common case the matrix is identity and there is nothing to add; a master overlay that was scaled or rotated relative to its page is not yet reproduced.

ShowMasterItems: parsed, not honored

The format carries a ShowMasterItems boolean — on both the body Spread and the MasterSpread — to toggle whether master items display. The stamping pass does not consult it: any page with an AppliedMaster gets its master items stamped. A spread that sets ShowMasterItems="false" to hide its master layer is not yet honored, and its master items will still appear.

This matters more than it looks. The example below ships with a master spread that declares ShowMasterItems="false", yet its master rectangle is still a live participant in stamping — it is suppressed on the body page only because the body page overrides it, not because of the flag.

A worked example

The two-page spread below is the simplest place to watch stamping route per page. The master holds one header rule; the spread holds two body pages side by side, each applying that master by its bare Self id. Read the spread part: the two <Page> elements come first (each with its own ItemTransform placing it left or right of the binding), then the body items. Each page receives the master's header rule, offset onto its own origin — the routing in step 3 sends the right copy to the right page.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<idPkg:Spread xmlns:idPkg="http://ns.adobe.com/AdobeInDesign/idml/1.0/packaging" DOMVersion="20.0">
  <Spread Self="uspread" PageCount="2" BindingLocation="1" ShowMasterItems="true" AllowPageShuffle="true" ItemTransform="1 0 0 1 0 0">
    <Page Self="upageL" Name="2" AppliedMaster="umaster" ItemTransform="1 0 0 1 -595.276 0" GeometricBounds="0 0 841.89 595.276" MasterPageTransform="1 0 0 1 0 0"/>
    <Page Self="upageR" Name="3" AppliedMaster="umaster" ItemTransform="1 0 0 1 0 0" GeometricBounds="0 0 841.89 595.276" MasterPageTransform="1 0 0 1 0 0"/>
    <TextFrame Self="uframeL" ParentStory="ustoryL" PreviousTextFrame="n" NextTextFrame="n" ContentType="TextType" AppliedObjectStyle="ObjectStyle/$ID/[None]" Visible="true" Name="$ID/" ItemTransform="1 0 0 1 -537.638 145.8237" FillColor="Swatch/None" StrokeColor="Swatch/None" StrokeWeight="0">
      <Properties>
        <PathGeometry>
          <GeometryPathType PathOpen="false">
            <PathPointArray>
              <PathPointType Anchor="0 0" LeftDirection="0 0" RightDirection="0 0"/>
              <PathPointType Anchor="0 400" LeftDirection="0 400" RightDirection="0 400"/>
              <PathPointType Anchor="480 400" LeftDirection="480 400" RightDirection="480 400"/>
              <PathPointType Anchor="480 0" LeftDirection="480 0" RightDirection="480 0"/>
            </PathPointArray>
          </GeometryPathType>
        </PathGeometry>
      </Properties>
    </TextFrame>
    <TextFrame Self="uframeR" ParentStory="ustoryR" PreviousTextFrame="n" NextTextFrame="n" ContentType="TextType" AppliedObjectStyle="ObjectStyle/$ID/[None]" Visible="true" Name="$ID/" ItemTransform="1 0 0 1 57.638 145.8237" FillColor="Swatch/None" StrokeColor="Swatch/None" StrokeWeight="0">
      <Properties>
        <PathGeometry>
          <GeometryPathType PathOpen="false">
            <PathPointArray>
              <PathPointType Anchor="0 0" LeftDirection="0 0" RightDirection="0 0"/>
              <PathPointType Anchor="0 400" LeftDirection="0 400" RightDirection="0 400"/>
              <PathPointType Anchor="480 400" LeftDirection="480 400" RightDirection="480 400"/>
              <PathPointType Anchor="480 0" LeftDirection="480 0" RightDirection="480 0"/>
            </PathPointArray>
          </GeometryPathType>
        </PathGeometry>
      </Properties>
    </TextFrame>
  </Spread>
</idPkg:Spread>

Read it against the inspector output: two pages, four frames total — each page's own text frame plus the stamped master rule. The master's items are not in the spread XML; they are stamped in.

Once you can predict what stamping adds, the next page covers what an override tells it to leave out.

Frequently asked questions

Why don't master items appear in the body page's XML? Because masters are inherited, not copied. A Spreads/Spread_*.xml part holds only the items drawn on that page; the master's items stay in the MasterSpreads/*.xml file the page's AppliedMaster points at, and the renderer stamps them onto the page at render time. This keeps the repeating furniture authored in one place.

Why do master items render behind a page's own content? The stamping pass runs before the renderer emits a page's own items, so master items land at the back of the page's display list and the page's own items, emitted afterwards, paint on top. The back-to-front order does the work — no explicit z-index is needed.

Does the ShowMasterItems flag hide a page's master items? Not currently. ShowMasterItems is parsed but not honored: any page with an AppliedMaster gets its master items stamped regardless of the flag's value. To suppress a specific master item on a page, list its Self id in the page's OverrideList instead.

Are grouped master items stamped onto body pages? No. The stamping pass walks each shape type — text frames, rectangles, ovals, graphic lines, and polygons — but has no arm for Group, so a cluster grouped on the master does not reach the body page. Author master furniture as top-level shapes until grouping is wired.