[Openicc] Linux CM ideology... ICC image map converter

[Chris Murphy]

On Feb 4, 2011, at 10:07 AM, Kai-Uwe Behrmann wrote:

> Am 04.02.11, 16:04 -0000 schrieb Richard Hughes:
>> On 4 February 2011 15:46, Jan-Peter Homann <homann at colormanagement.de> wrote:
>>> This "ICC image map converter" should transform both image maps for output
>>> to the monitor or for print out.
>> 
>> In GTK we use cairo for printing too. "Print preview" support would be
>> very easy to add.
> 
> "Print preview" needs to pass the print ICC profile to the preview window. I see that not adressed with your CUPS icc changes. Eigther the profile from the print dialog needs to be passed to Ghostscript and the print driver. Or the profile from CUPS needs to be transparent to the preview code. Otherwise the preview is fragile.

I would say it's problematic to literally pass the printer ICC profile to the preview window, because the data could be RGB or CMYK or deviceN, depending on the printer. It probably makes more sense to have GhostScript normalize the PDF to Display RGB first, then do the hand off. 

Example:

1.
Starting out with a PDF print spool file with various objects which are tagged with their respective source spaces, whatever they are, and there is also an OutputIntent which is a destination profile. The user would have chosen this either directly in the print dialog, or automatically inferred by CUPS using *cupsICCProfile in the printer's PPD, based on user settings.

2.
Ghostscript+lcms color manage the objects per the pdf canonical sequence (which is important, the order must be right, the blend spaces must be correct, etc) to the OutputIntent space, so now this still probably mostly vector PDF is color managed to the output intent but hasn't been fully rasterized.

3.
Now you have a PDF in a single normalized print space, which could be RGB or CMYK (or maybe deviceN). Now it needs both rasterization for display and also needs to be color managed for display.  This could be done in either order. But for performance reasons it's probably better to get the print file into Display RGB before moving it to a preview application. 

4.
Once in Display RGB, you could handoff to the preview application. It would be nice if the preview application could leverage Ghostscript for on-the-fly rasterization so the user has the ability to zoom into the print preview file and it looks nice and sharp, no jaggy text, etc. But if not, Ghostscript could raster a medium resolution version earlier in the chain then hand off to the preview app and it would probably be OK.

Another variation would be to fully color manage and rasterize it to print resolution, and then convert a "copy" of that to DisplayRGB redirected to the preview application.

Chris