[
https://issues.apache.org/jira/browse/PDFBOX-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916260#comment-13916260
]
John Hewson commented on PDFBOX-1164:
-------------------------------------
LGTM
> 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
> 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.1.5#6160)
