[Parsing] Wide table rows are truncated on the right: nine columns emitted as four, dropping row totals

Description

On a dense financial table, projected text lines are truncated on the right: a nine-column row is emitted with only its first four columns, and the remaining values — including the row total — are silently dropped.

This is not a case of the page being skipped or under-extracted. LiteParse produces more total text for the page than pypdf does (4,667 vs 1,854 characters), so the loss is invisible to any size- or page-count-based check. The row simply looks like a shorter table.

Disclosure: I'm not a Rust developer and found this while evaluating LiteParse against pypdf for a personal NZX/ASX equity-analysis project. I used Claude (Anthropic's AI assistant) to isolate the reproduction and check it across versions. I have not attempted a fix — projection.rs is heavily tuned heuristic geometry and I have no way to check a change for regressions against your corpus.

Document

BHP's Economic Contribution and Payments to Governments Report 2025, a public ASX filing (36 pages, portrait A4 595×842). Page index 25 (0-based) holds a wide "payments to governments by country" table.

Direct download: https://cdn-api.markitdigital.com/apiman-gateway/ASX/asx-research/1.0/file/2924-03122145-3A699003

Expected Output

The United States row of that table has nine value columns. pypdf recovers them:

United States 106.2 – 106.2 – 0.5 – 106.7 3.3 110.0

Actual Output

LiteParse emits the first four columns only. 106.7 (a subtotal) and 110.0 (the row total) are absent from the page text entirely:

United States                                                 106.2                                                                  -        106.2

Verified by substring search on the page text:

page 25 contains "106.2"? True | "106.7"? False | "110.0"? False

Across the whole document, 106.7 appears on pages 3, 5, 25 and 26 per pypdf, but only on pages 5 and 26 per LiteParse. Page 3's instance is a large display figure in an infographic (US$106.7bn); page 25's is the table cell above.

Command Used

from liteparse import LiteParse

t = LiteParse(ocr_enabled=False, quiet=True).parse("bhp-economic-contribution-2025.pdf").pages[25].text
print("106.7" in t, "110.0" in t, len(t))   # -> False False 4667

LiteParse Version

2.14.3 (Python wheel).

Also reproduced identically on:

• 2.11.0 — so this is not the edge-drop regression described in #416; the behaviour predates 2.12.0.
• PR #392 build (2.13.1, artifact wheels-x86_64-pc-windows-msvc from commit 6c96a22) — unchanged, byte for byte.

Operating System

Windows 10 (x86_64), Python 3.13.

Additional Context

Configuration made no difference. Each of the following produced byte-identical output (4,667 characters, same truncated row):

The page reports its dimensions correctly (595 × 842, matching the PDF mediabox), so this doesn't appear to be a geometry-detection problem.

Why this shape of failure seems worth flagging: in a financial table the right-hand columns are usually the totals, so the dropped values are the most consequential ones on the row — and because the row still renders as a well-formed, plausible-looking table, there's nothing to indicate anything is missing. A merged or mangled row is self-evidently wrong; a truncated one is not.

I also have a separate reproduction of borderless side-by-side tables being merged into shared projected lines — related in spirit to #414/#392, but those cover ruled grids, and the PR #392 build does not change the borderless case. Happy to open that separately if it's useful rather than noise.