Override resolution

Override resolution is the rule by which a body page's OverrideList tells the renderer to skip specific master items so the page's own copy can stand in.

In short: Where stamping adds every eligible master item to a body page, override resolution is the subtraction. A body page's OverrideList attribute holds a space-separated set of the Self ids of master items it has taken over; before the stamping pass walks the master's items, it builds a set from that list and skips any item whose id is in it. The mechanism is small — one attribute, one membership test — but the semantics around it (what counts as an override, what the renderer actually checks, where it stops short) reward a close look. This page is that look; the end-to-end "one item swapped" walkthrough lives on the layout model's Override resolution.

Stamping adds every eligible master item to a body page. Override resolution is the subtraction: the rule by which a body page tells the renderer to leave out specific master items, so its own copy can stand in their place. The mechanism is small — one attribute, one set membership test — but the semantics around it (what counts as an override, what the renderer actually checks, where it stops short) reward a close look. This page is that look. The end-to-end "one item swapped" walkthrough lives on the layout model's Override resolution; here we go under it.

What OverrideList means

OverrideList is an attribute on the body <Page>. Its value is a space-separated list of the Self ids of master items this page has overridden. The parser splits it on whitespace into a list of ids and stores it on the page; that list is the page's complete declaration of intent: "for these master items, do not use the master's version."

An override is a two-sided arrangement, and both sides have to be present for the result to look right:

1. The body page lists a master item's id in OverrideList, which removes the master's version from the page.
2. The body page holds its own replacement — an ordinary top-level page item, usually with the same role and position as the master item it stands in for.

The format models this as the body page "promoting" a copy of the master item into a real, editable page item and recording the original's id so it is not drawn twice. From the renderer's side, though, only one thing happens at stamp time: the listed ids are skipped. The replacement is not linked to the override — it is just a normal page item that happens to occupy the space the suppressed master item vacated.

How resolution runs

The override check lives inside the stamping pass, not in a separate phase. Before the pass walks the master's items for a body page, it builds a set from that page's OverrideList. Then, for every master item it would otherwise stamp — across all five shape types: text frames, rectangles, ovals, graphic lines, polygons — it tests the item's Self id against that set and, on a hit, skips it. The skipped item is simply never emitted for that page.

The net effect is a clean one-for-one swap:

• The master's version is not stamped (the override list suppressed it), so there is no placeholder painting underneath.
• The body's replacement, being an ordinary page item, paints on its own through the normal frame pass.

Because the suppression is keyed on the Self id, an id that appears in OverrideList is removed whether or not the body page actually supplies a replacement. List an id with no replacement and you get a clean deletion of that master item from the page — which is occasionally exactly what an author wants.

What the renderer does not check

This is where the deep companion earns its keep. The format carries more override machinery than the renderer currently consults, and assuming the unread parts are honored is the easiest way to be surprised.

AllowOverrides is not read

In the format, a master item carries an AllowOverrides flag that gates whether a body page is permitted to override it. The current parser does not read that flag at all. Suppression is driven purely by the body page's OverrideList: an id present there is skipped regardless of whether the master item opted in. In practice InDesign only writes ids into OverrideList for items that allowed it, so well-formed exports behave correctly — but the renderer is trusting the list, not enforcing the gate.

OverriddenPageItemProps is not read

An override in InDesign can be partial: a page can override a master item's properties (move it, recolour it) without replacing the whole item, and the master spread records which properties via OverriddenPageItemProps. The parser does not read that attribute, so property-level overrides are not reconstructed — the model is whole-item-or-nothing.

The override chain is only shallow-tested

The single-item override is exercised and behaves as described. The fuller story — long override lists, overrides interacting with a multi-page facing master, the interplay of suppression with the per-page item routing of stamping — is only partially tested. If an override on a complex master misbehaves, this is the first place to suspect.

A worked example

The package below is a master with a single header rectangle and a body page that overrides it. Three details in the parts make the whole mechanism visible:

• The master rectangle is umasterHeader, a solid black bar.
• The body page declares OverrideList="umasterHeader" — naming exactly that master item.
• The body page supplies its own ubodyHeader rectangle in the same place, here a lighter 40% tint, plus its body text frame.

Because umasterHeader is in the override set, the stamping pass skips it; the body's ubodyHeader paints in its place.

<?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="1" BindingLocation="0" ShowMasterItems="true" AllowPageShuffle="true" ItemTransform="1 0 0 1 0 0">
    <Page Self="upage" Name="1" AppliedMaster="umaster" OverrideList="umasterHeader" ItemTransform="1 0 0 1 0 0" GeometricBounds="0 0 841.89 595.276" MasterPageTransform="1 0 0 1 0 0"/>
    <Rectangle Self="ubodyHeader" ContentType="Unassigned" AppliedObjectStyle="ObjectStyle/$ID/[None]" Visible="true" Name="$ID/" ItemTransform="1 0 0 1 57.638 56.6929" FillColor="Color/Black" FillTint="40" StrokeColor="Swatch/None" StrokeWeight="0">
      <Properties>
        <PathGeometry>
          <GeometryPathType PathOpen="false">
            <PathPointArray>
              <PathPointType Anchor="0 0" LeftDirection="0 0" RightDirection="0 0"/>
              <PathPointType Anchor="0 24" LeftDirection="0 24" RightDirection="0 24"/>
              <PathPointType Anchor="480 24" LeftDirection="480 24" RightDirection="480 24"/>
              <PathPointType Anchor="480 0" LeftDirection="480 0" RightDirection="480 0"/>
            </PathPointArray>
          </GeometryPathType>
        </PathGeometry>
      </Properties>
    </Rectangle>
    <TextFrame Self="uframe" ParentStory="ustory" 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: the page reports exactly two frames — the body text frame and the body's replacement rectangle. The master's header is not among them. If the override were ignored, a third frame (the stamped master header) would appear behind the body's copy.

This example also quietly demonstrates the limits above. Its master spread is authored with ShowMasterItems="false" and the master rectangle carries AllowOverrides="true" — yet neither flag is what produces the result. The header is gone purely because its id is in the body page's OverrideList. The ShowMasterItems flag is not honored and AllowOverrides is not parsed; the OverrideList is doing all the work.

For the inheritance side this resolution sits on top of, return to Master items and stamping.

Frequently asked questions

What does the OverrideList attribute do? OverrideList is an attribute on a body <Page> holding a space-separated list of the Self ids of master items the page has overridden. During the stamping pass, the renderer builds a set from that list and skips any master item whose id is in it, so the page's own replacement can take its place.

What happens if I override a master item but supply no replacement? The master item is cleanly deleted from that page. Suppression is keyed only on the Self id, so an id in OverrideList is skipped whether or not the body page provides a replacement — listing an id with nothing to stand in for it removes that master item from the page.

Does the renderer honor the AllowOverrides flag on master items? No. AllowOverrides is not parsed; suppression is driven purely by the body page's OverrideList. In practice InDesign only writes ids into OverrideList for items that allowed overriding, so well-formed exports behave correctly — but the renderer trusts the list rather than enforcing the gate.

Can a body page override just some properties of a master item? Not yet. Property-level overrides are recorded by OverriddenPageItemProps, which the parser does not read, so the model is whole-item-or-nothing: a master item is either stamped in full or suppressed in full by its id appearing in OverrideList.