[
https://issues.apache.org/jira/browse/PDFBOX-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996644#comment-13996644
]
Tilman Hausherr commented on PDFBOX-2070:
-----------------------------------------
I will change the filter classes to get rid of this bug.
The problem is that we can't satisfy the PDFBOX-2042 "A read operation must not
alter the pdf" rule easily because three filters do more than just decode the
stream, they return an altered dictionary. Which is breaking at least two
"Uncle Bob" rules :-(
In a first step, I will modify the code so that the decodeparms aren't altered
which should produce clean pdfs. Either I'll pass the filter index as a
parameter (as it is in 1.8), or I'll pass the decodeparms as a parameter.
> Filter.decode() modifies PDF if there is a filter array
> -------------------------------------------------------
>
> Key: PDFBOX-2070
> URL: https://issues.apache.org/jira/browse/PDFBOX-2070
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Tilman Hausherr
> Attachments: after.pdf, before.pdf
>
>
> If there are several filters (filter array) in an image, PDFBox is inserting
> an empty DecodeParms object here
> {code}
> params.setItem(COSName.DECODE_PARMS, getDecodeParams(params, index));
> {code}
> instead of either inserting an empty COSArray, or (better) do nothing. Saving
> such a PDF results in it not being displayable in the Acrobat Reader.
> Test code:
> {code}
> PDDocument d = PDDocument.load("before.pdf");
> new PDFRenderer(d).renderImage(0);
> d.save("after.pdf");
> {code}
> The rendering is important because without it, the filtered objects aren't
> decoded.
--
This message was sent by Atlassian JIRA
(v6.2#6252)