You can clone with
HTTPS or Subversion.
The source of the issue we saw that was classified as: #17 (comment) has an embedded image that does not have any space between the end of the image data and the EI token. I pulled out the section of the PDF that was causing the failure and added the spec here: rstawarz@9601d33
Reading the PDF spec it seems the embedded image definition follows that of the stream objects (section 7.3.8) which is beautifully written as "There should be an end-of-line marker after the data and before endstream;"... the operative word being 'should be'.
I was going to change the buffer parser directly but you have specs in there that specify that an 'EI' should be allowed inside the image stream. Without implementing some sort of look ahead, it seems the two are mutually exclusive. Any thoughts?
Thanks for the spec and clear issue report.
Last year another user had a sample PDF that had the bytes 0x45 0x49 (EI) inside an inline image.
Your PDF and the earlier one seem mutually exclusive - I'm not sure what the best behaviour is.
No problem... this is the great world of the PDF Spec :)
My thoughts were to peek at the couple bytes AFTER the 'EI' end token to check for a start of the next token, but that would include ANY possible token I would think.
having a similar problem with a very specific accounting document...