[Openicc] colord 0.1.0 released!

[Robert Krawitz]

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.