<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> 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 </body></html>