[Openicc] colord 0.1.0 released!

[edmund ronald]

On Tue, Jan 18, 2011 at 1:41 PM, Robert Krawitz <rlk at alum.mit.edu> wrote:
> On Tue, 18 Jan 2011 09:53:42 +0100 (MET), Kai-Uwe Behrmann wrote:
>> Am 17.01.11, 10:49 -0000 schrieb Tim Waugh:
>>> On Mon, 2011-01-17 at 09:43 +0000, Richard Hughes wrote:
>>>> Sure, which is why the profile qualifier is free text. We're only
>>>> suggesting people use the same three dotted nomenclature that
>>>> ColorSync uses, but since we can send a simple regular expression to
>>>> colord it's quite possible to support random things like
>>>> "RGB.Plain.300dpi.RandomFeature|LengthE0"
>>>
>>> In fact the dotted notation comes from CUPS, specifically the "Color
>>> Profiles" PPD extension:
>>> http://www.cups.org/documentation.php/spec-ppd.html#PROFILES
>>
>> If existing specs would be sufficient for Linux, things would very
>> likely have already been solved. I think it was much more work on
>> the Ghostscript and Poppler cores and pdftoraster filters, than what
>> was brought up recently on the CUPS side. We are still in the
>> specification stage.
>>
>> As an example, why the three qualifiers are not enough, think of a
>> print queue with the following ICC profile qualifiers:
>> RGB.300dpi.plain_paper
>>
>> Now move the gamma slider somewhere, by accident or what ever
>> reason. Each system, which solely relies on the above three
>> qualidiers, will horribly fail. A user can print lots of photos with
>> that settings without getting a hint from the system that here/his
>> profile is pretty useless.
>
> Another example is computers with multiple types of ink (e. g. matte
> and photo black ink).  Or linearization curves (not just gamma values).
>
>> Users should not be able to mess up the ICC profile settings. That
>> is plain usability logic.
>>
>> If a PPD is stripped down to just three colour related options + a
>> valid ICC profile then we arrive in PPD vendor land, which is appart
>> from user settings.
>
> Three color related options aren't enough, *period*.  Let's stop even
> considering that as a starting point, and let's make sure we avoid any
> ad hoc limits like that.  The PPD limitations (such as 40 byte
> selectors) are bad enough, but at least at that time a lot of things
> were running 16 bit DOS.
>
> What we really want is a way to tie a particular profile to an entire
> bundle of settings, some of which (such as linearization curves) might
> not even be scalar values at all.
>
> Something else that would be useful would be the ability to install
> entire blobs of settings.  For example, expert users may carefully
> linearize and profile a new paper on a particular printer.  This
> process may require changing some Gutenprint options (such as density)
> from their defaults in addition to setting things like resolution and
> paper size.  If these could be conveniently packaged up and
> distributed, and installed into the color system, this would be of
> great assistance.
> _______________________________________________


At this point from the Gutenprint side of things, whether the user has
decent color management is the least of our problems.

Just getting to the state where the user can make a print involves
setting up ink curves for the paper, choosing raster patterns etc and
density adjustments, deciding on an rgb=>cmyk formula etc.

We are looking for a clean user interface and mechanism to associate
*all* these settings with the act of making a print;  getting color
management options into the same mechanism is probably the right way
to go, but we believe that we need a general solution.

We would prefer that the debate go there; Robert agrees that the
existing CUPS PPD color extension syntax does not seem appropriate for
large blobs of information, some XML inclusions would be preferable.
Personally, I believe that designing a user interface for the whole
thing and looking at user models (consumer, pro) would allow us to
understand better what mechanisms are need.

The Fruit OS has not needed to solve these issues, because it has been
constructed on the premise that vendors do NOT wish to allow domain
experts to tune the printer drivers. Therefore it has not exposed
printer tuning data upstream. However we in the open-source world now
rely on expert users for tuning, and so we need to facilitate it.

Edmund