Description
This is a follow-up issue to PDFBOX-2250:
the xref repair algorithm simply searches for the nearest offset, which may fail if more than one xref table is present
...
Once we have a sample pdf which can't be parsed with the simple algorithm, we can open a new issue.
And here's one:
Exception in thread "main" java.io.IOException: Error: Expected a long type at offset 1180, instead got '50/Filter/FlateDecode/DecodeParms' at org.apache.pdfbox.pdfparser.BaseParser.readLong(BaseParser.java:1690)
That file does have more than one xref table.
Attachments
Attachments
Issue Links
- is related to
-
TIKA-1300 Switch default PDFBox parser to NonSequentialParser
- Resolved
- relates to
-
PDFBOX-2250 Improve XRef self healing mechanism
- Closed