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

[Kai-Uwe Behrmann]

Am 16.05.11, 23:07 +0100 schrieb Alastair M. Robinson:
> On 16/05/11 19:41, Hal V. Engel wrote:

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

agreed

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

How can the toolkit silently assume imagery is sRGB if that information is 
not provided by the application in the first place? Doing so could break 
applications relying on that behaviour. However as Qt5 is going to happen 
sometime it might be the time to introduce that soon to get that into 
upstream Qt5 during the Qt4->Qt5 transition.

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

oh no. Forking without real maintainer is not nice.

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

A CMS can provide this. It might be too hard for applications to do the 
PPD manipulations by their own. Oyranos is designed towards to accept a 
few calls which provide the print context to the CMS in order to get the 
colour management related work done. At the moment it needs more work in 
Oyranos for that to be a) stable and b) feature complete.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org