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

Sun May 15 16:48:50 PDT 2011

I believe this is a very nice summary of how we stand. Thank you for writing
this.

Edmund

On Mon, May 16, 2011 at 12:43 AM, Hal V. Engel <hvengel at gmail.com> wrote:

>  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
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110516/b14e0391/attachment-0001.htm>