Matterhorn TG-RTL-004 · PDF/UA-1 Taggart extension

Hebrew two-column PDFs tagged in left-to-right order

Auto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.

What a screen reader actually does

The reader announces the second column before the first, so every page reads as two interleaved halves.

The failure

A Hebrew newsletter, two columns. Sighted readers start at the top right, read down, move to the top left, read down. The page is unambiguous.

The tagger walked it top-left to bottom-right. The structure tree now reads: left column paragraph 1, left column paragraph 2, … then right column paragraph 1. A screen reader user gets the second half of every article first, then the first half — two coherent streams of Hebrew, interleaved into nonsense.

This is 09-001 — tags not in logical reading order — with a specific, mechanical, entirely predictable cause. It is worth its own condition because the cause tells you both how to find it and how to fix it in bulk.

Why every auto-tagger does this

Automatic tagging derives reading order from geometry, and the geometric rule is essentially universal:

sort blocks by vertical band; within a band, sort by increasing x.

Increasing x is left to right. That is correct for Latin script and wrong for every right-to-left script, and the tools do not condition the rule on the script of the content — the rule lives in the layout analyser, which runs before anything knows what language the text is in.

Acrobat’s Add Tags to Document, most commercial batch pipelines and the auto-tag pass in several remediation suites all inherit this. It is not a bug anyone introduced; it is a default nobody localised.

Where it shows up

Four layouts produce it reliably:

• Two- and three-column Hebrew editorial — newsletters, university bulletins, municipal magazines.
• Israeli government forms with a right-hand instruction rail. The rail is tagged last, so the instructions are read after the fields they explain.
• Arabic and Hebrew academic papers in two-column templates, where an English abstract in column one makes the mis-ordering harder to spot.
• Sidebars and pull-quotes floated left in an RTL page. Left is the end of an RTL line, so the float should be read after the body block it sits beside, and it is read before.

What is in the file

Nothing is wrong with the page description. The glyphs are painted where they belong; the file renders perfectly. The defect is entirely in the order of the kids array of the structure tree:

% Structure tree, in the order it will be read
/StructTreeRoot
  /Document
    /P  -> MCID 14   % left column, x ≈ 60 .. 280
    /P  -> MCID 15   % left column
    /P  -> MCID 2    % right column, x ≈ 315 .. 535   <- should be first
    /P  -> MCID 3    % right column

The give-away is the MCIDs. Marked-content ids are assigned in paint order, and layout engines usually paint an RTL page’s right column first. So a structure tree whose kids run 14, 15, 2, 3 on an RTL page has almost certainly been re-sorted by geometry after the fact.

How to find it in ten seconds, free

Open the file in Acrobat Reader — no Pro licence needed — and use the Read Out Loud feature (View → Read Out Loud → Activate, then Read This Page Only). You do not need to understand what it says. Listen for whether the first thing read is the text at the top right of the page.

Faster still, for a file you cannot listen to: select all the text on one page and paste it into a plain-text editor. Copy order follows structure order when a document is tagged. If the paste starts with the left column, the tags are in left-to-right order.

How to fix it free, in Acrobat Pro

The Reading Order tool cannot reorder anything — it only assigns types. Reordering happens in the Tags panel, and for a two-column page it is faster than it looks:

1. View → Show/Hide → Navigation Panes → Tags.
2. View → Show/Hide → Navigation Panes → Order alongside it, and turn on Show reading order panel so you can see the page regions numbered.
3. In the Tags tree, expand the page and identify the two runs. Click each element to see the highlighted region on the page — that is the only reliable way to tell which column an element belongs to.
4. Select the whole right-column run (click the first element, shift-click the last).
5. Drag it above the left-column run. Acrobat drops between elements, not into them, so aim for the horizontal insertion line at the same indent level.
6. Repeat per page.

Two cautions from doing this on real files. Acrobat’s Tags panel has no multi-level undo for drags — one mis-drop can nest a run inside a paragraph, and you will not see it in the tree without expanding. Save a copy before you start. And a drag that lands inside an element rather than between two changes the semantics silently, so re-check the nesting depth after each move.

For a 40-page Hebrew bulletin this is roughly 40 minutes of careful dragging, which is the number this product exists to change.

How Taggart does it

Column detection runs on the marked-content geometry, not on laid-out lines. That distinction is the whole trick: a text extractor groups by baseline, so the last line of the right column and the first line of the left column — which share a y — become one line and the two columns dissolve. Taggart takes the bounding box of every MCID, clusters their horizontal spans, and finds the gutter as the widest empty vertical band.

Once the bands are known, the page’s primary script decides the order: if the strong-direction characters on the page are predominantly Hebrew or Arabic, bands are ordered by decreasing x. Within a band, order is by decreasing y as usual.

The reorder is a reading-order fix, which is not in the safe set. It changes what the document means, so Taggart proposes the new order, shows it as numbered badges over the rendered page, and waits. You can accept it, reorder by hand with Alt and the arrow keys, or reject it with a justification — and whichever you do goes into the remediation report with a timestamp and an actor.

How Taggart handles it

Taggart detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.

The fix is Repair reading order. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.

Where this sits in the standards

Related conditions

• 09-001 Tags are not in logical reading order The order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.
• TG-RTL-001 Right-to-left text is stored in visual order Older Israeli government, legal and DTP systems lay out Hebrew by reversing the character order and then rendering left-to-right. The page looks correct, but the stored text is backwards. Extracting it gives you the sentence mirrored, and the bidi algorithm then reverses it a second time.
• TG-RTL-003 A mixed-direction run is not correctly ordered Hebrew sentences containing English product names, dates, percentages or citation numbers are the hardest bidi case. Producers frequently reverse the RTL and leave the LTR runs alone, or reverse everything.
• 01-005 Content is neither marked as Artifact nor tagged as real content Every 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 TG-RTL

Checkpoint TG-RTL covers right-to-left text and reading order (taggart extension). These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• TG-RTL-001 Right-to-left text is stored in visual order Older Israeli government, legal and DTP systems lay out Hebrew by reversing the character order and then rendering left-to-right. The page looks correct, but the stored text is backwards. Extracting it gives you the sentence mirrored, and the bidi algorithm then reverses it a second time.
• TG-RTL-002 A right-to-left run has no language declaration The document declares en-US at the catalog and never overrides it, so Hebrew paragraphs inherit English.
• TG-RTL-003 A mixed-direction run is not correctly ordered Hebrew sentences containing English product names, dates, percentages or citation numbers are the hardest bidi case. Producers frequently reverse the RTL and leave the LTR runs alone, or reverse everything.
• TG-RTL-005 Right-to-left punctuation or numerals are misplaced A full stop that renders at the left edge of a Hebrew line must be stored at the end of the logical string, not the beginning. Brackets must be stored as the logical opening/closing character, not the visually mirrored one.
• TG-RTL-006 Right-to-left storage order could not be determined Two signals decide whether a right-to-left line is stored in visual or logical order: the direction successive text-showing operations move across the page, and whether letters that only ever end a word are sitting at the ends of words. Some lines give neither — a line painted as one operation has no direction to read, and a short line may carry no position-locked letters. Those lines are listed here rather than counted as passing. A document whose remaining lines were all repaired but which still holds undecided ones has not been shown to be correct; it has been shown not to be provably wrong, which is a different claim.

Verified against a real document on 2026-09-10 . Last updated 2026-09-10 .