[Openicc] Introduction / Gutenprint

[Kai-Uwe Behrmann]

Am 10.04.05, 11:38 -0400 schrieb Robert L Krawitz:

>    Sounds like an good direction if CUPS will transport some information:
>    - sending a custom linearistation profile to Gutenprint
>    - request a gamut profile from the CMS layer (kind of an other issue)
> 
> So the problem here is how the spooler, driver, and CMS layer talk to
> each other.  Right now the spooler basically firewalls the driver from
> everything else, unless you're using something like the GIMP/Cinepaint
> print plugin, which incorporates the driver directly.  All of the *x
> spooling systems appear to basically be designed to accept jobs and
> route them to the correct printer, maybe with a little bit of job
> control information on the side from a static PPD file.  The JCL is
> quite limited; it allows some number of keyword/value pairs, but not
> anything really extensive like curves or tables.

I dont come with an complete solution here just a listing of outstanding 
issues for late colour binding:

o users want to set parameters (in libgutenprintui or a PPD interface )
  - the ui should prevent users from changing colour relevant settings or
    pop up a dialog to break the "colour managed" status, eighter through
    bidirectional comunication or more dangerous by carefully handling 
    such cases in in the GUI
o the CMS layer needs to know about parameters of the "logical printer", 
  as a set of textual strings for selecting the correct profile. This
  allowes on the fly queries of colour managed settings : select a profile 
  and see the appropriate driver settings in the gui.
o users want to easily use/install profiles (including belonging settings)
  without beeing asked for administrator rights (target profiles as part 
  of the job/document is possible in pdf?)

One partitial solution could be to embed driver settings into the profile 
itself. Texts are allowed as tags. And as such settings are highly 
specialized, I have no trouble to use even if they can not been 
interpreted as by the intended driver. The CMS layer can easily extract 
such a tag and proceed to the driver for interpreatation. So the profile 
handling would become a one file thing.

Anyway binary blobs outside of image data remain as an issue for the 
transportation.

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name