[Openicc] Printing Plans GhostScript / sRGB / ICC

[Chris Murphy]

On Mar 3, 2011, at 10:48 PM, Kai-Uwe Behrmann wrote:
> 
> 
>> 1. Are these options going to appear in the GUI? Can they be ignored or turned off somehow? I really think we need a way to force their deprecation.
> 
> I tent to agree with not showing such advanced stuff by default to
> innocent users. This would be a specialised feature.

I don't think it's advanced stuff, I think it's ridiculous stuff. I would never use such a thing, and I wouldn't subject clients or end users to using it. It's an admission of complete failure of everything upstream.

>> 3. Why and how could there possibly be different sources for text, images and vector graphics? This makes less sense than the very option of choosing color spaces, unless of course, it is anticipating the existence and acceptance of malevolent applications that ignorantly strip ICC profile metadata.
> 
> It appears to come from the legitimate wish, to print text with pure
> black and not with any other colour channels involved.

OK, but you cannot get that whatsoever by choosing an RGB color space for text.

Black text is a particular kind of object, it does not have RGB or CMYK values. What colorants get used for it depend on the context and capabilities of the output device. If it is a press, almost invariably you want black text to print as 0,0,0,100. If it is a grand format printer printing billboard, the exact same text is almost invariably going to be rich black because 100%K only isn't particularly dark on such printers. ICC applies to one, and not the other.




> 
>> 4. So what gets used? What the user chooses in the print dialog from the pop-ups that this portion of the PPD generates? Or what the user has chosen elsewhere in their applications, or in the Gnome Color Manager or Oyranos or whatever their ancestors are? How many different locations do we really need for users to set default color spaces for untagged objects?
> 
> I have the feeling we discuss about the right problem to solve in a
> difficult place. Anyway, its a interesting problem.

Ha! Well I have an interesting solution: don't honor this portion of the PPD. We do not need more buttons and switches, unless the goal is to give users aneurisms. Advanced users are mortal.


>>> 
>>>   Simulation Profile: None *SWOP Euroscale Commercial DIC TOYO
>> This is annoying and nonsensical also, but there's probably not a lot that can be done about it in a v1.0 or short term. This is a relic of a bygone era. And how it works varies from printer to printer. So preventing it from happening, and then rolling better conversions (even default ones) within a new framework which would achieve better consistency from device to device, is a long shot. By default, this means there is no such thing as /DeviceCMYK on this printer. An internal conversion will occur. It expects to receive SWOP, and usually such a system has *NO MEANS* of communicating this expectation upstream so the data can be properly submitted every time.
> 
> Proofing belongs either into the applications or, at the moment, into a
> hand crafted xxxtoraster filter.
> Too many might loose overview if we try to put all bells and whistles
> into v1.0. We are already very busy on discussing the very basics and
> how to get that v1.0 working including naming and working on bugs.

I think the whole thing needs to be flowcharted. I think the entire end goal does need to be discussed, with a deadline in time. It should include PostScript. It should include mobile.

And *THEN* we can break down the tasks that are realistic for a v1.0 implementation. If we just haphazardly choose things for v1.0, I do think we may find ourselves at v1.5 thinking, "oh crap what we did in 1.0 with this one thing was a mistake, now we have to back track". Or whatever.


Chris