fix(parser): recover root-bearing linearized xrefs - #435
Conversation
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Shadow auto-approve: would not auto-approve because issues were found.
Fix all with cubic | Re-trigger cubic
Guard short inputs, parse trailer dictionaries without mistaking comments or nested keys for /Root, bound trailer searches to the next xref table, and preserve amended /Prev chains.
Only retain the newest rootless table when its top-level /Prev offset points backward, and cover forward malformed chains with a regression test.
There was a problem hiding this comment.
All reported issues were addressed across 1 file (changes from recent commits).
Shadow auto-approve: would not auto-approve because issues were found.
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
Ignore comment text when locating the standalone trailer keyword and add a regression test for a root-bearing trailer following a commented placeholder.
There was a problem hiding this comment.
All reported issues were addressed across 1 file (changes from recent commits).
Shadow auto-approve: would not auto-approve because issues were found.
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 1 file (changes from recent commits).
Shadow auto-approve: would not auto-approve because issues were found.
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
There was a problem hiding this comment.
0 issues found across 1 file (changes from recent commits).
Shadow auto-approve: would auto-approve. Fix bug in xref table selection during repair for linearized PDFs with padded EOF; prefer root-bearing trailer to avoid zero-page result.
Re-trigger cubic
Problem
Issue #345's scanned PDF reports
page_count: 0and rejects conversion withOCR is required. The file is linearized and has more than 512 bytes of padding after its final%%EOF.The document has two classic xref tables:
/Rootand/Prev;/Rootin its own trailer.lopdf cannot find the final EOF through the padding, so container repair runs. The old repair selected the newest classic xref without inspecting its trailer. That loads the rootless final table, leaves the catalog unreachable, and produces a zero-page result even though the root-bearing table and its
/Prevchain are intact.Change
/Root, which also recovers the rest of the chain through/Prev.page_count == 0and now returns one text page containingHello World.The sample from the issue was also checked locally: it now reports four scanned pages (still requiring OCR) instead of zero pages.
Tests
cargo test --lib— 987 passed.cargo test --test integration_tests test_process_pdf_repairs_padded_linearized_xref_chain -- --nocapture— 1 passed.cargo clippy --lib -- -D warnings— clean.cargo fmt— clean.Fixes #345
Summary by cubic
Recover linearized PDFs with padded EOF by preferring a root-bearing classic xref and requiring standalone token boundaries for
xref/trailer. Previously repair always chose the newest classic xref and could pick a rootless final table, producing page_count: 0; now it selects the newest xref whose trailer has/Root, or keeps the newest rootless table only when its/Prevpoints backward, preserving revisions and restoring a reachable catalog./Prevpoints backward; rejects forward/Prevand falls back to the newest root-bearing table; keeps the newest valid table when no root-bearing trailer exists./Root, backward/forward/Prev, and keyword boundary checks; the sample in Could not convert this file: unsupported input: PDF has no extractable text (Scanned, 0 pages): OCR is required #345 now reports four scanned pages instead of zero.Fixes #345.
Written for commit 9ddc2a9. Summary will update on new commits.