[Openicc] colormanaged print path - the big picture
edmundronald at gmail.com
Sun May 8 07:49:40 PDT 2011
On Sun, May 8, 2011 at 2:27 PM, Richard Hughes <hughsient at gmail.com> wrote:
> On 8 May 2011 12:27, Jan-Peter Homann <homann at colormanagement.de> wrote:
> > - offering a "one click install" for additional printer setups with
> > integrated ICC-profil
> I've dealt with one-click install before with my dealings with
> PackageKit. The conclusion I came to was that one click install is
> very difficult to get right, and probably impossible to do legally and
> securely when not dealing with the distribution metadata directly.
> > - offering robust opt-out for printing profiling testcharts
> I would prefer per-document opt-out.
- because I consider opt-out to be a reasonable thing to have easily
available on your system, whatever privileges you happen to have, and also
available to people sending stuff rom another machine (targets,
preconverted files) to a print server, when the print server has a
rudimentary instance of our color management system. These may be foobarred
workflows, but they allow the use of a CMM on the Photoshop host, black
point conversion etc, and I find them useful enough to offer my users, at
least until the Linux color management is as robust as the one found on a
Photoshop host. To those who mock my reference to proprietary software, let
me remind them that we are playing catch up, and that Linux was also a copy
of Unix which was a very functional system.
> Is this a per-document opt out? I.e. do I expect to send a normal
> document with color management, a testchart and then normal document
> to the queue and expect it all to work correctly? At the moment, the
> way colord does this is really designed for scanners and displays,
> where we inhibit the device for the duration of the calibration. For
> printers this works as long as the user does not try to print a
> "normal" document when we're in inhibit "mode". If this needs to be
> changed we can probably add an additional method for the ghostscript
> and foomatic projects to use that pass document-specific hints. I'm
> not sure if that's required yet.
If someone can help us implement a clean way to test getting the
ink-settings through to Gutenprint, at least for testing, we could get a lot
of this stuff protototyped by implementing just sRGB and opt-out. This would
allow Gutenprint to transition from the present hand-runed state to profiled
printing *now* rather than later.
I'm being a little cautions relying on the CPD being adopted before we
> can color manage printers. Until KDE and GNOME have significant buy in
> to CPD, I think it's a dangerous dependency to rely on for the promise
> of a color managed printing system. I'm sure that statement that won't
> make me super-popular with most of the people on this mailing list.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openicc