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

[Kai-Uwe Behrmann]

Am 15.05.2011 18:43, schrieb 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.
>

As long as creating DeviceRGB is way easier than creating ICCbased,
things might not change easily.

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

We more or less delayed that anyway.

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

agreed

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

Both can work in parallel without much interference.

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

Both colord and Oyranos decided about means to pass through colours.
While colord's approach appears more easily implemented and might soon
be available, the per document pass through is the main target for the
GSoC project.

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

Can PhotoPrint print PDF's? I wonder as it is so much advertised as
GutenPrint front end.

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

We want to concentrate on output device profiles with reasonable
assumptions for all the untagged input (opt-out paradigm).

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

I doubt that the project can make toolkits fit for tagging input
correctly. That might need further discussion about CM in these toolkits
first.

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

I am in favor of a profile selection choice per print job. This has so
many advantages. The print UI is possibly the only useful place for that
selection at all.

> 3. CUPS
>
>
> A. We should be able to leverage the work done on the colord
> integration if the GSoC project is based on Oyranos.
>

I can not see where this would make sense.
Again colord hooks deeply into the print server circumventing many CUPS
access barriers.
I do not see Oyranos in following this model without real need.
Oyranos is way ahead when it comes to maintain the device calibration.

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

kind regards
Kai-Uwe