[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management
Alastair M. Robinson
blackfive at fakenhamweb.co.uk
Mon May 16 15:07:19 PDT 2011
On 16/05/11 19:41, Hal V. Engel wrote:
> 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.
Indeed - I tried building Poppler with Splash, and couldn't get it to do
anything useful, then ran out of time to play with it. In particular,
if memory serves the Gtk demo app would no longer build with the
alternative backend enabled.
> 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.
OK. One can hope that a specific bug report (with a patch attached!)
would have more luck!
> 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.
Yes, I think it's pretty much the same story with Cairo and GTK
> I think this is the real issue and it can be a difficult one to deal with.
Well, if migrating from /DeviceRGB to /ICCBased sRGB is a simple enough
change, it can be handled at the distribution level if need be.
> Would you accept patches from the GSoC student or someone from this list?
Yes, absolutely, though I'd think twice about exposing a GSoC student to
my C++! (PhotoPrint's been a pet project I've used while learning C++,
so it does contain a few WTFs.) Anyhow, Alexandre's been trying to
persuade me to set up a public repo for my projects for some time now,
and it's something I'd like to do at some point.
It may actually make more sense to fork PhotoPrint for target printing,
or create a new application using its framework. GPLin may rovide some
useful reference code too. (And of course is built on the same framework.)
> 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
Actually I think what we really need is a clean way of editing / adding
to PPDs; I don't see how else we can provide a clean way of associating
profiles and option sets, while still accounting for the one-to-many
relationship between a set of settings and ICC profiles.
All the best
Alastair M. Robinson
More information about the openicc