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

Hebrew sentences that start with a full stop when extracted

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.

What a screen reader actually does

The reader announces punctuation at the start of sentences and mismatched brackets.

The symptom

You copy a Hebrew paragraph out of a PDF and paste it somewhere plain. Every sentence begins with a full stop:

.זהו משפט בעברית

Or a parenthetical comes out with the brackets facing outward, )כך(, closing where it should open.

Neither of these is a rendering problem. On the page the document looks perfect. It is what the file stores that is wrong, and it is wrong in a way that tells you something specific about how the file was made.

Why it happens

Sentence-final punctuation in Hebrew is drawn at the left end of the line, because a right-to-left line ends on the left. A producer laying out text by position rather than by logic sees a period at the leftmost x and stores it first, since first is what leftmost means in its model.

The same reasoning produces mirrored brackets. Unicode’s bidi mirroring means U+0028 LEFT PARENTHESIS is drawn as ‹)› inside right-to-left text — the character does not change, only the glyph. A producer that records the glyph it drew rather than the character it was given stores U+0029 where the logical text has U+0028, and the pair comes out inverted.

Both symptoms have the same root cause as TG-RTL-001: the run was stored in visual order. Punctuation is just the part of that failure you can spot without reading Hebrew, which is exactly what makes it useful.

What a screen reader does with it

Less than you might hope, and that is the problem. Most synthesisers treat a leading period as a pause or drop it silently. So the reader does not hear an obvious error — they hear a slightly odd rhythm, and sentence boundaries that fall in the wrong places.

Brackets are worse, because bracket depth is how a reader tracks parenthetical content when punctuation announcement is on. Inverted pairs mean a reader hears themselves entering a parenthesis at the point they should be leaving it.

Characters this actually covers

Hebrew’s own punctuation — geresh ׳ and gershayim ״ — is not mirrored and is not in scope. Neither is the maqaf ־, which is a hyphen, not a bracket. Flagging those would be the over-eager repair this condition is written to avoid.

How to check free

Paste a Hebrew paragraph into a plain-text editor that does not reapply the bidi algorithm on display, and look at the first character of each sentence. This takes ten seconds and needs no Hebrew.

If your editor does run bidi — most do — you will see the punctuation snap back to the correct-looking side, which hides the defect. In that case use a hex viewer, or a Python one-liner:

python3 -c "import sys; s=sys.stdin.read(); print([hex(ord(c)) for c in s[:12]])"

A 0x2e in first position on a line of Hebrew is a period at the start of the string.

How to fix it free, in Acrobat Pro

There is no punctuation-level repair in Acrobat, and there should not be — moving one character would leave the rest of the run in visual order. The fix is the same as for the underlying condition: set /ActualText on the structure element to the correct logical string, typed normally in a Hebrew editor.

1. Tags panel → find the element.
2. Right-click → Properties → Tag tab.
3. Type the sentence into Actual Text, with the punctuation where you would naturally type it.

Type the brackets as you normally would too. Your keyboard produces the logical characters; the renderer mirrors them. Do not go looking for a “reversed bracket” character.

How Taggart does it

Punctuation position is checked per run, and the result feeds two places. As a finding it is a warning under TG-RTL-005, with the page, the structure path and the offending characters. As a signal it raises the confidence on TG-RTL-001 for the same run — a run with mirrored punctuation and disagreeing paint-versus-position order is not a marginal call.

Repair happens as part of the logical-order rewrite rather than separately, so a run is never left half-corrected. The bracket pass is deliberately narrow: a bracket is only re-mapped when the pairing within the run is inside-out, and a correctly paired bracket in a right-to-left run is left exactly as stored. Getting this wrong in the confident direction would corrupt text that was fine, which is the one outcome that would make the tool untrustworthy.

Everything is written as /ActualText. No glyph moves, and the output is compared against the original at structural similarity ≥ 0.999 before it is returned.

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

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