[Openicc] GoSoC 2011: CPD and target printing

[Ann McCarthy]

Hi Alastair,

Yes - excellent points which are also in the realm of the potential
metadata in an ICC profile -- to record what kind of rendering and
specifically what paper the profile is designed for.

The driver settings should not be one to one with a single profile,
rather there are 1-N profiles that work with a particular set of
driver parameters.

In the case that a driver can intelligently determine that N profiles
match the current setttings (i.e., the profiles all have recorded in
metadata the driver settings they are suited for AND the driver can
compare its current settings to the recorded profile driver settings)
--- then the user should be presented with the choice of just the N
profiles that are right for the current driver settings.
In one scenario the user would have to choose by filename.
Preferentially -- additional metadata in the profile such as 'paper
brand' and/or 'perceptual rendering intent aim' can be used to provide
the user with an understandable choice.

Best regards,
Ann L McCarthy
Imaging Systems R&D
Lexmark International, Inc.



On Mon, May 9, 2011 at 2:30 PM, Alastair M. Robinson
<blackfive at fakenhamweb.co.uk> wrote:
> Hi,
>
> On 09/05/11 12:35, Jan-Peter Homann wrote:
>
>> http://www.freedesktop.org/wiki/OpenIcc/ColorMangedPrintingPath
>>
>> It would be nice to get some comments on this proposal.
>
> Unfortunately I lack the time to "get my teeth into this" at the moment, but
> I'll make a few comments in passing if I may.
>
> Firstly, Print Spool File generation, you list QT printing API, but not GTK
> / Cairo.  Those two will account for the vast majority of "casual" printed
> documents.  PDFs coming directly from applications will, I expect, be
> largely from high-end apps such as Scribus.  Apps with less demanding
> printing needs that implement their own print path will, I imagine, continue
> to print in PostScript for some time to come.
>
> PDFtoRaster modules:
> Both Ghostscript and Poppler have working colour management now, for varying
> values of working.  CUPS has the CUPSICCProfile mechanism, which again works
> today.  Is the consensus that this mechanism isn't flexible enough for our
> needs, or should we design towards it?
>
> Section 3 - linking of ICC profiles and raster driver settings.
> One point I've made several times already, but which I'll re-iterate here:
> Don't assume a one-to-one mapping between a particular instance of driver
> settings and an ICC profile.  There are two situations I use on a daily
> basis where one set of printer settings maps to many profiles:
>
> Firstly, inkjet printing on multiple brands of photo paper.  I have several
> different types of paper that all work well with identical printer settings,
> but which require individual profiles to keep the grey balance right.
>
> Secondly, using a high-end workgroup laser printer with CMYK profiles. If
> I'm printing a flyer or postcard that requires the best possible contrast
> and deepest blacks, then I'll use a high TAC and lenient black-generation.
>  If on the other hand the job's going to be folded, I'll use a much more
> aggressive black-generation to keep the toner coverage low and reduce the
> chance of toner flaking off the fold. Identical print settings, very
> different profiles.
>
> All the best
> --
> Alastair M. Robinson
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>