<!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 Friday, June 24, 2011 11:14:26 AM Till Kamppeter wrote: > On 06/21/2011 07:17 PM, Hal V. Engel wrote: > > I have already open bug/feature reports for CM in Qt generated PDF spool > > files. I don't expect this to be worked on anytime soon however. At this > > point these have been assigned to someone but the only comments are from > > members of this list. In addition the priority of the three items is set > > to P4: low. Till is there something we can do to get the priority of > > these bumped up? > > > > http://bugreports.qt.nokia.com/browse/QTBUG-17387 > > > > http://bugreports.qt.nokia.com/browse/QTBUG-17388 > > > > http://bugreports.qt.nokia.com/browse/QTBUG-17386 > > John, can you take some influence on the Qt developers here to get the > color management issues fixed more quickly? Thanks. > > Till Till, These are PDF specific. At the time I wrote the above I didn't know what direction Qt5 was going with it's PDF stuff. But in light of what John has writen here: http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Printing I think we need to work this into those plans. It appears that Qt5 will be seperating the PDF creation stuff into a new public class. I would think that the CM work to the PDF generator should be part of the new public class rather than the existing but soon to be obsolete private class. Since the new public class could have an extended more robust API (the current PDF generator has a very simplistic API which is one of the reasons that it creates malformed PDFs) it should be possible to extend the API to allow for things like color space tagging, higher bit depth images, CMYK images, DeviceN images and output intent (PDF-X). All of those things are needed for a robust CM based printing work flow and also for a resonably complete generalized PDF creation API and none of these are supported by the current API. The concern I have is that the PDF class could be seperated into a public class and still have the old overly simple API in the initial release of Qt5. This could make the migration to a more complete PDF API difficult later. So I think that having a robust PDF generation API in the new pulic PDF class is the main issue we should focus on. Doing this will also make it easy to fix the vast majority of CM related issues with the current Qt print engine. Also perhaps the Scribus folks would be willing to help define the new Qt PDF API? They are after all the ones with the most expertise in this area. Hal </body></html>