[Openicc] questions about cupsICC on remote CUPS servers

[Jan-Peter Homann]

Hello all,
Following the dicussions in the OpenICC list, i have the impression, 
that a color managed print path with a remote CUPS server is somehow 
more tricky to implement, than a local installation.

see e.g. statements from Hal. V. Engel

 > There is no good reason to point cups clients at localhost if the spool

 > is actually on another box. lpoptions should specify the remote spool

 > as one's default printer in such cases. And with that, both the CUPS

 > API and http over port 631 should give direct access to the PPD.


Direct access to the PPD is already supported and this makes it possible 
to get a list of CUPS configure profiles (IE. CUPSICCProfile entries). 
Oyranos apready does this. But on remote print servers there is no way 
to retrieve one of these profiles for things like proofing. HTTP over 
port 631 does not expose the profiles unless you create a sym-link from 
the dirrectory that is visible using http and port 631 to the profiles 
directory. At best this is a hack but it would allow us to create a 
"retrieve proofing profile" API for prototyping purposes without too 
much effort so that how all of this works from a user prespective could 
be tested.


*****
Reading such discussion I realize, that I need a deeper understanding of 
some Aspects of CUPS based workflows. Hopefully somebody could answer to 
my questions:


1) Dynamic updating of PPDs for a remote CUPS server
Are there tools available, which allow to update automatically a PPD 
representing a remote CUPS server ?
The use case here would be the installation of new combinations of 
ICC-profiles with assigned driver settings on the CUPS server with an 
automatic update of the cupsICC entries in the PPD.


2) CUPS client pulling PPD from the remote CUPS server
Are tools available, which allow a CUPS cleint to pull a PPD from the 
remote CUPS server ?
(The usecase here is, that the printing GUI for sending a print job gets 
an update, which driver settings (media / resolution) are available at 
the remote server.


3) Configuration of target profile in pdftoraster based on cupsICC
As being not a developer, the following described workflow is may 
uncorrect in terms, that i`m using, so please correct me, if I´m wrong:


- An administrator for the remote CUPS server installes new printer 
profiles with assigend driver settings
- The PPD for the remote CUPS server gets an update for installed driver 
settings and links between driver settings (media / resolution) and 
server side printer profiles.
- In the print chooser on client side (e.g. CPD) the media / resolution 
settings extracted from the PPD are always representing the settings and 
profiles on the server side.
- The user chooses one of the media / resolution settings and sends the 
print job to the CUPS server.
- The CUPS server reads the media / resolution settings from the 
printjob and selects the approbiate printer profile through cupsICC match.
- The selected printer profile will be automatically configured as 
target-profile in server side pdftoraster (GhostScript)
- Gutenprint reads also the media / resolution settings from the CUPS 
datastream and uses the correct Gutenprint configuration to output the 
rasterfile from pdftoraster


- optional: (pdftoraster embedds the printerprofile into the rasterfile 
for e.g. rastertogutenprint. Gutenprints extracts the Gutenprint 
settings, which have been embedded into the printer profile before.


- Workflow for creating media /resolution settings for ICC-off in 
pdftoraster
- an existing media / resolution settings is duplicated with a new 
naming for media "GlossyNoICC"
- no cupsICC entry will be associated with this new setting
- pdftoraster will not triggered via cupsICC with a printer profile and 
creates the rasterfile for rastertogutenprint without any ICC-transformation
- gutenprints reads the media / resolution parameters from the cups 
stream an outputs the raster file with the correct settings


Is such a workflow possible ?


If yes, is it correct, that such a workflow with a remote server could 
also be used with a local CUPS installation ?


Maybe this decribed workflow is version wich could be implemented more 
or less with the available tools and minor improvements e.g. for CPD to 
pull the PPD from the remote server:


The goals to reach would be:
- Make the installation of new printer profiles with assigend driver 
setting easy on CUPS server
- Avoid any possible mistakes with profile handling on the client side
- Only very few improvements on CPD are necessary

- compatible with existing DeviceRGB print spool formats
- allows invisible sRGB->printer colormanagement for standard users
- open for the professional users a path for creating printing paths 
with disabled ICC transformation in pdftoraster

- allow crowd profiling for for the open source printing community
- use the same workflow both for local and remote CUPS server installations


Goals wich are not reached in this step
- No preview possible, because profiles could not be pulled from CUPS 
remote server
- no link to local color management frameworks like Oyranos or g-c-m / 
colord, because profiles could not be pulled from CUPS remote server


Such goals could be implemented later, if pulling of profile from the 
CUPS server is realized.


****

Comments and corrections are welcome
Jan-Peter

-- 
----------  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