[Openicc] Printing Plans GhostScript / sRGB / ICC

[Chris Murphy]

On Mar 8, 2011, at 1:20 AM, James Cloos wrote:

> I wanted to wait a bit before replying again to avoid devolving this
> even further.
> 
> But this much needs to be said:
> 
> My reply which mentioned how office colour lasers handle the issue of
> how to convert DeviceRGB to CMYK was an answer to the single question
> of how the user should be able to tell a CUPS/GS RIP that a given job
> is either a normal job or a profiling job.
> 
> And the options I mentioned are explicitly only used for DeviceRGB;
> not for CalRGB, CalGray, Lab, ICCBased, CIEBased or even DeviceGray.
> 
> Even the simulation profile is only used for DeviceCMYK.  
> 
> Users are even able to load arbitrary ICC profiles to the printers
> and use them instead of the pre-loaded profiles.  These printers
> support several PDLs and use an ICC workflow.  But the need to know
> what profile to use, by default, for the Device spaces.

I have no issue with sRGB being the default for /DeviceRGB. I have an issue with a user selectable means of changing it to Adobe RGB, because it's a hack for a problem upstream that needs to be fixed, not fixed with a hack. And manufacturers should not support hacks, or things upstream do not get fixed. If upstream processes are dropping e.g. Adobe RGB tags, then it's a bug and needs to be addressed as a bug, as data loss. Not with a convoluted, messy, confusing, insanely space consuming hack where the user chooses to re-integrate lost metadata. 

These superfluous options are really not a defensible position, except by acceptance of: 1.) a monolithic operating system with the screen space, memory and drive space to support such absurdities, because they will certainly not be tolerated on mobile, and for good reason; 2.) a willingness to subject *every single user* to see such a clusterf*ck every day they use the printer, whether they have a need for the hack or not.

Again, no problem with sRGB being default. Makes perfect sense. I understand, but don't like, the None option being user selectable, I think it needs to be buried and chosen automatically when upstream processes require it such as application prematching or system level color management converting the content for output, necessitating a "raw" state for the device, under which it was originally profiled.


> The simulation profile default is region-dependent; only the NA models
> default to SWOP.  And they do so because most DeviceCMYK output is
> intended for offset.  It remains common for print shops to insist that
> the jobs use DeviceCMYK and assume that that is SWOP or FOGRA or etc.

t's unknown what the printer manufacturer's device is actually expecting. sRGB is clear. SWOP is not. FOGRA is not. There are three SWOP characterization data sets and "SWOP" by itself does not tell us which of the three it is. There are, what, 42 different FOGRA characterization sets, with about a dozen in common use?

Are we then going to ship distributions of Linux (or any other operating system) with regional defaults, so the operating system supplies the correct CMYK assumed by these printers? Do the regions overlap? Do the assumptions?

This paradigm is closed-loop color. It works by assumptions. It does not work by communicating color spaces from hop to hop as a document travels from application to application, and through various printing pipelines in the system. It is very manual. And it is incompatible with being part of an open color management architecture without changes. Changes that proofing systems make possible by restricting the modes the printer is put into, and the options the user is allowed to choose.

And really, it doesn't work very well, it's just that most people don't know better, don't know how to fix it, don't have time to find out, and don't know who they'd complain to if they did have time. And so it goes.


> 
> Cost control is every bit as valid a consideration as colour fidelity.
> Allowing « 0 0 0 setrgbcolor » to convert to « 0 0 0 1 setcmykcolor »
> or « 1 1 1 0 setcmykcolor » on a per job and even per type basis is
> completely valid.  Even more so for .25 .25 .25 setrgbcolor.

It is valid, but these behaviors and contexts are knowable by people who understand why people want them. It's not rocket science, and it isn't random. It could very well be completely hidden by the user if the printer's PPD actually described it's full capabilities and limitations, so that a color management system could ensure that on a laser printer a page of black text from a word process always prints K only. That's obvious. It doesn't require a user to change it, except in a brain dead closed-loop architecture.

> The manufacturer-specific ppd options are always on a separate UI tab,
> marked either PPD or Advanced or similar.  They do not get in the way.

Yes, let's put a manual fuel pump for our cars into the trunk, where it won't be in the way. But still requires the user to interact with this pump with a hand crank if they want to go anywhere but downhill.


Chris