Created attachment 7578 [details] the PDF that fails When using ghostscript to break up the attached PDF into PNG images, corresponding to each page, the colors on the cover page get distorted. This seems to be a regression bug, as it works fine in version 8.71, but fails in 9.02. I'm using the following switches when invoking gs: $cmd = GS_BINARY_PATH." -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dUseCropBox -sOutputFile=$folderBase/full/image-%d.png -r100 $folderBase/pub.pdf"; Tested on both MacOS and CentOS, with the same result.
Created attachment 7581 [details] Simplified sample file. Changing the color space in 12 0 obj to /DeviceRGB or /DeviceGray has dramatic effect on Ghostscript but no visible effects on AR9 or Evince.
Alex, What do you mean "changing" the color space in 12 0 obj? I went in and did the change from DeviceCMYK to DeviceGray and DeviceRGB in the PDF file and AR no longer opens the file. I also ran your simplified file as it stands and it looks fine to me. Could you clarify what the simplified file is showing? If you change the color space 12 0 I would expect to see some changes as it changes the transparency group color space.
With the simplified file bug692265_simple.pdf the file will render properly to a CMYK based device (e.g. tiff32nc) but not to an RGB based device (e.g. tiff24nc) this is regardless of the antialiasing parameters nor the multipage output settings the user reported on the command line. The simplified file consists of an image and a softmask with a path fill. The source of the problem is that there appears to be some color space confusion with respect to the transparency groups.
So this is a strange one. I have found that the color conversion that is done on a transparency buffer to go from CMYK to RGB is giving the wrong result. The input data coming in seems to be fine. The output is the weird colors that we see in the simple file. I am a bit surprised to see this as we should have files in the regression tests for this case. Need to see when exactly this broke.
I've run a git bisect here, and ended up with: There are only 'skip'ped commits left to test. The first bad commit could be any of: 33bf32d870238e3c9cfe579a3c6ed972dbea9b36 7a2f7d30a69eab7e7a9c51d0f7448826fc1a8d18 84b537fb34b4833c88cc4865b4240209c0d686da 079c0dae622177a294a35738da791aabb6c6db24 dbfbed3ca3306d7b03bc7ea0941001bc086fff94 6398f5075a1c01ff5786c22fecd79da1204cbf1e b2d5e2d05af74df972264f00a8fb8942c097d477 53de3134eb5fd985702d4eee6a8cec66242f2192 83c064513eefd7294137d3330fdcef462b1a6d1f 01e002de8cb4c26faa325d991a1ed7e40062ce66 9bd9651cdd38c44715cf4450f2ad91b212c5989a 0d252b58996a5656f70a481e50166ed48694e12c a598a94e370aaa64801c66dce95da8e7e469b097 7a826cf9ff63b9d1b130e1a998aacacd554228c5 cfaf3f316094840084e2f47186f79b26af2b68a3 2280b46be4e1188d41925f1e75ca9ff18110114d aa28c8a85ef51bd6918005e9197978501796037b 258218da2159b713f091db29a08add3f32ab7647 f150cacec91d2f4ee2ba09622a07262a1c9ce024 06ad4e08c3b22c6254c4af099a7dc96b2c21aa15 175e1012a314989daa18e0063a613ec3759408d9 659e5fbfacef0fb9e8015ab16e4576914bb86514 ac8592d708a104da025c60f664ed9e3482ebe6d1 5f74e7609c444de2ee0f15dada8a99e3c0903429 91021d89d7ec667e573a7f7a9c2e6f0f2cb5bc84 f287286c7efde68e5d2a63e01a19620df17bea25 We cannot bisect more! During the course of the bisect, I had compile failures at various stages (and so needed to skip those), and had SEGVs on this file. I *think* that this block represents all SEGVs, but I have not confirmed that yet.
Using gentoo’s mildly patched version of gs 9.02 and the x11alpha device, I get the wrong colours with: :; gs -dBATCH -sDefaultCMYKProfile=default_cmyk.icc ic.pdf but get the correct colours with: :; gs -dBATCH -sDefaultCMYKProfile=ps_cmyk.icc ic.pdf With my compile of ghostpdl git and pspcl6, -sDefaultCMYKProfile doesn't seem to change anything, but soft linking ./default_cmyk.icc to the other profile files does. With that in place, I tried a few other, real CMYK profiles; those had the same type of issues with that pdf as gs’s default_cmyk does. Only ps_cmyk rendered that pdf properly. Even weirder, specifying a different rgb profile also fixed the rendering, such as: :; gs -dBATCH -sDefaultRGBProfile=/usr/share/color/icc/Display_Profiles/AdobeRGB1998.icc ic.pdf :; gs -dBATCH -sDefaultRGBProfile=/usr/share/color/icc/sRGB/sRGB_type2.icc ic.pdf (Adjust paths as needed. And notice that the second one is an sRGB profile.) This also works fine: :; gs -dBATCH -sDefaultRGBProfile=ps_rgb.icc ic.pdf It seems that the bug only happens with the combination of a measured cmyk profile (including your default_cmyk.icc) and your default_rgb.icc. Maybe that will help narrow it down? mupdf (also git master) had no problem with it.
I seem to have lost a bit of text while editing.... please s/with that in place,/with that in place, pspcl6 gives the same results as the system gs does with -sDefaultCMYKProfile./
Ah. Good catch on the profile differences. This points me to the issue which is that the profile used during the softmask rendering is remaining around during the transparency group pop. I will dig into this.
Fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=03bce08fdcb15702abf4cafbe8723dc8b9b7bd6f