<!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 Sunday, May 15, 2011 04:53:01 PM Alastair M. Robinson wrote: > Hi, > > On 15/05/11 23:43, Hal V. Engel wrote: > > 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. > > Are there any at all, besides Scribus? I almost asked the same question when I did the write up. I suspect that Scribus could in fact be the only one. > > > 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. > > Last time I tested the Poppler-based filter it failed miserably on the > Altona and Ghent test suites, but in the simplest case (sRGB input, > printer profile output) it worked. It appears that poppler has to be built with specific options to do CMYK output correctly. I think it needs something other than the default back end for this to work since the default back end, cairo, is limited to RGB. I have mine built with the splash back end but I have not tested CMYK output yet. Also it appears that virtually all distros ship poppler with the default back end. > > > 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. > > It shouldn't be difficult to modify the toolkits such that as a starting > point they use sRGB ICCBased instead of DeviceRGB (should it?). That should be a simple change. I looked at the Qt PDF code back in Feb. and making this change would only involve perhaps a half dozen lines of C++ code and having the sRGB and Gray profiles imbedded as a resource to get this working. I have three related bug reports in for the Qt PDF print/paint pipeline for several months now (since Feb.) and the only comments are from Kai-Uwe. The bugs have been assigned to a developer but he appears to be working mostly on OpenGL and XOrg related issues. So there appears to be little interest in addressing issues related to CM. These three reports are for higher level bugs (IE. no way for apps to correctly tag objects) and I have not created a bug report asking for the default tags to be corrected but I added a comment asking for this as a minimal short term fix. You are correct that an easy first step is to stop using DeviceXXX and instead create PDFs with objects tagged as sRGB.icc or gray.icc since the code is not capable of creating anything other than RGB and gray output. One added feature set in Qt4 to QColor is suport for color types other than RGB such as CMYK and HSV as well as support for floating point color values. But none of the Qt image/bit map objects support anything other than 8 bit (or less) RGB or Gray (single channel) images. This is the primary reason for the lack of high bit depth and CMKY support in the Qt PDF engine since it only allows for QImages to be inserted in the any paint device including a printer. Here are the bug reports. http://bugreports.qt.nokia.com/browse/QTBUG-17386 http://bugreports.qt.nokia.com/browse/QTBUG-17387 http://bugreports.qt.nokia.com/browse/QTBUG-17388 It might help this to move forward if these bugs had more user activity. So please sign up at http://bugreports.qt.nokia.com and vote for these and/or add comments. > Assuming the toolkit maintainers can be persuaded of the importance of > such a change, that is! I think this is the real issue and it can be a difficult one to deal with. > > > * 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. > > PhotoPrint is a special case because it bypasses the normal print > pipeline. This is a double-edged sword. On the positive side, it means > PhotoPrint (when printing to Gutenprint-supported printers) is > guaranteed to be immune to unwanted colour-mangling downstream in the > pipeline. On the negative side, it's a different enough workflow that > it's harder to be confident that settings are perfectly in sync between > Photoprint and a regular print dialog. This problem would be mitigated > significantly by having print settings embedded in profiles, mind you. > The only other issue with PhotoPrint is that I have next to no time > available for programming at the moment, and that's not likely to change > in the forseeable future. Would you accept patches from the GSoC student or someone from this list? > > > 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. > > I imagine such an option probably wouldn't be something specifically > implemented in the print UI, but something in the PPD that becomes > presented by the UI like any other PPD option would be. This might be a way to prototype CM options in the UI since this could be done by modifying a single PPD. But for production this means that all PPDs need to be modified and that puts this in the hands of various printer/driver vendors some of whom may ignore this and not modify their PPDs. > > > Perhaps producing one or more example PPDs that do this correctly > > > > is a good idea for the prototype. > > Definitely. > > All the best > -- > Alastair M. Robinson </body></html>