[Openicc] Printing Plans GhostScript / sRGB / ICC

[Chris Murphy]

On Mar 4, 2011, at 1:05 PM, James Cloos wrote:

> 
> CM> If this is a common PPD, we have our work cut out for us on another
> CM> front which is what options should and and should not appear in PPDs.
> 
> Why shouldn’t they?

It's like arriving in a pig pen and considering how to use it as a kitchen. It's a mess. I've already posted an email containing my rationale for why this needs to go away.


>  The out of box defaults are sane for most users.

Exception 1: It does not communicate the default upstream.
Exception 2: It does not communicate any other user setting upstream.
Exception 3: The other options are not sane, except for the non-communicatible None option.
Exception 4: Any user wanting to use ICC profiles presumably must set all three object type settings to None, manually. That's completely retarded. (It's yet another reason why I'd say in implementation v1.0, PostScript electrophotostatic devices are entirely on their own, convert everything to sRGB and let the printer's PPD and internals deal with the fallout. Don't even give them an ICC option, it is that fraught with peril.)


> The ability to choose between expensive CMY or inexpensive K for RGB
> gray is clearly a feature demanded by users (using CMY for gray costs
> more than five times as much USD than using K, but gives noticeably
> better results in photographs and the like).

Yes and those options are contrary to profiling the device. It's not the user that should control it, it's the content. If you're printing photographs with ICC profiles, the RGB to K only option is a disaster, it shouldn't even be possible. If people want to try it, I certainly wouldn't give them that power in a UI.

I suspect we could come up with a path that would elegantly deal with assigning different output profiles to these three objects DEPENDING on the user preference for handling these types of objects. However, we need that feedback to come upstream so that GhostScript can be told what to do, which profiles to use, and preserve all necessary metadata so that the printer does the right thing. I personally do not think that this is a v1.0 possibility. We have higher priorities than unwinding the mess that is PostScript printing on electrophotostatic devices: they are notoriously inconsistent anyway. 

> 
> Remember that papers (usually, I’m sure, due to author naïveté)
> frequently use images where a vecotr graphic should have been used.
> And when so they are essentially always in DeviceRGB.  So you can’t
> just say «use CMY for images and K for graphics».  The users need
> to be able to set a default, but still override that default on a
> per job basis.

Papers? I'm not understanding that reference. Newspapers?

There is one ICC profile that applies to both images and vector. If you're going to have two different black behaviors for image and vector graphics, you need to have two different ICC profiles and a way for them to be chosen by object type. There is no such system that does this right now.

If you want accurate color, you use ICC, and it needs full control. If you don't give a crap about correct color then yes, please use these settings. I can't come up with contingencies for users that have impossible scenarios like RGB images that needed to be printed K only. That's called grayscale.


> The manuacturers of RIP printers have now had, what, twenty years or
> so to figure out what controls the users want and how to present them.

Oh and it looks about 20 years old too. Incompatible with what we are doing. I'm going to continue to have this discussion but I'm going to continue to argue that PostScript electrophotostatic devices should be *on their own* and good luck with that. I'd say, do nothing different than what is being done today.

> 
> And for cups-based print flows, the only way *to* do those per-job
> overrides is via PPD options.

Overrides != ICC workflow. They are contra options. Use them, and your workflow is dead. And the defaults usually cannot be profiled.


> 
> (The PPDs use setpagedevice postscript snippets; the printers generally
> also support using PJL to set those options.)
> 
> I just do not understand the complaint....

I don't think you understand that these options break ICC workflows at worst, and at best require a substantially more complicated, multiple outputintent heuristic pipeline as to make it not possible right now.

Users who want to screw shit up on the backend, which has no way of informing upstream what the new printer behavior is, without any profiles that describe that new behavior, have NO REAL DESIRE to get consistent color.

I will tell you how designers think when it comes to devices like this. They talk nonsense all the time, such as "I want it to be color accurate to a printing press. I want the printer to print black only text." These instructions are in conflict. I don't believe in giving them the option to do inane things. If they choose "color accurate" as an intention somewhere upstream - take away all of the razor blades downstream.


Chris Murphy