[
https://issues.apache.org/jira/browse/PDFBOX-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385121#comment-16385121
]
ASF subversion and git services commented on PDFBOX-3340:
---------------------------------------------------------
Commit 1825814 from [~tilman] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1825814 ]
PDFBOX-3340: Sonar fix
> Image decoded twice without a real need
> ---------------------------------------
>
> Key: PDFBOX-3340
> URL: https://issues.apache.org/jira/browse/PDFBOX-3340
> Project: PDFBox
> Issue Type: Improvement
> Affects Versions: 2.0.8
> Reporter: Petr Slaby
> Assignee: Tilman Hausherr
> Priority: Minor
> Labels: optimization
> Fix For: 2.0.9, 3.0.0 PDFBox
>
>
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
