[Openicc] cupsICC on remote CUPS servers Part 2
Jan-Peter Homann
homann at colormanagement.de
Fri May 20 01:14:22 PDT 2011
Hello list, hello Kai-Uwe, (Question to Mike and Till at the end !!)
If we have a remote CUPS server, I would recommend, that driver
settings, ICC profiles and a PPD representing this setup are managed
centrally at the CUPS server.
This is necessary to make sure, that all user working with the CUPS
server are using the same setup.
As a result, only the people with admin rights for the CUPS server are
allowed to install printer ICC profiles with assignend driver settings.
As the CUPS protocol do not allow to pull ICC profiles from the server,
we have to work with the CUPS PPD dependent mechanism for communicating
the available colorsetup to the CUPS clients.
Concerning the PDF print spool format, it will be easier to implement a
color managed printing path, if the PDF print spool format transports
only the profiles for describing the document colorspace.
In the print chooser (e.g. CPD), the user chooses the cupsICC qualifiers
(media, resolution) presented through the PPD, which CPS has pulled from
the CUPS remote server. On CUPS serverside, the cupsICC qualifiers are
intepreted and the printer profile for pdftoraster is setup through
through the cupsICC selection process.
***********************************************
Questions to Michael Sweet and Till Kamppeter
***********************************************
- Is this is workflow-proposal, which makes sense for a color managed
print path with remote CUPS servers from your point of view ?
- If not, what are the alternatives ?
Best regards
Jan-Peter
Am 20.05.11 09:45, schrieb Kai-Uwe Behrmann:
> Am 19.05.11, 21:25 -0400 schrieb Robert Krawitz:
>> On Thu, 19 May 2011 15:58:57 +0200, Jan-Peter Homann wrote:
>>>
>>> I´m not developer, but I´m working regularly together with
>>> developers. From this experience, the manipulation of pure ASCII
>>> files like a PPD is not something very complicated. Is it really a
>>> lot of work to create e.g. a basic PPD without color relevant
>>> entries and update the color relevant entries from profile Divtype
>>> metadata, which are installed on on the remote CUPS server ?
>
> Does CUPS provide an API to manipulate remote PPD files?
> [Please keep in mind a changed PPD will apply to all users of a print
> queue.]
>
> Again, it makes sense to deliver a PPD with fixed settings for a
> desired calibration state, add the cupsICCProfile property and ship
> and install that PPD with the according ICC print profile. Thats
> clearly a CUPS server thing useful for vendors like GutenPrint and
> administrators as they have control of packages or the needed access
> rights.
>
> For user configured profiles that makes not much sense as Hal already
> pointed out, because of the static nature of server side installed PPDs.
>
>> For Gutenprint, the first part (creating PPD files without
>> color-relevant entries) is no problem. The rest of it, I'll leave to
>> people with more experience in that area.
>>
>> (Gutenprint's PPD files are all generated based on information in the
>> driver. Since we added information about which options affect color
>> in 5.2.7, it would be a simple matter to generate PPD files without
>> color information.)
>
> Then the defaults would apply, which appears to me different from the
> driver settings that have formed the calibration state during target
> printing.
>
> kind regards
> Kai-Uwe Behrmann
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
--
---------- Please note the new adress --------------
homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110520/b8207a0d/attachment.html>
More information about the openicc
mailing list