[Openicc] - CM Framework - Printer Driver - output intent - PDF specs
Hal V. Engel
hvengel at gmail.com
Fri Jun 24 12:11:30 PDT 2011
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.
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openicc