[ https://issues.apache.org/jira/browse/PDFBOX-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15273772#comment-15273772 ]
Tilman Hausherr commented on PDFBOX-3340: ----------------------------------------- I noticed that too, I don't remember what issue, but it was an angry guy who wanted to print an invoice with a huge background. Sadly I couldn't come up with a better solution. > Image decoded twice without a real need > --------------------------------------- > > Key: PDFBOX-3340 > URL: https://issues.apache.org/jira/browse/PDFBOX-3340 > Project: PDFBox > Issue Type: Bug > Reporter: Petr Slaby > Priority: Minor > > Take the pdf from PDFBOX-1708, put a breakpoint into the class > CCITTFaxFilter, method decode() and run PDFToImage. You will see the debugger > stop twice, even if the pdf contains a single image. > The second call is arrives when the image is rendered to G2D, this is OK. But > for the first time, the image is decompressed in the constructor of > PDImageXObject - line 147 > {noformat} > this(stream, resources, stream.createInputStream()); > {noformat} > just to allow the filter (CCITTFaxFilter in this case) to provide additional > dictionary parameters in case something is missing in the input (COLORSPACE > would be set to DeviceGray if missing here). > I think this is a complete waste. The filter should be able to fix the > dictionary without having to decode the image. As far as I can tell, this > could be done by implementing a repair method on COSStream and on > implementations of Filter. > Also, I do not see that the stream created in the above mentioned constructor > of PDImageXObject would ever be closed. This seems to be a more general > issue. I have put a counter into COSInputStream.create(), there where it > creates new RandomAccessInputStream(buffer). With the testfile from > PDFBOX-1708, I end up with 3 unclosed streams when the program finishes. I am > not sure whether this is important, but I guess the unclosed streams are > uselessly occupying space in the scratch file. > Sorry if this is just lack of understanding of the code from my side, but I > could not resist to report what I see. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org