fix: recover from a corrupted startxref pointer

[MADENIYOU]

Fixes #228.

Summary

A PDF whose startxref pointer has been corrupted to point at the wrong byte offset — a single flipped digit, which is what damaged writers emit in the wild — was entirely unprocessable: every entry point (classify_pdf, extract_pages_markdown, process_pdf) raised Invalid PDF structure, even though the file's object data, real xref table, and trailer were all completely intact just past the wrong pointer. Both pypdf and pdfium recover from this by locating the real table directly instead of trusting the pointer; lopdf doesn't.

Fix

Added a new repair candidate alongside the existing missing-%%EOF-marker and stripped-leading-bytes repairs already in repair_pdf_container_candidates: scan the buffer for the real, standalone xref keyword and append a corrected trailing startxref/%%EOF block. lopdf's own get_xref_start always reads the last %%EOF in the final 512 bytes of the buffer and the startxref value immediately before it, so the appended block transparently supersedes the corrupted one already in the file — no in-place byte surgery on content the original writer produced.

Scoped to classic (non-stream) xref tables, matching the reported repro and the common case. A corrupted pointer into a cross-reference stream (N 0 obj << /Type /XRef ...>>, used by some PDF 1.5+ writers instead) would need the containing object's number, not just a byte offset — out of scope here, happy to follow up separately if useful.

Verification

Reproduced the issue's exact repro (a valid one-page PDF, then corrupt the startxref offset to point at the wrong byte):

	Before	After
process_pdf / classify_pdf / extract_pages_markdown	Invalid PDF structure on all three	Loads correctly
Extracted text	n/a (unprocessable)	"Order Detail Report by Account", "WIDGET ASSEMBLY", the dollar amount — all present
Page count	n/a	1 (correct)

Added a regression test using a fixture built the same way as the issue's repro script.

Testing

• cargo test: 859 tests pass (1 new)
• cargo clippy --all-targets -- -D warnings: unchanged at 28 pre-existing/unrelated errors versus main

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Recover PDFs with a corrupted startxref by scanning for the real classic xref table and appending a correct trailer. The scan validates the table header (including count termination) and runs in a single reverse pass, fixing “Invalid PDF structure” errors in process_pdf, classify_pdf, and extract_pages_markdown.

• Bug Fixes
  • Add a repair path that finds a standalone classic xref (with a valid <start-id> <count> header) and appends startxref/%%EOF, ensuring lopdf uses the corrected trailer.
  • Reject coincidental tokens and malformed headers (e.g., standalone “xref” without a header, “xref” inside startxref, or a count with trailing garbage like xref\n0 6garbage) to avoid false positives.
  • Use a single reverse scan (O(n)) for better worst‑case performance.
  • Applied to both the original and stripped buffers. Added regression and unit tests. Classic tables only (no xref streams). Behavior matches pypdf/pdfium.

^{Written for commit 4a03110. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 3 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[MADENIYOU]

Both confirmed and fixed.

P2 — trusting any standalone "xref" unconditionally: Added `looks_like_xref_subsection_header`, which confirms a plausible classic xref subsection header (` `, e.g. "0 6" — the shape every real table starts with) actually follows the candidate token before accepting it. The scan now walks backward until it finds a token that both stands alone and validates, instead of accepting the first (rightmost) standalone match unconditionally.

P2 — quadratic worst case: Rewrote as a single reverse byte-index walk — O(n) regardless of how many false candidates get rejected along the way, instead of re-invoking windows().rposition() on a shrinking prefix per failed candidate.

Added direct unit tests on the byte-level scan rather than trying to construct an adversarial full PDF for the coincidental-match case — that scenario can't actually be represented in a PDF-level integration test anyway, since reportlab (and most real writers) compress page content by default, so a literal "xref" word in visible text never appears as raw bytes in the file. Tests cover: a coincidental standalone "xref" with no subsection header is rejected; a real classic table is found; a coincidental match positioned after the real table doesn't shadow it; "xref" as a substring of "startxref" still doesn't match.

Full suite: 863 tests passing (5 new), clippy unchanged at the same 28 pre-existing/unrelated baseline. The original #228 repro is unaffected — reverified manually alongside the existing integration test.

[cubic-dev-ai]

All reported issues were addressed across 1 file (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[MADENIYOU]

Confirmed and fixed in the latest commit.

P2 — count run not bounded: looks_like_xref_subsection_header checked that a digit run followed the whitespace separator, but never verified where that run ended. A coincidental xref\n0 6garbage in stream/literal content had the right shape (digits, whitespace, digits) and would validate, letting the recovery repair against a bogus offset. Now requires the count run to end at whitespace or buffer-end.

Added find_xref_rejects_count_run_with_trailing_garbage covering exactly that shape. Full suite: 869 tests passing (1 new), clippy clean on the changed file (pre-existing unrelated failures remain in src/tables/grid.rs, untouched by this PR).