[
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)