Created attachment 7199 [details] type 7 shading example using XYZ colourspace These two ps files are updates of simple type 7 shadings in ABC colour spaces. The first uses the XYZ space as defined in the PLRM-3rd. I recently updated the second to use L*a*b* as output by lcms2’s psicc(1). In both cases, if you create a pdf using pdfwrite (and no other options), that pdf renders with significantly different colours than the ps. (And every pdf viewer I checked generated different different colours. Fun wow!) [sic] gs 9.0 and head/master generate similar pdfs.
Created attachment 7200 [details] type 7 shading example using L*a*b* colourspace
BTW: it is possible that neither of these do exactly what they intend, but the point for this bug is that pdfwrite creates pdfs which look vastly different than what the x11 and image backends display, suggesting that the ad hoc icc profile embedded in the pdf might not quite match. Or that the shading might be translated improperly into pdf syntax.
Having since learned of the options: -dColorConversionStrategy=/LeaveColorUnchanged -dPreserveSeparation=true -dPreserveDeviceN=true -dPreserveOverprintSettings=true I tried those. GS still renders the resulting pdf vastly differently than the source ps if the source uses a CIELab ABC space. The combination of a type 4 shading with: /XYZColors 3 dict def XYZColors begin % make current /RangeABC [ 0.0 0.9505 0.0 1.0 0.0 1.0890 ] def /RangeLMN [ 0.0 0.9505 0.0 1.0 0.0 1.0890 ] def /WhitePoint [ 0.9505 1.0 1.0890 ] def end translates correctly with those -d switches.
Created attachment 8446 [details] Type 4 shading XYZ space example which (mostly) works This ps, when converted with: ps2pdf -dColorConversionStrategy=/LeaveColorUnchanged -dPreserveSeparation=true -dPreserveDeviceN=true -dPreserveOverprintSettings=true trixyx.ps trixyz.pdf renders the same as the original ps in gs (9.05) or pspcl6 (master). The pdf, though, renders darker in mupdf (master) and evince (master; poppler and cairo also master; uses lcms2).
pdfwrite, in general, can't honour an arbitrary CIE colour space because PDF doesn't support it. For some kinds of shading it is possible to convert the end points into an ICCBased equivalent space and interpolate between, but in general we can't do this. So the only solution (and the same one I believe used by Distiller) is to render the shading to an image. When you do that with pdfwrite, the image colour space is given by the ProcessColorModel of the device, the default being RGB. Fundamentally this is a 'don't do that' gotcha and there isn't really any way around it (the Lab space *is* supported in PDF but its tough to spot that a given CIEBasedABC is actually the PDF Lab space). In future the colour management should do a 'better' job of this, but basically there is no way that pdfwrite can 'honour' (ie preserve) the CIE space. The reason for the different colour is due to the fact that at present the Ghostscript rendering and PDF output devices use different colour management strategies. Before you point it out, pswrite and ps2write do an even worse job and also don't preserve CIEBased spaces, even though they could. I intend to address that at some point too.
XYZ can trivially be specified via icc, so that shouldn't stand in the way of getting this right. And other cie based ps spaces should be easily converted, too. If it uses a table and interpolation, use that same table in the generated icc. If it uses a function, sample it. Doesn’t Michael’s code alreay generate icc profiles on the fly when needed? Why is it invalid to want to do that also for shadings, and then translate the shading as is?
(In reply to comment #6) > XYZ can trivially be specified via icc, so that shouldn't stand in the way > of getting this right. > > And other cie based ps spaces should be easily converted, too. I don't disagree that a CIEBased space can be converted to an ICCBased space, but I remain unconvinced that a mathematical operation generating a CIEBased colour at a given point will generate appropriate ICCBased components. > If it uses a table and interpolation, use that same table in the generated > icc. Yes *IF*. > If it uses a function, sample it. We could do that, But again I'm unconvinced that this would produce a better result than converting the shading to an image. > Doesn’t Michael’s code alreay generate icc profiles on the fly when needed? Yes, and pdfwrite doesn't currently use them. Fundamentally this is why you get different colours when rendering and when converting to PDF. > Why is it invalid to want to do that also for shadings, and then translate > the shading as is? I don't believe that this is possible in the general case, and the fact that Distiller does the same as we do is some evidence in that direction. Yes, probably we could do a 'better' job with some shadings, but given that shading dictionaries are fairly rare in PostScript, shadings in CIEBased spaces are rarer, and ones that aren't trivial cases (and already handled as such) are like hen's teeth, it seems we would be doing a lot of work to do a slightly better job on some cases that basically don't occur in the real world. I'd far rather expend the effort on getting proper colour management done.