[Printing-architecture] [Printing-summit] Print Dialog:PreviewProcessing: Only A Question

[Petrie, Glen]

Thanks for clarification on the color management side of things.  My
concern is a little different, and is about whether or not Ghostscript
will dither/halftone the image independent or in connection with of CM.
But, if I understand correctly, Ghostscript will only dither/halftone if
requested.  So, for the case I was describing, the printer driver will
do the dither/halftoning along with conversion from color-to-inks and
print control language stuff.

This sounds like a good approach; printer drivers may not (maybe they
should not) worry about the complexities of CM; there are better
applications, filter, processes for that.  Printer driver, however,
should and need to focus on dither/halftone and color-to-inks processing
that is device dependent anyway.

Back to preview; the preview cares (may care) about the CM but
won't/can't care about the dither/halftone.  (I won't get into how
dither/halftone may affect the CM!!!).


glen


> -----Original Message-----
> From: ralph.giles at artifex.com [mailto:ralph.giles at artifex.com] On
Behalf
> Of Ralph Giles
> Sent: Friday, April 24, 2009 12:46 PM
> To: Petrie, Glen
> Cc: Till Kamppeter; printing-architecture at lists.linux-foundation.org;
> printing-summit at lists.linux-foundation.org; Michael Vrhel
> Subject: Re: [Printing-summit] [Printing-architecture] Print
> Dialog:PreviewProcessing: Only A Question
> 
> On Fri, Apr 24, 2009 at 11:33 AM, Petrie, Glen
> <glen.petrie at eitc.epson.com> wrote:
> 
> >> In 5. we get CUPS Raster. This is not yet dithered. The dithering
is
> >> done by the rasterto... driver.
> >
> > As Ghostscript is the most critical filter here, I would like to
verify
> > this with the Ghostscript folks.
> 
> Till and Mike are more expert here, because it's not what ghostscript
> does, but what cups asks it and the driver together to do.
> 
> I don't think we have real colour management working yet. The cups
> raster format can accept halftoned images, in which case gs can do the
> halftoning. Normally, I think the driver does the halftoning, in which
> case ghostscript generates a continuous-tone cups raster.
> 
> Ghostscript has to do *some* colour management because the input pdf
> could have different components in different colour spaces. Right now,
> I think everything gets converted to some 'device space' and then goes
> through some hard coded transformations in both ghostscript's graphics
> library and the cups raster driver to get the right number of
> components. Aside from applying an rgb matrix that looks like it came
> from the cups ppd, I don't see any attempt at calibrating these colour
> spaces.
> 
> The point of the work Michael talked about at the summit is that cups
> will be able to supply an ICC profile describing exactly what space
> ghostscript should generate output in. If the application embeds an
> icc profile in the pdf it generates, this will result in end-to-end
> colour management if ghostscript is doing the halftoning. If not, the
> PPD can at least request generation of a cups raster in an
> intermediate space with an appropriate gamut for passing to the
> rasterto* driver, which minimizes conversion loss. The printing dialog
> would supply the screen's ICC profile *and* the printer's profile, so
> ghostscript (or libpoppler, when it also has ICC support) could
> approximate the appearance of the document within the constraints of
> both the printer and the screen gamuts.
> 
> If you don't want gs to do any colour management, then you have to
> ensure that the image and output ICC profiles combine to a null
> transform. The application can do this by looking up the printer
> driver's ICC profile and using that directly. The printer driver can
> do this by accepting sRGB, which would help applications that can't be
> bothered since that's usually the default. As long as the image in the
> pdf has a profile that matches the requested output profile, gs will
> leave the image colour alone and let the next stage do all the work.
> 
>  -r