[
https://issues.apache.org/jira/browse/PDFBOX-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-825.
---------------------------------------
Fix Version/s: 1.3.0
Resolution: Fixed
I added the code to solve the issue described in PDFBOX-705. You are right, it
doesn't work correct and the solution obviously accidently worked for
PDFBOX-705.
Revision 996309 solves both issues PDFBOX-705 and this one.
> Wrong opacity for images with indexed color space
> --------------------------------------------------
>
> Key: PDFBOX-825
> URL: https://issues.apache.org/jira/browse/PDFBOX-825
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
> Affects Versions: 1.3.0
> Reporter: Timo Boehme
> Fix For: 1.3.0
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> In class PDPixelMap used to decode images the handling of opacity for images
> with color space PDIndexed is wrong.
> Test PDF: http://onlinelibrary.wiley.com/doi/10.1002/ajh.21765/pdf
> (or another PDF with image and color space /Indexed)
> Picture Im2 at page 4 of the test PDF is empty (all pixels white).
> The reason:
> In PDPixelMap at line 205 (rev. 988513) an opacity variable is set depending
> on first value of Decode parameter.
> This parameter often is not specified (null) and default value is [0, 2^n-1].
> Thus the code:
> boolean isOpaque = (decode != null && decode.getInt(0) == 1) ? true : false;
> sets isOpaque to false, resulting in all white pixel.
> Exchanging 'true' and 'false' would help but I even can't imagine why a first
> value of '1' should
> be interpreted as an opacity parameter? Am I missing something (some kind of
> workaround)?
> If there are no good reasons for keeping the opaque parameter I would propose
> removing it and setting alpha to 0xff in every case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
