[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