[Openicc] GoSoC 2011: CPD and target printing (Michael Sweet)

[Chris Murphy]

On May 14, 2011, at 5:13 PM, Alastair M. Robinson wrote:

> Hi,
> 
> On 14/05/11 23:28, Chris Murphy wrote:
> 
>> Ridiculous conjecture and unsupportable in fact. There is no such thing now in any print dialog on any platform,
> 
> Just because operating systems don't provide such controls as standard doesn't mean they don't exist.
> Exhibit A:  http://www.normankoren.com/Epson_2200_preferences_ColorMgmt.gif

My point is that it's a travesty of UI design because it's non-obvious what this option means. First,  you have to choose ICM in a print dialog, and then choose No Color Adjustment. So how is it that you're choosing ICM but getting no ICM? It's a contradiction.

It's also ambiguous to a regular user whether the content has already been subject to an upstream ICM conversion.

> 
> Exhibit B:  The PPD shipped with EFI Fiery servers allows the printing of CMYK with calibration only, or raw CMYK bypassing the calibration.

That makes sense because the expectation is that CMYK PostScript is passthrough. It does require an assumption, one that most people performing the calibration would understand. And also, calibration function is very clearly a print specific feature with no upstream event, unlike system level ICC based color management.

> 
>> A disable ICC transform option in a print dialog can only mean disabled in the context of the print pipeline,
>> it cannot ensure upstream conversions have not occurred.
> 
> Semantics - of course the print dialog can't dictate what an application does upstream, but on the other hand what business does an application have applying ICC transforms without being asked to?

This is as absurd as saying a pedestrian does not need to look both ways when they have the right of way in a cross walk. The pedestrian may be right, and the car that hits him may be wrong, but in the meantime you have a dead pedestrian.

You cannot prevent applications from implementing transforms however they see fit. You can only make recommendations. If they want to prematch everything and cache it, and not the original, that's not inherently wrong. And it's not inherently wrong to do so by default. That's the whole point of color management by default. Firefox does it for tagged images. So does Safari. Photoshop has been applying transform for more than a decade for onthefly display compensation. So I refuse the premise that transforms require user permission - that's unworkable proliferation of even more color management UI insanity.



>  Is that really going to be a common enough occurrence to cause an issue?  The only place I can see it being a problem is if an application only "speaks" one colourspace and the user's trying to print using another.

With one web browser alone doing it, you've got enough of a problem the whole adventure needs a rethink. The more you want apps to opt in with some kind of color management, with a huge array of untagged images in the world assumed to be sRGB - you're going to have transforms occurring everywhere, and ideally, without the user asking for it. That would be the whole point.
> 
>> We need the latter as well or the test chart is questionable (or useless). An option in a print dialog is inadequate.
>> Printing test charts is a special use case, and should have a known reliable application specific to the task that
>> uses a published and tested API that anyone else can use as well.
> 
> Printing testcharts is indeed a special case, and an application specifically for printing testcharts would be a great idea.  But has anyone volunteered to write and maintain one?

Whose volunteering to write and maintain this hypothetical off switch in the CPD? Consider them retasked. Who is volunteering to write and maintain and opt out color management system for various Linux distros? Consider the opt out mechanism a required component, if not included the entire opt-out color management system can't ship.

Until we see the app as fundamental, we'll see it as optional, and keep lying to ourselves about how it belongs in the CPD where it isn't actually going to ensure opt out because it can't.


>  And even if one existed, do I really have to use a specialist program if I want to print pre-targetted data?

It's already to that point. It has *NEVER* been best practices to print from some random app. We've always been using a specialized application for this purpose on Mac OS and Windows, for the better part of a decade. The app of choice until recently was Adobe Photoshop's No Color Management option. Now it's a mix of the Adobe Color Printing Utility and the profiling applications themselves.

It was never considered reliable to use Word, Excel, Internet Explorer, Firefox, the list of the most common applications you can think of. They aren't for this purpose. I'm not going to take a Word document and put it into an ICC profiling application in order to print it either.

There is a tool for each purpose. So yes, you really should use a special app that provides the proper assurance that the digital file is unaltered through the entire path to the printer.


>  (I do that on a daily basis, by the way - it's not just a hypothetical question.)  Note, further, that I can print pre-targeted data *now*, from any software that supports the appropriate colourspace, so losing that capability would be a major regression for me.

That's only because those apps haven't opted into color management transforms. Once they do, if they do, all bets are off until you thoroughly test those applications. And continue to test them every time they're updated to make sure the behavior is the same.

There's a reason why Photoshop was the gold standard for this for so long - and it's because so many people only used Photoshop NCM for the sole purpose of printing ICC profile targets. Anytime there was a problem you'd get 100 red flags at once that there was a bug. With this idea that every application is a profile printing application - you don't have that concentration. You don't have that assurance.


Chris Murph