[Openicc] Printing Plans GhostScript / sRGB / ICC

Chris Murphy lists at colorremedies.com
Thu Mar 3 11:04:10 PST 2011



On Mar 3, 2011, at 12:03 AM, Kai-Uwe Behrmann wrote:
> And thats why it was suggested to consider DeviceRGB without OutputIntent as sRGB. Michael stated that Ghostscript will behave this way and as stated by Chris its in line with Mac OS and Windows. So non smart apps are colour managed by the opt-out policy. Honestly I hope, similiar to Hal, that CM aware apps will soon embedd the OutputIntent and we are almost done.

The CPD could add it for apps that write PDF spools, but do not have a means of setting OutputIntent (they'd have to look at *CUPSICCProfile in the PPD, or they'd have to subscribe to some service that does this for them like colord, or Oyranos, etc.)

However, a point on /DeviceRGB = sRGB when there is no OutputIntent. This is the case on Mac OS and Windows, but the actual net effect on Windows is /DeviceRGB = /DeviceRGB to the display, because on Windows the default display profile is sRGB. Windows is in a cockamamie situation where it does not build ICC display profiles from display EDID on the fly, like Mac OS does.

So in reality, there is a rather significant departure in the total user experience between Mac OS and Windows, even if the printed output ends up being (theoretically) the same.

Another problem with /DeviceRGB = sRGB when there is no OutputIntent is with PostScript and PCL generation with pdftops and pdftopcl. How do you communicate /Device = /Device vs /Device = sRGB in such a case?

Anyway, this is getting sufficiently confusing that we're going to have to flow chart it.


Chris Murphy


More information about the openicc mailing list