[Openicc] Printing Plans GhostScript / sRGB / ICC

Hal V. Engel hvengel at gmail.com
Wed Mar 2 16:47:57 PST 2011


On Wednesday, March 02, 2011 03:48:38 PM Chris Murphy wrote:
> On Mar 2, 2011, at 4:38 PM, Hal V. Engel wrote:
> > A user setable switch in the user land software (like the CPD) could be
> > something that always defaults to  "Make my colours pretty" and must be
> > set each time a user wants "leave my colours the hell alone" since the
> > latter is used very rarely.  That is it should be setup so that a
> > "normal user" can't set this and then end up wondering why he/she is
> > getting bad results from that point on.  After all the "leave my colours
> > the hell alone" option is for users that have an understanding of color
> > management and at some point CM aware apps (GIMP, Krita, InkScape...)
> > should be producing well formed PDF spool files.
> 
> Should these applications be able to sent a "token" with their print job
> that automatically sets the CPD to "no color management" automatically to
> prevent a default condition of double color management?

That is a possibiliy but why not just tag the objects in the PDF file correctly 
so that it is passed through?  After all if the app is smart enough to produce 
color managed spool files it should be smart enough to figure out what the 
printing pipeline will pass through directly to the printer.   The number of 
open source apps that fall into the CM aware group is fairly small and the 
developers working on them are well aware of what is happening here and very 
capable of doing the right thing.  They just need to know what the right thing 
is.

The only time pass through or not is ambiguous is when there is no 
OutputIntent and the objects are tagged as DeviceXXX and there is only one 
DeviceXXX type used and it matches the printer color mode.  A CM aware app 
wanting it's already CMed spool file to pass through should set the profiles of 
the embedded objects == the OutputIntent and it will get pass through since 
this is completely unambiguous.  The main thing is to make sure that 
pdftoraster honors OutputIntent.  

In fact this would also work for profiling and calibration targets but these 
would need to be produced by a specilized app I think.

> 
> >  Also it should be OK for "leave my colours the hell alone" print jobs to
> >  fail if there are issues down stream like sending a DeviceRGB object to
> >  a printer set in CMYK mode or having more than one DeviceXXX type (IE.
> >  DeviceRGB and DeviceGary) in the PDF file.
> 
> While I agree in theory, in practice anyone who tries this feature, which
> they will if it is not hidden and only viewable with a secret keyboard
> combination, will still expect a print to come out. Not an obscure error
> related to color mode mismatches. So this behavior would seem to require a
> clear error message. "User is confused. Please try again with color
> management enabled, or matching document and printer color modes."

I didn't mean to imply that it should fail ungracefully.  Like most users I 
don't like ungraceful failures.  The user should get a clear error message if 
it fails.  After all even a CM expert can make a wrong selection when setting 
up a print job and if it fails they should get a clear indication of why it 
failed.  I would also be inclined to have the option clearly labeled in the UI 
as FOR EXPERTS ONLY so that normal users are inclined to not use it and if 
they do and get error messages and/or bad results they will know it was a user 
error to try that option without the right level of expertise.  But you are 
right many of them will try even if they don't know what it does.

> 
> 
> Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110302/630f3224/attachment-0001.htm>


More information about the openicc mailing list