[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management

[Alastair M. Robinson]

Hi

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
> PPDs.

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