Repository navigation
anydoc-wasm still ships pdf-inspector 1.14.2 — the RTL extraction fix (pdf-inspector#440) isn't included #170
Description
Cargo.lock on main pins pdf-inspector to 1.14.2:
[[package]]
name = "pdf-inspector"
version = "1.14.2"
That predates pdf-inspector#440 (merged 2026-08-21, fixed visual-order RTL text extracting character-reversed) and #441 (merged same window, fixed digit-only Arabic lines voting RTL and reversing). Both landed in pdf-inspector 1.16.0; latest is 1.19.0.
Concretely, @firecrawl/anydoc-wasm@0.2.4 (published 2026-08-27, after both fixes existed upstream) still reverses Hebrew/Arabic text stored in visual order, because the vendored engine predates the fix — pdf-inspector's own tests/fixtures/hebrew_visual_order.pdf / hebrew_logical_order.pdf both now extract correctly on pdf-inspector main, confirmed against the real fixtures in that repo.
Could you bump the pdf-inspector dependency to 1.16.0 or later and cut a new anydoc-wasm release? Evaluating anydoc for a PDF-to-Markdown use case and this is the blocker.
Activity
SEO-32: propose PDF to Markdown, English-only, RTL deferred
shlomsh commentedon Sep 15, 2026
Quick status, since this has been open a while:
pdf-inspectoris now at 1.20.0 (released today), and the RTL fix has been in every release since 1.16.0, so the only thing standing between users and correct Hebrew/Arabic/Persian output is the pin inCargo.toml.I opened #175 with the bump, the regenerated lockfile and the one snapshot that moves (it's the reversed Persian sample in
pdf/text.pdfcoming out right). Clippy andcargo test --lockedare green locally. If a republish of@firecrawl/anydoc-wasmcan follow, that would close this out.al-ashalash commentedon Sep 25, 2026
Two additions here, both measured today on Windows x64 against a generated three-line Arabic page (nothing attached — two commands reproduce it).
1. On "the RTL fix has been in every release since 1.16.0": that holds for letter order, but not for word boundaries in Arabic. Per-version table in #175: 1.16.0 through 1.21.0 get every letter right (CER 0.000 once spaces are removed) yet only 32% of the expected words survive intact, because the spaces land inside words. The output first matches the expected text exactly at 1.22.0 (CER 0.000), and 1.23.0 or newer is the safer target since #561 and #562 landed after it.
2. The stale pin is repo-wide, not wasm-only.
Cargo.tomlhaspdf-inspector = "1.14.2", andCargo.lockcarries exactly one entry for it —version = "1.14.2",checksum = "1e024ae2…", withlopdf0.42.0 — so all three workspace members (node,python,wasm) resolve through that single entry.npm i @firecrawl/anydoc@0.2.4on Windows x64 installsanydoc.win32-x64-msvc.node(7.9 MB) whose embedded build paths read…/registry/src/index.crates.io-…/pdf-inspector-1.14.2/src/extractorand…/pdf-inspector-1.14.2/src/markdown— so the native Node binary carries 1.14.2 too.extract_pages_markdownfrom pdf-inspector 1.14.2 installed on its own (same SHA-256 of the text once the BOM my shell added is stripped). CER 0.258 against the known text; the same page through 1.22.0+ gives 0.000..github/workflows/pages.ymlbuildswasm-pack build wasm --release --target webfrommainon every push and deploys it, so the public demo runs the same 1.14.2 behaviour.So bumping that single lock entry covers the crate, the three bindings and the demo in one change — and per the table in #175 the target wants to be 1.23.0+ rather than 1.16.0+.
fix(deps): update pdf-inspector for RTL text extraction fix
fix(pdf): bump pdf-inspector to 1.20.0 so RTL text extracts in logica…