[PDFBOX-802] Better handle corrupt/missing %%EOF flags at the end of a file

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.3.1
• Assignee: Adam Nichols
• Reporter: Adam Nichols
• Created: 24/Aug/10 19:02
• Updated: 26/Oct/10 09:34
• Resolved: 24/Aug/10 19:57

Description

Currently, when the %%EOF flag at the end of the file is missing, an IOException is thrown which produces a stacktrace something like this:
java.io.IOException: Error: Expected to read '%%EOF' instead started reading '%%E^@'
at org.apache.pdfbox.pdfparser.BaseParser.readExpectedString(BaseParser.java:1090)
at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:463)
at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:179)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:859)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:826)
at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:751)

While these PDFs are non-conforming, it'd be an improvement to allow them to be read and processed since we're only a few bytes from the end of file anyway.

There's existing code which checks to see if what was read was %%EOF and throw an exception if %%EOF wasn't read and we're not at the end of file. However, this is never reached because readExpectedString() throws an exception before this can happen. To fix this, I changed readExpectedString() to readString() and left the manual check to see if the proper %%EOF flag was found. If not, it'll output a warning. If we're not at the end of the file, we'll still throw an exception. I've seen corrupted and missing %%EOF flags at the end of a file, but never in the middle. Since this doesn't seem to happen, if it does the PDF is clearly out of spec, and these issues would be much harder to deal with, throwing an exception still seems like a reasonable thing to do.

Issue Links

• relates to: PDFBOX-506 PDFBox can't parse PDF documents from jstor.org