Summary
After upgrading 2.8.1 → 2.12.0, text near the edge of rotated pages (/Rotate 90) is dropped from the output. On our documents this is a native-text stamp that courts overlay on scanned pages — it carries the signer, the case number, the validation code and the page number used for citations. The page body is unaffected.
Bisected to the version range that contains #412 ("Fix text clipping on rotated page edges"), and confirmed it is not #382: passing --keep-headers-footers does not bring the text back.
Measurements
Two rotated pages (/Rotate 90) from a 176-page scanned document, with their unrotated neighbours as controls:
| page |
rotation |
2.8.1 |
2.12.0 |
| 35 |
0 |
1258 chars |
1258 (identical) |
| 36 |
90 |
1299 |
997 |
| 37 |
90 |
3083 |
2852 |
| 38 |
0 |
1734 |
1734 (identical) |
Net −77 words. The controls being byte-identical rules out OCR nondeterminism — the difference is deterministic and comes from the parser.
Same two pages, asking only whether the stamp survives (lit parse with OCR, identical invocation):
2.8.1 pages 36-37: stamp present (2x, 4404 chars)
2.12.0 pages 36-37: ABSENT (0x, 3871 chars)
2.12.0 --keep-headers-footers pages 36-37: ABSENT (0x, 3871 chars) <- rules out #382
2.8.1 / 2.12.0 pages 35,38 (unrotated): present / present
Repro
I could not get a synthetic repro to trigger it, and I'd rather report that than hand you a file that doesn't show the bug. Two variants that do not reproduce (both motors keep the text):
- a two-page PDF, one page
/Rotate 0 and one /Rotate 90, with a horizontal (Td) text run hugging the left edge;
- the same, with the edge text drawn through a rotated text matrix (
Tm 0 1 -1 0), which is how the real stamp is laid out.
So "text near the edge of a rotated page" alone isn't the trigger. The real pages are scanned images with the native text stamp overlaid, so the image + native-text combination may matter.
The actual document is a court case file with victim and witness personal data, so I can't attach it publicly. Happy to send a redacted page privately, or to run any diagnostic build you suggest against it and report back — we have both engines set up side by side.
Environment
- liteparse 2.8.1 → 2.12.0, built from crates with
--no-default-features --locked
- PDFium prebuilt
chromium/7897 (unchanged across both)
- Linux x86_64, glibc 2.35
Summary
After upgrading 2.8.1 → 2.12.0, text near the edge of rotated pages (
/Rotate 90) is dropped from the output. On our documents this is a native-text stamp that courts overlay on scanned pages — it carries the signer, the case number, the validation code and the page number used for citations. The page body is unaffected.Bisected to the version range that contains #412 ("Fix text clipping on rotated page edges"), and confirmed it is not #382: passing
--keep-headers-footersdoes not bring the text back.Measurements
Two rotated pages (
/Rotate 90) from a 176-page scanned document, with their unrotated neighbours as controls:Net −77 words. The controls being byte-identical rules out OCR nondeterminism — the difference is deterministic and comes from the parser.
Same two pages, asking only whether the stamp survives (
lit parsewith OCR, identical invocation):Repro
I could not get a synthetic repro to trigger it, and I'd rather report that than hand you a file that doesn't show the bug. Two variants that do not reproduce (both motors keep the text):
/Rotate 0and one/Rotate 90, with a horizontal (Td) text run hugging the left edge;Tm 0 1 -1 0), which is how the real stamp is laid out.So "text near the edge of a rotated page" alone isn't the trigger. The real pages are scanned images with the native text stamp overlaid, so the image + native-text combination may matter.
The actual document is a court case file with victim and witness personal data, so I can't attach it publicly. Happy to send a redacted page privately, or to run any diagnostic build you suggest against it and report back — we have both engines set up side by side.
Environment
--no-default-features --lockedchromium/7897(unchanged across both)