<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> 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 </body></html>