Matterhorn 30-002 · PDF/UA-1 UA1:7.20-2

Tagged form XObject reused on several pages: MCID clash

An MCID is only unique within one content stream. Re-using an XObject that contains MCIDs makes the structure-to-content mapping ambiguous.

What a screen reader actually does

Content maps to the wrong structure element, so text is announced in the wrong place or twice.

What is in the file

A form XObject is a self-contained piece of drawing — its own content stream, its own resources — that a page paints with one operator, Do. Producers use them to draw something once and paint it many times: a running header, a logo, a letterhead.

If the content inside the form is tagged, its marked-content sequences carry MCIDs, and the form gets its own /StructParents key so the structure tree can find them:

51 0 obj                                    % the running header, drawn once
<< /Type /XObject /Subtype /Form
   /BBox [ 0 0 300 20 ]
   /StructParents 7                         % one entry in the parent tree
>>
stream
/P <</MCID 0>> BDC                          % tagged, inside the form
  BT /F1 9 Tf 0 0 Td (Acme Ltd – Confidential) Tj ET
EMC
endstream

% page 1:  q 1 0 0 1 72 800 cm /Hdr Do Q
% page 2:  q 1 0 0 1 72 800 cm /Hdr Do Q   ← the same object, painted again

A structure element claims that content with a marked-content reference that names the stream:

<< /Type /MCR /Stm 51 0 R /MCID 0 /Pg 3 0 R >>

Why the second painting breaks it

MCIDs are unique within one content stream. The form has one content stream, so MCID 0 is one piece of content as far as the structure tree is concerned — however many times the page paints it. And the form has one /StructParents key, so the parent tree has one answer to “which element owns this?”

Painted twice, that one answer has to be right for two places. It is right for at most one. The structure tree reads the header once, as belonging to wherever its element says; the second painting is either attributed to the first page’s element or to nothing. Software walking from the page back to the tree — highlighting the element under the cursor, following a reader’s position, extracting tagged content page by page — finds the same element on page 2 that it found on page 1.

What a screen reader user hears depends on which direction their software walks. Walking the tree, the content appears once, at one place. Walking the page, it may appear twice, or belong to the wrong section. Neither is what was printed.

PDF/UA-1 clause 7.20 requires the content of form XObjects to be incorporated into structure elements the way ISO 32000-1 describes, and that model has no way to give two paintings of one MCID two owners.

Where it comes from

A producer that tags its page template. A report generator or a layout tool that draws headers, footers and logos as a reusable object — a sensible size optimisation — and then tags everything it draws, including that object. Tagged once, painted on every page.

How to check it free

veraPDF reports it against clause 7.20, with the message “Form XObject contains MCIDs and is referenced more than once”. Its test keys on the form’s /StructParents entry and fails a form that is reached a second time as the pages are drawn — so it sees two paintings on one page as well as one on each of two pages. A form with MCIDs and no /StructParents at all is broken differently, and that test does not look at it.

Acrobat Pro can show you the symptom. Open the Tags panel — the hamburger menu (Windows) or the View menu (macOS) → Show/Hide → Side Panels → Tags. Select the header text on page 2 and choose Find Tag From Selection from the panel’s Options menu, which Adobe documents as finding the tag that contains what you selected; then do the same on page 1. A repeated header that has a tag at all should have one per page. Landing on the same tag twice, or on none the second time, is what a shared tagged object looks like from the outside.

How to fix it free

If it is page furniture — and it usually is — artifact it. A running header, footer, logo or page frame is not content; it belongs in the artifact stream, and once the content inside the XObject is marked /Artifact instead of carrying MCIDs, painting it fifty times is harmless. In Acrobat, Adobe documents the Tags panel’s Change Tag To Artifact as changing the selected tags to artifacts and removing the tagged content from the structure tree (Adobe: Edit document structure with the Content and Tags panels):

1. In the Tags panel, select the element that holds the header.
2. Options menu (or right-click) → Change Tag To Artifact.
3. Save, and check again with veraPDF or Taggart.

Adobe does not document how the command treats content that lives inside a form XObject shared between pages, so the re-check is not optional: the condition is gone only when the MCIDs inside the XObject are.

If it is real content that repeats — a disclaimer that must be read on every page, a repeated table heading — each occurrence needs its own XObject with its own MCIDs and its own structure element. That is a change to how the producer writes the file, and the place to make it is the producer’s settings or the source document.

Fix the source either way. A header defined as a running header in the source — Word’s header area, an InDesign parent page — is normally exported as an artifact rather than as tagged content, and the problem does not arise. A running header should be a pagination artifact in any case, which is 18-001.

What Taggart does

Taggart finds every form XObject that has MCIDs inside it and is listed in more than one page’s resources, and reports it with the pages:

Form XObject 51 0 R contains marked-content identifiers and is referenced 2 times (pages 1, 2). MCIDs are only unique within one content stream.

There is no repair. Whether the shared object is furniture to be artifacted or content to be duplicated is a decision about the document, and the second one rewrites page content, which Taggart does not do.

Three things about how it counts, all of which the person reading the finding should know:

• It counts pages that list the XObject, not paintings. A tagged XObject painted twice on the same page is not reported. veraPDF’s test, which follows the paintings, is the one to run for that case.
• It looks for MCIDs, not for /StructParents. A form with tagged content inside is reported whether or not it declares a parent-tree entry, which is the opposite of veraPDF’s starting point. The two can disagree on a malformed file; both disagreements are worth looking at.
• Listed is not the same as painted. A producer that gives every page one shared resource dictionary lists every XObject on every page. Taggart counts those listings, so it can report an XObject as referenced from pages that never draw it. Confirm where it is actually painted before restructuring anything.

How Taggart handles it

Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.

Where this sits in the standards

Related conditions

• 30-001 A reference XObject is presentReference XObjects import content from an external file, which may not be available. PDF/UA-1 forbids them.
• 01-001 Artifact tagged as real contentDecoration — a rule line, a page-border image, a watermark, a background flourish — has been given a real content tag, so assistive technology announces it as if it were part of the document.
• 18-001 Headers and footers are not marked as pagination artifactsRunning heads, footers and page numbers are tagged as real content, so they repeat in the reading order on every page.
• 01-005 Content is neither marked as Artifact nor tagged as real contentEvery text-showing, image-painting and path-painting operator on a page must sit either inside a marked-content sequence that maps to the structure tree, or inside an artifact sequence. Content that is in neither is orphaned.

Other conditions in checkpoint 30

Checkpoint 30 covers xobjects. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• 30-001 A reference XObject is presentReference XObjects import content from an external file, which may not be available. PDF/UA-1 forbids them.

Checked with Taggart on a generated file that fails this condition on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.