[Openicc] cupsICC on remote CUPS servers Part 2

[Richard Hughes]

On 24 May 2011 12:41, Jan-Peter Homann <homann at colormanagement.de> wrote:
> So far what I have learned about CUPS through this list, I think an process
> of updating the color entries of a sever side PPD about installed profiles
> and driver settings is way, how a communication between server and client
> could be realized.

The PPD file itself can't be modified. It's installed by a package
manager, or in extreme cases is burnt into a ROM image.

> The user makes his selction through CPD and the cupsICC qualifiers are
> selecting the printer profile for pdftoraster. Rastertogutenprint reads the
> driver settings from the printer profile for printing with the right
> setting.

pdftoraster doesn't exist anymore, Till and I replaced that and
pstoraster with a new executable called gstoraster that detects the
different file types and does the right thing. If you're hooking into
gstoraster, you can either just use the existing colord code, or add
code that does something different in the same place.

As a more general point, I really think people should define the
architecture they want before trying to fix the remote cupsd use case
-- it really is much harder to fix than the typical
local-cups-instance setup.

As soon as you start hooking into the remote gstoraster instance,
you've got to have the icc profiles you specified _on the client
machine_, now accessible on the server machine. What Tim and I have
decided is to _not_ add remote printers to the local instance of
colord, and to rely on the remote instance of cupsd to have its own
remote instance of colord doing the profile management and color
correction. In the situation you *need* to color correct on the
client, I think it makes perfect sense to just create the source pdf
with an embedded output profile and intent, which means any possible
interaction with colord on the remote instance is ignored.

Richard.