[
https://issues.apache.org/jira/browse/PDFBOX-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13915170#comment-13915170
]
Tilman Hausherr commented on PDFBOX-1164:
-----------------------------------------
I assume you are running your own version with the change but wanted another
opinion before committing and then maybe forgot about it. The change makes
sense. I have set it for myself now, and will let it run for a week or two. I
still haven't had the time to merge Johns changes in my own version, but after
that I will make diff tests for about 100 files, and if all is good I'll commit
your change.
> 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)
