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

English inside Hebrew: mixed-direction text lands wrong

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.

What a screen reader actually does

The English words inside a Hebrew sentence are announced in the wrong position, often at the far end of the sentence.

Why mixed direction is the hard case

Pure Hebrew stored in visual order is TG-RTL-001, and once you have detected it the repair is a string reversal. Mixed direction is harder in both halves of the problem.

Consider a line that should read, logically:

התקן ISO 14289 מגדיר מסמך נגיש

Rendered on the page, right to left, the eye sees the Hebrew flowing right-to-left with ISO 14289 as an island flowing left-to-right inside it. That island is the problem. Three things can be true of the stored bytes, and all three render identically:

1. Stored logically. Correct. Nothing to do.
2. Whole line reversed. The Hebrew is backwards and ISO is stored as OSI, 14289 as 98241.
3. Hebrew reversed, Latin left alone. The most common producer output, and the most deceptive: ISO 14289 extracts correctly, so a spot check on the recognisable token passes while every Hebrew word around it is mirrored.

Case 3 is why “I checked, the English looks fine” is not evidence.

What UAX #9 actually says

The Unicode Bidirectional Algorithm assigns every character a direction class. Three matter here:

• Strong — Hebrew and Arabic letters are strong RTL; Latin letters are strong LTR.
• Weak — European digits, currency signs, the decimal separator. They do not set direction; they take it from context but keep their own internal order.
• Neutral — spaces, most punctuation, brackets. They resolve to the direction of what surrounds them, and to the paragraph direction when they sit between opposing runs.

Two consequences follow, and both show up as bugs:

Digits inside RTL text keep left-to-right order. 4289 is stored and read 4, 2, 8, 9 even in a Hebrew sentence. A producer that reverses the line character-by-character breaks this, and it is the failure a reader spots first because a wrong number is wrong in any language.

Neutrals between an RTL run and an LTR run resolve to the paragraph direction. In a Hebrew paragraph, the space between ISO and 14289 is not between two opposing runs — Latin letters and digits are both effectively LTR here — so the two stay together. But the space before ISO, sitting between Hebrew and Latin, resolves RTL. Get that boundary wrong when repairing and ISO 14289 splits, with the pieces landing at opposite ends of the sentence.

What is in the file

There is no direction information in a PDF content stream. There are positioned glyphs:

BT /F1 11 Tf
  1 0 0 1 452 700 Tm (ןקתה) Tj       % "התקן", stored reversed
  1 0 0 1 398 700 Tm (ISO 14289) Tj  % Latin island, stored forwards
  1 0 0 1 300 700 Tm (רידגמ) Tj      % "מגדיר", stored reversed
ET

Each Tm places a run absolutely, so the file renders perfectly whatever order the runs are in. Extraction concatenates in paint order and gets a mixture of reversed and forward text — which is why the same file gives different wrong answers in different extractors, depending on whether they sort by paint order or by x.

How to check your own file free

Copy a Hebrew sentence containing a number out of the PDF and paste it into a plain text editor — one that does not run the bidi algorithm on display, or the second reversal will hide the first. TextEdit in plain-text mode is fine; a browser address bar is not.

Then look only at the digits. If a number you can verify from the rendered page comes out with its digits in the opposite order, the line was reversed character-by-character. If the digits are right but the Hebrew words are mirrored, you are in case 3.

The Hebrew final letters are the second test, and they need no numbers. Five letters — ך ם ן ף ץ — occur only as the last letter of a word. Paste a Hebrew paragraph and look at where they fall. In a correctly stored string they end words. In a reversed string they begin them, and every one of them is at a word start.

How to fix it free, in Acrobat Pro

Honestly: this one is painful without tooling, and you should know that before you start.

Acrobat has no facility for repairing character order. What it does have is /ActualText, and that is the right mechanism:

1. Open the Tags panel and find the element containing the affected text.
2. Right-click → Properties → Tag tab.
3. Type the correct sentence into the Actual Text field, in logical order — that is, type it the way you would type it normally in a Hebrew editor.
4. Repeat per element.

/ActualText replaces the extracted text for that element entirely, for every consumer: screen readers, copy-paste, and reflow. The glyphs on the page are untouched, so the appearance cannot change.

The cost is that you are re-typing the document. For a paragraph it is reasonable. For a 60-page report it is not, and this is the specific case where a service vendor’s per-page price starts to look sane.

How Taggart does it

Detection is structural, not linguistic. For each line, Taggart pairs the sequence in which runs are painted with their positions on the page, then asks whether those two orders agree for the script in question. A right-to-left line whose paint order runs left-to-right is stored visually. Hebrew final-letter positions are checked as an independent corroborating signal, and the two together are what produce a confidence figure rather than a guess.

Repair reverses the line, then reverses back each maximal left-to-right run — Latin letters and digits together with the neutrals between them, but not the whitespace on either side, so ISO 14289 survives as one token. A final pass un-mirrors brackets, and only where the pairing is actually inside-out: a ( that closes and a ) that opens is evidence of a mirrored store, whereas a correctly paired bracket in an RTL context is left exactly as it is.

The result is written as /ActualText on the structure element. No content stream is touched, and the output is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back.

The fix is not in the safe set. Taggart shows you the original string, the repaired string and its confidence, and waits for you to accept it — because a repair that is confidently wrong about a document’s language is worse than the defect it replaces.

How Taggart handles it

Taggart detects this condition automatically. It is reported as a warning, 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.

Where this sits in the standards

Related conditions

• 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-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.
• 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-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.

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-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.
• 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 .