[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management

[Hal V. Engel]

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

> 
> All the best for your work this summer.
> 
>     Till

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

4. Architecture

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

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

1.  Apps.

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

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. 

3. CUPS

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?

5. Architecture

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

Other thoughts.

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.

Hal
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110515/e7cb975e/attachment-0001.html>