The customer reports and I've verified that the file MalliPDF-Ocelle.pdf renders very differently when output to a RGB device vs. a CMYK device using gs8.60 and gshead (r8285). The file is large, so it's on casper:/home/support/689512/MalliPDF-Ocelle.pdf The difference does appear on all computers/operating systems, but does happen on both peeves and casper. The command lines I used for testing: bin/gs -sDEVICE=tiff24nc -sOutputFile=rgb.tif -r30 ./MalliPDF-Ocelle.pdf and bin/gs -sDEVICE=tiff32nc -sOutputFile=cmyk.tif -r30 ./MalliPDF-Ocelle.pdf
That should be: The difference does NOT appear on all computers/operating systems, but does happen on both peeves and casper
This appears to be a transparency problem, probably related to the way GS uses the Device native colorspace as the blending color space (instead of using the /CS colorspace given in the transparency group attributes). I will attempt to trim this file down to a small example that still shows the problem. In the meantime, I will attach the complete customer file.
Created attachment 3535 [details] MalliPDF-Ocelle.pdf
FWIW, I can't see a difference between those two command lines on x86_64 linux or x86_32 MacOS.
Please try running the file on casper: bin/gs -sDEVICE=tiff24.nc -o test24.tif ./MalliPDF-Ocelle.pdf bin/gs -sDEVICE=tiff32.nc -o test32.tif ./MalliPDF-Ocelle.pdf See screenshot.png attached.
Created attachment 3928 [details] screenshot.png
transferring to Michael.
This renders properly with the softmask branch
This issue is not resolved with the soft mask branch. Head (r9784) still produces different output on casper.
Tried with r9948. Mac OS X 10.5.7 + Xcode 3.1.2: Reproduced. Windows XP Pro SP3 + VS2008 Express SP1: Not reproduced. Windows 2000 Pro SP4 + VS6 SP6: Reproduced. I don't know it relates, but when I tried to open this pdf file with Illustrator CS4, it complained that it found unknown type of fill. This (autocad-generated?) pdf file may contain its own flaws.
Created attachment 5392 [details] t8.pdf First, let me correct previous comment #10. This does reproduce on Windows XP Pro SP3 + VS2008 Express SP1 (or not, see below). The thing is this problem doesn't show up using GIMP. Attached is a PDF file created using Illustrator. It is a 10pt by 10pt size document and filled with a color (rgb=115,166,125) with 70% transparency. This is a imitation of color used in 'MalliPDF-Ocelle.pdf' named 'Erikoispinnoite'. I ripped this with following command. $ bin/gs -DBATCH -sDEVICE=tiff24nc -o t8r.tiff t8.pdf $ bin/gs -DBATCH -sDEVICE=tiff32nc -o t8c.tiff t8.pdf Resulted tiff files show same difference when using Apple preview 4.2 and Adobe PhotoShop CS4, but looks same when using GIMP 2.6. t8r.tif (rgb) has color value <9d c1 a4> and t8c.tif (cmyk) has color value <62 3e 5b 00>. Where 9d+62=ff, c1+3e=ff, a4+5b=ff. I don't think this is any problem of ghostscript, but an user error introduced by modern image viewing software's fancy color conversion.
Verified by customer that problem was solved.
Changing customer bugs that have been resolved more than a year ago to closed.