[Openicc] Assuring that all CUPS filter... Our color management community

[Jan-Peter Homann]

Hello all together,
Just some personals feedback after coming back from the ICC meeting.
Reading some of the discussion in the OpenICC list, I feel not 
comfortable with the discussion culture at OpenICC.

We all as the color management community need the work, both Kai-Uwe and 
Richard are doing. And we all need the OpenICC list as a medium to 
discuss both with Kai-Uwe and Richard the FLOSS color management 
developments.

My proposal for calming down the discussion:

1) No more general discussion about Oyranos or colord g-c-m
Both projects have their place in the LINUX color management community 
and it make no sense to have general discussions, like e.g. saying 
project A is bad hack or project B is much too ambitious for the general 
user.

Let the users decide, what they use in daily practice.

Looking at all the color management problems we have currently under 
Windows or Mac OS X with the absence of coordination for color 
management in applications, on OS Level and driver level, we will 
probably see cases, where users have real world problems with e.g.  
g-c-m / colord or Oyranos. But than, we should focus on understanding 
and solving these real world problems.

Kai Uwe:
Could you agree not to write further statements about colord / g-c-m on 
the OpenICC list and just focus on the developments of your personal 
preferred color management projects ?


Richard:
Would you still share your experiences and developments of colord and 
g-c-m on the OpenICC list, if we all are coming back to a more positive 
and relaxed style of dicussion ?


Looking forward
Jan-Peter




Am 02.02.12 13:29, schrieb Richard Hughes:
> On 2 February 2012 11:10, Kai-Uwe Behrmann<ku.b at gmx.de>  wrote:
>> 1. colord user selectable per session print profile
>>   (as patched into CUPS by RedHat team members)
> It's "Red Hat", as I've said before. No space. It's also being used by
> Ubuntu and OpenSuse, so the fact that I'm a Red Hat employee doesn't
> really come into things. Please stop creating a conspiracy out of
> nothing.
>
>>   - side stepping CUPS API
> Err, it uses the same mechanism that ColorSync uses on OSX. It also
> allows CUPS to specific a default ICC profile in the ppd, but allows
> the user to override it.
>
>>   - needs permanent root access (might be fixed now by security team
>>     members)
> Sure, it needs root. Ubuntu and OpenSuse worked together recently on a
> patch to make it run as it's own privileged user. It no different to
> all the other DBus daemons in existence, I assure you.
>
>>   - non transparent to applications through the document or the CUPS API
> I have no idea what this means.
>
>>   - potentially affects print job of other users as selection is time
>>     based
> Well, the idea is you set up some print profiles for the printer ahead
> of time, i.e. you set profile X for color printing on glossy paper,
> and set up profile Y for draft color printing on plain paper. Users
> should not "choose" an ICC profile in a print dialog in the same way
> they don't choose ink limits and ink-dry parameters. It's an
> implementation detail, and not useful to add as a control. Sure, show
> the user what profile would be chosen for a set of media types (which
> is what the GTK print dialog does) but don't let the user control such
> low level details.
>
>>   - thus it may override other profiles in a more or less undefined way
> It's not undefined. It's perfectly defined. You just don't understand
> how it works.
>
>>   - not network transparent (which is only a missed feature)
> Sure, it's not network transparent. The idea is you install the print
> profiles on the print server (the remote CUPS instance) rather than
> controlling it all client side. If you want client side control, you
> just embed the output profile in the pdf that gets sent to CUPS.
>
>>   - three CUPS identifiers are non sufficient for complete calibration
>>     state control in PPDs
> I never said they were, it's just the default identifier I've been
> using to match the format in the ppd and also the format used by
> ColorSync. I'm sure color geeks will want to set the identifier format
> as something else. In colord the identifier isn't hardcoded as any
> format, it's just a string that gets matched by a regular expression.
>
>>   - all these concerns from the colour community are long known
> Heh.
>
>> 2. user configurable per print-queue-assigned profile
>>   (as investigated by Edmund Ronald)
> This is not either or. How much more simple can I make things. If you
> specify a print profile in the ppd file, then it gets used. colord
> only gets involved when you override that profile for whatever reason.
> The two schemes work perfectly together now, and I wish you would stop
> spreading FUD that the two systems are in some kind of competition.
>
> Thanks,
>
> Richard.
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc


-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de