[Openicc] questions about cupsICC on remote CUPS servers

[Hal V. Engel]

On Wednesday, May 18, 2011 07:48:17 AM Jan-Peter Homann wrote:
> Hello to all,
> It would be fine, if somebody could answer my questions or comment my
> workflow ideas.
> 
> As I´m not a developer, my ideas or workflow recommendations  may have
> problems or pitfalls. But my goal is to bring the discussion in a
> direction to discuss workflow opportunities, which could be realized in
> near future with current available technologies.
> 
> 
> Thanks an best regards
> Jan-Peter
> 
> Am 17.05.11 16:57, schrieb 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.

There are no tools that exist for this.  In addition the PPD files are intended 
for printer/driver vendors and the whole setup is designed to be static.  So 
currently using PPD files for dynamic configuration is not possible and will 
require a lot of work to change.

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

This is already in place and widely used.

> > 
> > 
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110518/6434362d/attachment-0001.htm>