Matterhorn TG-RTL-001 · PDF/UA-1 Taggart extension
Hebrew PDF reads backwards: visual order vs logical 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.
The condition, as the protocol states it. “A Hebrew or Arabic text run is stored in the content stream pre-reversed (visual order) rather than in logical order.”
Matterhorn Protocol 1.1, checkpoint TG-RTL, index TG-RTL-001, section Taggart extension. Software can decide this one on its own.
What a screen reader actually does
The screen reader announces the sentence backwards, word order and letter order both inverted. Numbers and embedded Latin words come out in the wrong place. This is the defining failure of Hebrew PDF accessibility and no mainstream tool detects it.
The failure nobody else checks for
Hebrew and Arabic are written right to left, but a PDF content stream has no notion of direction. It paints glyphs at coordinates, one after another. That leaves a producer two ways to lay out a right-to-left line.
Logical order. Store the characters in the order a human writes them, and paint them right to left — each successive text-showing operation moves to a smaller x coordinate. This is correct, and it is what a modern InDesign or Word export does.
Visual order. Reverse the characters first, then paint them plain left to right, like any Latin text. The glyphs land in exactly the same places. The page is indistinguishable. But the stored character sequence is the sentence spelled backwards.
Here is the same Hebrew sentence, stored both ways:
logical הנגשת מסמכים דיגיטליים היא חובה חוקית בישראל
visual לארשיב תיקוח הבוח איה םיילטיגיד םיכמסמ תשגנהThe second line is what a visual-order file contains. Extract its text and you get that. Feed it to a bidi-aware consumer — a screen reader, a browser, a search index — and the Unicode Bidirectional Algorithm reverses it again, on the assumption that it was logical to begin with. The result is neither.
What is in the file
The tell is in the content stream, and it is structural rather than statistical. A logical-order producer must walk leftwards across the line:
BT /F1 14 Tf
1 0 0 1 452 760 Tm <05D4 05E0 05D2 05E9 05EA> Tj % x = 452
1 0 0 1 398 760 Tm <05DE 05E1 05DE 05DB 05D9 05DD> Tj % x = 398, moving LEFT
ETA visual-order producer walks rightwards, like Latin text:
BT /F1 14 Tf
1 0 0 1 181 767 Tm <05DC 05D0 05E8 05E9 05D9 05D1> Tj % x = 181
1 0 0 1 235 767 Tm <05EA 05D9 05E7 05D5 05D7> Tj % x = 235, moving RIGHT
ETSuccessive text-showing operations moving to increasing x, on a line whose script is right-to-left, is the signature. It is not a heuristic about the words; it is a fact about how the file was written.
The second signal: Hebrew final letters
Sometimes an entire line is a single Tj, and paint order tells you nothing. Hebrew supplies its own answer.
Five Hebrew letters take a different form at the end of a word: ך ם ן ף ץ (kaf, mem, nun, pe, tsadi). They occur only there. Reverse a Hebrew string and every final form lands at the start of a word instead — a violation of the writing system that needs no dictionary to detect.
In םיכמסמ (the reversed form of מסמכים, “documents”) the final mem sits first. That cannot be Hebrew.
Taggart scores both the stored string and its reversal on final-letter placement and takes the better one as logical. Combined with the paint-order signal, it reaches 95% confidence on ordinary documents and says so on every finding.
How to check a file free, right now
By hand, in any PDF viewer. Select a line of Hebrew, copy it, paste it into a plain text editor that does not reorder text — TextEdit in plain-text mode, Notepad, or the address bar of a browser. If the pasted text reads backwards, the file is visual-order. This takes ten seconds and is completely reliable on a single line.
In Acrobat Pro. File → Export To → Text (Plain). Open the result. Same test, across the whole document.
With free command-line tools. pdftotext -layout file.pdf - from Poppler gives you the stored order. Compare a line against the page.
What you cannot do free is repair it. There is no setting in Acrobat that converts a visual-order document to logical order — the character sequence in the content stream is simply wrong, and Acrobat has no notion that it might be. The honest free fix is to go back to the source document and re-export it with a modern producer. If the source is gone, or the file came from a government portal, that option is gone with it.
How Taggart repairs it
Taggart reconstructs the logical order by applying the inverse of the Unicode Bidirectional Algorithm: reverse the line, then reverse back each run of Latin text and numerals so that ISO 14289-1 and 2014 survive intact rather than coming out as 1-98241 OSI. Mirrored characters — brackets, parentheses — are restored only when the stored pairing is actually inside out.
Then, crucially, it does not touch the content stream. The logical string is attached as /ActualText on the structure element covering the run:
13 0 obj
<< /Type /StructElem
/S /P
/Pg 8 0 R
/Lang (he-IL)
/ActualText <FEFF05D4 05E0 05D2 05E9 05EA ...>
/K [ 1 ]
>>
endobj/ActualText replaces the content for text extraction. Assistive technology announces it; the glyphs on the page are untouched. The remediated file renders pixel-identically to the original — Taggart’s appearance gate measures structural similarity of 1.000000 on this fix, because nothing that paints anything has changed.
Per-run /Lang is set at the same time, so a Hebrew paragraph is no longer announced by an English voice. That is TG-RTL-002.
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 right-to-left text to logical order. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.
Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.
Frequently asked questions
The PDF looks completely normal on screen. How can the text be backwards?
Because what you see and what is stored are two different things. A visual-order producer reverses the characters and then paints them left to right, so the glyphs land in the right places on the page. The page is correct. The stored character sequence is the sentence spelled backwards. Copy a line out of the PDF and paste it into a plain text editor — if it comes out mirrored, the file is visual-order.
Can this be fixed without changing how the document looks?
Yes, and it should be. Taggart never rewrites the content stream. It attaches the logical-order string as /ActualText on the structure element covering the run, which is exactly what ISO 32000-1 defines ActualText for: it replaces the content for text extraction while the painted glyphs stay byte-for-byte identical. The remediated file renders pixel-identically to the original.
Does Acrobat's accessibility checker catch this?
No. Acrobat checks that the text has a Unicode mapping, not that the characters are in the order a human wrote them. A visual-order Hebrew document with clean tagging, a document language and alt text on every image passes Acrobat's checker and PAC, and still reads backwards. This is why the problem persists in files that have already been through a remediation process.
Which files are most likely to have this?
Hebrew documents from older Israeli government and legal systems, anything produced by pre-Unicode DTP workflows, and scanned documents run through OCR engines that write text in visual order. Modern InDesign and Word exports are usually fine. The reliable test is the one Taggart automates: compare the order glyphs are painted in against their positions on the page.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint TG-RTL (Right-to-left text and reading order (Taggart extension)), index TG-RTL-001 |
| PDF/UA-1 (ISO 14289-1) | Taggart extension |
| WCAG 2.1 | 1.3.2 Meaningful Sequence — Level A |
| WCAG 2.1 | 1.3.1 Info and Relationships — Level A |
| EN 301 549 / Section 508 / ADA Title II | All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them. |
| IS 5568 (Israel) | Included in Taggart’s IS 5568 profile. Confirm the statutory scope for your obligation with a licensed מורשה נגישות — Taggart makes no legal determination. |
Related conditions
- 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-004 Reading order is not right-to-left aware Auto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.
- 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.
- 10-001 Character code cannot be mapped to Unicode A glyph is painted whose character code has no Unicode equivalent reachable through the font's ToUnicode CMap, encoding, or glyph names. The text renders correctly but cannot be extracted.
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-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-004 Reading order is not right-to-left aware Auto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.
- 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.
Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.
Verified against a real document on . Last updated .