[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management
Hal V. Engel
hvengel at gmail.com
Sun May 15 15:43:14 PDT 2011
On Thursday, April 28, 2011 11:24:28 AM Till Kamppeter wrote:
> Hi Joseph,
> Congratulations for the acceptance of your proposal for the Google
> Summer of Code 2011.
> All the best for your work this summer.
I am back tracking to the beginning of the thread with the intent of helping
focus on what should happen with the design and implementation of the CM part
of the printing work flow. My aim is to help the GSoC student by directing the
discussion toward resolving the target architecture.
I would like to start with a short description of the current state.
1. Print UI and User Apps
A. None of the standard tool kits (QT, GTK+...) produce PDF spool files that
are well formed. In general these PDF spool files are garbage from a CM point
of view. There are no exceptions to this and it will likely take a long time
(several years is probably optimistic) before these issues are corrected.
B. The only open source apps that I am aware off that can produce well formed
PDF files with full CM support are specialized publishing apps like Scribus.
C. The standard tool kit print dialogs are completely devoid of any CM
related support and it will likely take a long time (well beyond the GSoC time
frame) to get this support implemented.
D. Current print UIs with the possible exception of the CPD and the related
PPD files are doing a poor job controlling how printing related complexity is
exposed to users. This is clearly a major issue that needs to be addressed
perhaps by following the CPD model.
E. There is currently no support for experts to set up custom CM work flows
for nave users in any existing print UI including the CPD.
F. Only a few open source apps support soft proofing and it must be hand
configured by the user (IE. no integration with the printing back end). In
addition, if the user is using a remote print server there is no way to get
the profiles used by CUPS without doing some tricks in the servers
installation/configuration to make this possible.
2. CUPS Print Server
A. We now have many of the underlaying building blocks for CUPS to handle CM
correctly. In particular we now have two working (but largely untested)
*toraster filters based on GhostScript and Poppler that support CM at least to
some extent. This is a major part that was missing until recently and without
this we would not be able to make any significant progress.
B. The GutenPrint team is on board and aware of what the underlaying issues
are. The GutenPrint team now has their own CM expert as well.
C. It appears that IPP Everywhere has hooks to address getting profiles from
remote print servers to deal with soft proofing issues that exist with the
current CUPS API. I suspect that this is partly in response to our requests
to the CUPS team for such support.
3. System level CMM (IE. Oyranos and colord)
A. We have two different approaches and both use different application
interfaces. I think it would be helpful to get both using the same interfaces
so that these could be interchanged depending on user or distro preferences.
B. Colord appears to be somewhat farther along as we now have a working
version of it that is integrated with CUPS and a front end configuration app.
Although it does not appear to have the level of integration (user apps, print
UI.. are not integrated) that is needed for a full print work flow.
C. Colord appears to take a more simplistic approach in it's printer support
than Oyranos. This is not a critical comment rather it is a comment that it
may at some point prove to be too simplistic but this remains to be seen. And
it might also be argued that Oyranos is too complex. Again we do not know at
A. There are many aspects of the printing CM architecture that are not defined
and where there is significant disagreement among the members of this list.
This is a significant issue for the GSoC project since the student working on
this needs to have this well defined before meaningful implementation work can
B. There is significant disagreement over how to handle target printing that
appears to break down into two approaches.
Use a specialized app. A slight variation on this would be to approach one of
the existing OSS apps and ask them to provide options for printing targets
although I don't think this has been mentioned by anyone here yet.
Allow any app to print targets and have specialized target printing
functionality in the print UI.
Now I would like to lay out a strawman for what we should do along with
A. Tool kits need to implement at least basic support for producing well
formed PDF spool files. This means at a minimum that they must not use
DeviceXXX object tagging unless it is specifically requested by the app. Most
tool kits appear to use DeviceRGB by default and have no way for apps override
this. Clearly a major design flaw that is very wide spread. This also a major
issue for the GSoC project.
B. Using a specialized app for printing targets has significant appeal but has
some significant issues.
It creates a new app that must be maintained. Anyone who has worked on any
open source system will tell that it takes at least one person making a
sustained commitment to keep any app in working order over an extended period
of time. I think the main issue with this approach is finding such a person
and I think this makes this approach less viable or even perhaps impossible.
Another option is to approach one of our existing apps to ask them to add
specialized target printing functionality. This would likely add only a few
lines of code to the existing app. We currently have members here from at
least two apps that might be good candidates. These are Scribus and
PhotoPrint. PhotoPrint might actually be the simplest to use for this but
either should work. For Scribus this might be implemented as a plug-in.
C. The other option is to put controls in the print UI for target printing.
This might be OK as a stop gap pending creating a specialized app.
D. As part of creating a printing work flow prototype we need at least one
user level app that can be used to test the work flow and to demonstrate what
apps need to do. This means we need an app that can produce well formed PDF
spool files. This leaves us with very few options for something that could be
in place by the end of the GSoC project and the only candidate that I see for
this is Scribus. Again it might be possible to do this as a Scirbus plug-in.
E. Eventually we will need for the standard tool kit libraries to add support
for producing well formed PDF spool files. At this point I don't know of any
existing library that will support this. It does not exist in any of the
standard tools kits and I have not found a third party PDF library that
provides more capabilities than the printing APIs of the tools kits. But I do
have to admit that I have not looked extensively and perhaps some one is aware
2. Print UI
A. I personally think this needs to be based on the CPD since it does allow
for controled exposure of complexity at least with well done PPD files.
Perhaps producing one or more example PPDs that do this correctly is a good
idea for the prototype.
B. Beyond possible support for target pass through I am not sure what else
needs to be visible in the UI.
A. We should be able to leverage the work done on the colord integration if
the GSoC project is based on Oyranos.
B. We may need to do some work to simulate the IPP Everywhere ability to
retrieve a profile for proofing. This should not be too difficult as I was able
to get something like this working by creating a few sym-links in the past.
4. System Level CM
A. We should seriously consider making both CMMs use the same system level
interfaces and perhaps even implement those now. There is a Oyranos GSoC
project this summer and perhaps this could add a colord style DBUS interface?
A. There likely needs to be lots of glue code written to tie things together.
6. Expert Work Flow
A. We need to decide how experts will create profiles, calibrations, settings
bundles and how these will be packaged and presented in the user UI. If the
CPD is the starting place for the print UI it makes sense that these would
installed on the printer server and would be presented as presets in the UI.
I would also expect that if a custom CM based preset is selected that all
options that could affect color would end up being disabled in the UI unless
the print UI had been called from a target printing app.
B. Since Joe lives near me I can lone him an ArgyllCMS supported spectro so
that he can experiment with this and run tests.
C. If the approach is to embed the printer settings into the profile (I
support this approach) then we need to be able to capture the settings bundle
at the time the target is printed and we need a tool to embed it into the
profile once it is generated (IE. usually the next day to allow for ink
I think it is fairly obvious that we will not end up with a complete solution
from this GSoC project since there are many parts of the whole work flow that
are well beyond the scope of a summer project. This means that things will
need to be prioritized and only the most import parts of this targeted for
near term completion or some other folks will need to step up and work with
the student on specific parts of the over all project. We will also likely
have to hack some parts of this together so that the work flow can be tested.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openicc