[ https://issues.apache.org/jira/browse/PDFBOX-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925689#comment-13925689 ]
Timo Boehme edited comment on PDFBOX-1164 at 3/10/14 12:06 PM: --------------------------------------------------------------- I have to beg pardon that I haven't commit this fix when getting a committer. Thanks for doing it. was (Author: tboehme): I have to bag pardon that I haven't commit this fix when getting a committer. Thanks for doing it. > Inline image parsing error causes RuntimeException + FIX > -------------------------------------------------------- > > Key: PDFBOX-1164 > URL: https://issues.apache.org/jira/browse/PDFBOX-1164 > Project: PDFBox > Issue Type: Bug > Components: Parsing > Affects Versions: 1.7.0 > Reporter: Timo Boehme > Fix For: 1.8.5, 2.0.0 > > Attachments: PDFStreamParser.diff > > > Inline images start with BI operator, followed by some parameters and ID > operator. Then the binary image data with a trailing EI operator follows. The > problem is the detection of the EI operator. The current code in > PDFStreamParser requires the operator to be surrounded by whitespaces. > However I have a document where the sequence EI with preceding 0x09 and > following 0x20 occurs in the image data. Thus PDFBOX wrongly assumes the end > of image data and the parsing later fails with a RuntimeException (from > PDFStreamParser#getTokenIterator - this should be changed to throw > IOException; will file another issue) because the following binary data is > interpreted as operator. > In earlier versions a heuristic was used to test the expected byte count of > the image to circumvent this problem, however it was disabled because the > data could also be compressed. > To fix the problem I have added a test involving the following X (with X=5) > bytes after the 'WS EI WS'. In order to treat the EI as operator all of the > bytes must be printable ASCII characters because it can only be followed by > PDF operators. If 5 bytes are too many because a comment with non ASCII > character could follow this could be reduced to 3 bytes which in most cases > should be enough. > Diff of fix is added to this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)