[Openicc] colord 0.1.0 released!

[edmund ronald]

Maybe we should explain that we envision dumping everything as much as
we can, including inking info, into the serialized settings . This
would allow users to tune and then publish media recipes without ever
needing to get near the procedural code of Gutenprint.


Edmund

On Mon, Jan 17, 2011 at 4:02 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:
> On Mon, 17 Jan 2011 15:43:00 +0100, edmund ronald wrote:
>> The colord authors seem to be smart people who are engaging the user
>> community. They deserve my respect.
>>
>> However I would agree that the print problems of a certain "other"
>> fruity OS are proving untractable, and it is not obvious that the same
>> architectural choices should be introduced to Linux.
>>
>> The "other OS" has been very reluctant to provide options for pros who
>> color manage upstream, and this has created considerable controversy.
>>
>> However, no one seems to have noticed is that the other OS has not
>> really allowed individual print setting serialisation, and
>> profile/paper association, going instead for a "bundled install"
>> approach. Of course, this has been partly motivated by vendors desire
>> for control. The complexity of actually getting a correct print from a
>> third-party paper with a third-party profile on "fruit" is much
>> greater than that of "just" telling the vendor's driver to print from
>> RGB on a given vendor paper.
>
> Not to mention third party inks, which can't even be represented in
> the three component model.
>
> The profile selector really does need to handle a serialized
> description of the option settings.  I'd ideally like to be able to
> handle different driver versions, since we allow multiple minor
> versions of Gutenprint (including Gimp-Print 4.2) to be installed
> concurrently.
>