[Openicc] Printing Plans GhostScript / sRGB / ICC

[Chris Murphy]

We're arguing the same thing. I'm just saying that an operating system *and* the PPDs found on it, should enable similar well behaved paths for printing to devices that insulate the user from stupid options. But that system is not in place because of the 20 year old PPD paradigm you're defending, but don't understand why I find it so irritating. It's one of the major reasons why we throw our hands up and say "ok this is pointless" for that entire class of devices, to be relegated to just sRGB and SWOP assumed.

So again, if it's really working for 99% leave it alone, convert to sRGB and SWOP and just let that whole era fade silently into the night. But if we're going to do any work to enable a sensible custom or manufacturer ICC workflow for these devices, their PPD's need to stop being malformed saboteurs for such a workflow. And I agree asking for that is a tall order.

Chris Murphy



On Mar 7, 2011, at 6:42 PM, Graeme Gill wrote:

> Chris Murphy wrote:
>> Ha! Yeah you insulated the user entirely from the menu system that PPD employed. You
>> ensure that you set the printer to a "None" or "Raw" color mode that had been profiled
>> (either custom or by manufacturer or batch for that model), prematched everything in
>> the proofing RIP, and sent /DeviceCMYK + and off switch to the printer. The end user
>> never saw the clusterf*ck.com PPD from the manufacturer.
> 
> Well, we were the "manufacturer" as far as the PPD was concerned, and
> yes, they were presented with a similar looking interface. Typically though
> they would set up a proofing print queue with the defaults set appropriately
> (ie. "Custom 1"), and on the RIP "Custom 1" then mapped to the CMYK device
> link and associated print mode. Once setup, the PS proofs (yes, all set
> in DeviceCMYK) were then sent to the proofing print queue.
> 
>> That's what a good proofing RIP does. It hides the manufacturer's convoluted options.
>> If it didn't, the user would touch one button and the behavior of the printer would
>> conflict with the expectations/assumptions of the proofing system and they'd get junk.
> 
> Sure, but there's nothing new about that in regards to color. The controls need to be
> there to set the system up to work correctly, and conversely it won't work correctly
> if you change them.
> 
> Graeme Gill.
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc