Reported by the customer: If ps-files (e.g. 'GW.ps') are rendered into CIELAB colorspace background is red. I used the following command-line: gswin32c.exe -P- -dBATCH -dNOPAUSE -Z: -sOutputICCProfile=lab.icc -r100x100 -sOUTPUTFILE=output.tif -sDEVICE=tiff24nc -dDEVICEWIDTH=2000 -dDEVICEHEIGHT=3000 -sICCProfilesDir=C:\Projekte\SVN\Colorasko\trunk\bin\gs_artifex\iccprofiles\ -c (GW.ps) run If additionally DefaultGrayProfile is set, the output is correct: gswin32c.exe -P- -dBATCH -dNOPAUSE -Z: -sDefaultGrayProfile=default_gray.icc -sOutputICCProfile=lab.icc -r100x100 -sOUTPUTFILE=output.tif -sDEVICE=tiff24nc -dDEVICEWIDTH=2000 -dDEVICEHEIGHT=3000 -sICCProfilesDir=C:\Projekte\SVN\Colorasko\trunk\bin\gs_artifex\iccprofiles\ -c (GW.ps) run Probably the initialisation of the gray-ICC-profile is not correct? I can't test this as none of my tiff readers will actually read the output, so worth double checking with the latest master code.
P2 as it's a customer issue.
Original report in e-mail subject "Re: Open issues for 9.03" on July 21 2011.
Updating this to P1 blocker since this has to be addressed before 9.04 release.
I have a fix for this and I am testing now. It is due to the DeviceGray color spaces that are used to initialize the graphic state. These are used during the fill page operation and so we end up using the old color mapping procs to go to RGB value of 255 255 255 which is a very bright red as a CIELAB value. The fix is to make sure that any remaps in DeviceGray force a proper install and conversion of the color space to an ICC gray type which then enables the use of a proper color conversion to the device values.
Fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=9d37cdcdbcb3b3bb23d0eab06d1683735303d5e1