[Openicc] - CM Framework - Printer Driver - output intent - PDF specs

[Hal V. Engel]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110624/4113a28f/attachment.htm>