This continues a long story about the "background" color in re-distilled 0.pdf . Acrobat renders it differently with 0.pdf and with 0.pdf re-distilled by Ghostscript. It looks as now I know the bottom of the problem : the conversion of CalRGB to ICCBased appears non-identity. I need Dan's help to understand why so, because my knowledge of those color spaces is poor.
Created attachment 368 [details] 0------.pdf 0------.pdf is a reduced 0.pdf . It contains 2 paths, one of them is a rectangle. I could not reduce it more with Acrobat - the effect is missing when I remove the curved path.
Created attachment 369 [details] unpacked-0------.pdf unpacked-0------.pdf is 0------.pdf with unpacked streams made with Peter's utility. Unfortunately Adobe can't read it. But it is useful for human reading. Ghiostscript can read it.
Created attachment 370 [details] cur.pdf cur.pdf is 0------.pdf re-distilled with Ghostscript. It renders differently than 0------.pdf in both Adobe and Ghostscript. I believe that only significant difference is CalRGB converted to ICCBased. So the convertion isn't identity.
I mean the rectangle is rendered yellow in the re-distilled file, and white in the source file. Dan, please help to debug that.
The worker is the function pdf_convert_cie_to_iccbased in gdevpdfk.c .
Igor, I had also started looking at this problem last night. I agree that the problem is that the CalRGB color space is not being correctly converted into an ICC based color space. I do not know why. I will look at the problem im more detail.
Fix for 687020 and 687146. The pdfwrite device is incorrectly converting CalRGB color spaces into ICC color spaces. Fix #1. Details: As Raph pointed out in the Wednesday's support call, there are actually two problems. 1. We were not correctly recognizing that we can use a CalRGB color space for the output. This patch corrects this problem. One of the tests in that process was assuming an incorrect ordering to the transforms. This fix corrects this problem. 2. The ICC color space which is being created is not equivalent to the original CalRGB color space. This results in differing colors between the original file and the output PDF file. This problem is still open. Note: I am leaving these bug reports still open since problem 2 is still open. Dan Index: src/gdevpdfc.c =================================================================== RCS file: /cvs/ghostscript/gs/src/gdevpdfc.c,v retrieving revision 1.41 diff -u -d -r1.41 gdevpdfc.c --- src/gdevpdfc.c 11 Nov 2003 11:23:17 -0000 1.41 +++ src/gdevpdfc.c 21 Nov 2003 01:42:17 -0000 @@ -144,21 +144,22 @@ private cie_cache_one_step_t cie_cached_abc_is_one_step(const gs_cie_abc *pcie, const gs_matrix3 **ppmat) { - /* The order of steps is DecodeLMN, MatrixLMN, DecodeABC, MatrixABC. */ - if (CIE_CACHE3_IS_IDENTITY(pcie->caches.DecodeABC.caches)) { + /* The order of steps is, DecodeABC, MatrixABC, DecodeLMN, MatrixLMN. */ + + if (CIE_CACHE3_IS_IDENTITY(pcie->common.caches.DecodeLMN)) { if (pcie->MatrixABC.is_identity) { *ppmat = &pcie->common.MatrixLMN; - return ONE_STEP_LMN; + return ONE_STEP_ABC; } if (pcie->common.MatrixLMN.is_identity) { *ppmat = &pcie->MatrixABC; - return ONE_STEP_LMN; + return ONE_STEP_ABC; } } - if (CIE_CACHE3_IS_IDENTITY(pcie->common.caches.DecodeLMN)) { + if (CIE_CACHE3_IS_IDENTITY(pcie->caches.DecodeABC.caches)) { if (pcie->MatrixABC.is_identity) { *ppmat = &pcie->common.MatrixLMN; - return ONE_STEP_ABC; + return ONE_STEP_LMN; } } return ONE_STEP_NOT;
Note on the second problem: "2. The ICC color space which is being created is not equivalent to the original CalRGB color space. This results in differing colors between the original file and the output PDF file. This problem is still open." The ICC color space is being clipped due to values needing to exceed 1.0. This is going to require some changes in the current implementation since the 1.0 clamp limit is built into the conversion to the 'frac' type.
*** Bug 687020 has been marked as a duplicate of this bug. ***
Getting rid of 'frac' types (making it a long), now that 32-bit CPU's are the common case would probably be of value, but this is not a customer issue, so dropping it to P3
Reassigning to current "owner"
This issue will be addressed when the ICC branch is merged in to the trunk. In that branch, CalGray and CalRGB are properly mapped to ICC color spaces.
With the current ICC color management there is no difference between the files. Closing.