<!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 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. <ul style="margin-top: 0px; margin-bottom: 0px; margin-right: 0px; -qt-list-indent: 1;"><li style=" margin-top:12px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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.</li> <li style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Allow any app to print targets and have specialized target printing functionality in the print UI.</li></ul> 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. <ul style="margin-top: 0px; margin-bottom: 0px; margin-right: 0px; -qt-list-indent: 1;"><li style=" margin-top:12px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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.</li> <li style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">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.</li></ul> 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 </body></html>