[
https://issues.apache.org/jira/browse/PDFBOX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13950868#comment-13950868
]
Tilman Hausherr commented on PDFBOX-457:
----------------------------------------
I had another look at the file and tried to view it with several java open
source products, and they failed. One closed source product I won't name
succeeded, and gsview and pdf.js also succeeded.
I also traced through the filter and noticed that it had a wrong length. The
stream is encoded twice, and the ccitt filter comes second, but gets the
"/Length". This makes no sense and no other filter does this, so I deleted it
in rev XXX for the trunk and rev XXX for the 1.8 branch. (Will commit this
later)
However that wasn't the cause of the crash. I then compared the ccitt encoded
content with the content of what I get when converting the PDF with gsview to
PS and back to PDF and it looked like extra bytes at the beginning. After some
trying, I was able to decode the ccitt stream in debugging by positioning past
these 6 bytes: " 5d7&ยก" (20 35 64 37 26 A1). That is not a solution. To rule
out a java bug in "Inflate", I tested the original ZLIB library and I also get
the 6 bytes. I built a TIF from scratch containing the ccitt g4 stream and
could not display it with IrfanView (which uses libtiff), but could after
removing the 6 bytes. Same for JAI, when I tried to read the TIFF created with
the 6 bytes and saving it.
So it is very mysterious. I looked at the source of pdf.js and can't see a
retry logic.
https://github.com/mozilla/pdf.js/blob/master/src/core/parser.js
https://github.com/mozilla/pdf.js/blob/master/src/core/stream.js
That is an interesting piece of code, it handles all three CCITT compressions
with the same class. The code for GS is also available and similarly complex.
> PDF to Image doesn't show correctly the document
> ------------------------------------------------
>
> Key: PDFBOX-457
> URL: https://issues.apache.org/jira/browse/PDFBOX-457
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 0.8.0-incubator
> Reporter: Marcelo Tavares
> Assignee: Daniel Wilson
> Labels: CCITTFaxDecode, TIFF, ccitt
> Attachments: 580505.PR00003.000003.PDF,
> pdfbox-457-Scan_from_a_Xerox_WorkCentre_Pro.PDF, pdfbox-457-as_fax.pdf,
> pdfbox-457.PNG, testPDFToImage1.png
>
>
> I tried to convert the following document to image, but I got the attached
> result.
> It parsed just the text. I also tried different formats like JPG. I ran it
> using the PDFToImage class passing the document path as parameter.
> I've read that sometimes the document is not created respecting the PDF
> standard. But, is there a possibility to ignore it?! In fact, it's very
> important to me, so, could I use PDF Box despite of those "errors"?
> Thank you
> Marcelo
--
This message was sent by Atlassian JIRA
(v6.2#6252)
