[Syamjith-NK]

AI disclosure, per CONTRIBUTING.md: this change and this description were written with AI assistance (Claude Opus 5, via Claude Code). Every measurement quoted below was run on my machine and checked before opening this.

Problem

extract_text() returns Arabic-Indic digits in reverse order. ١٢٣٤ (1234) comes back as ٤٣٢١ (4321), and Extended Arabic-Indic (Persian) digits ۱۲۳۴ do the same.

I checked the files were correct before blaming the extractor. I rendered the same strings to an image and looked at the result: the glyphs are drawn left to right as 1, 2, 3, 4. It reproduces with two unrelated producers (matplotlib and fpdf2), and on a line containing nothing but digits, so no direction heuristic is involved. PyMuPDF extracts the same files correctly.

Cause

U+0660-U+0669 and U+06F0-U+06F9 fall inside the ("֐", "ࣿ") entry of RTL_CHARACTER_RANGES, so is_char_rtl() returns True for them. In _text_extraction/__init__.py the neutral check runs first and keeps insertion order; anything that falls through to the RTL branch is prepended, so a digit run comes out reversed.

Fix

Add the two numeric ranges to NEUTRAL_CHARACTER_RANGES. Under the Unicode bidirectional algorithm digits are weak types (AN/EN) and a digit run is not reordered inside an RTL paragraph, so this is decidable from the standard rather than a matter of taste.

is_char_rtl() itself is untouched, so the other caller (generic/_appearance_stream.py) is unaffected.

Scope

Deliberately narrow. This does not settle #1629, which is about where a digit run sits relative to the surrounding Arabic text. That question is untouched here. Arabic and Hebrew letters keep reversing exactly as before, and the new test asserts that so it cannot regress silently.

Test

The test builds its page from a Type0/Identity-H font with a ToUnicode CMap, so it adds no binary fixture and depends on nothing but pypdf.

• With the fix: 5 passed.
• Without the fix: the 3 digit cases fail, the 2 letter cases pass. So it really tests this change.
• No existing test contains an Arabic-Indic digit, so nothing was asserting the old behaviour.

Full suite on this branch: 1717 passed, 34 skipped, 2 xfailed, 0 failed. ruff check . clean on the pinned 0.16.0, mypy clean on both changed files, all pre-commit hooks pass. The single xpassed in that run (test_issue_2336) also xpasses on unmodified main.

Before and after on real generated files:

input	before	after
١٢٣٤	٤٣٢١	١٢٣٤
۱۲۳۴	۴۳۲۱	۱۲۳۴
٥٠٪	٪٠٥	٥٠٪
سنة ٢٠٢٦	٦٢٠٢ سنة	٢٠٢٦ سنة (digits correct, run order still #1629)
plain Arabic, plain Hebrew	unchanged	unchanged

Happy to rename the constant or narrow the range to ٠-٩ if you would rather not include the numeric separators.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.12%. Comparing base (d26df36) to head (de0a35d).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4077   +/-   ##
=======================================
  Coverage   98.11%   98.12%           
=======================================
  Files          59       59           
  Lines       11489    11475   -14     
  Branches     2150     2143    -7     
=======================================
- Hits        11273    11260   -13     
  Misses        122      122           
+ Partials       94       93    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.