[Printing-architecture] Common Printing Dialog and color management

[Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

I've been doing quite a lot of research in to the Common Printing
Dialog in the last two days for my colord integration. I'm really not
sure where it fits in my color managed architecture plans.

From my perhaps-naïve point of view, CPD seems to have 3 main problems:

* There hasn't been any code merged in 5 *years*, even though quite a
lot of code has already been written.
* Neither GTK or KDE seem to want to include a new UI that doesn't
match either of their HIG guidelines.
* Every single PPD file on the planet would need to be modified to
support the CPD.

So basically, I'm not sure what the CPD buys us. Looking at
http://wiki.openusability.org/wiki/printing/index.php/Photo_printers_parameter_specifications#Color_Management_and_the_CPD
I'm not convinced mixing the color management settings in with the
printing options makes a lot of sense either.

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[peter sikking]

Richard Hughes wrote:

> I've been doing quite a lot of research in to the Common Printing
> Dialog in the last two days for my colord integration. I'm really not
> sure where it fits in my color managed architecture plans.
> 
> From my perhaps-naïve point of view, CPD seems to have 3 main problems:
> 
> * There hasn't been any code merged in 5 *years*, even though quite a
> lot of code has already been written.
> * Neither GTK or KDE seem to want to include a new UI that doesn't
> match either of their HIG guidelines.

both KDE and GNOME will happily take the patches. there is a lot of
enthusiasm for it at both platforms. just not to do the work. so we
have to get it to work as a large infrastructure project, then it
can go in.

about the HIG: in the spec you are looking at is a KDE/GNOME agnostic
meta spec, the implementation is done for KDE and GNOME separately,
fully HIG-compliant.

> * Every single PPD file on the planet would need to be modified to
> support the CPD.

Till has ensured that the cpd is backward compatible with any
(decent) PPD file on the planet. apart from that all major
printer manufacturers have been planning and gearing up for
PPD amending that will unlock the full cpd potential.

> So basically, I'm not sure what the CPD buys us. Looking at
> http://wiki.openusability.org/wiki/printing/index.php/Photo_printers_parameter_specifications#Color_Management_and_the_CPD
> I'm not convinced mixing the color management settings in with the
> printing options makes a lot of sense either.


now it is getting interesting.

I am not sure what you mean exactly. please be a bit more
precise about what you do not see working, from which perspective
(technical, color workflows, or something else).

    --ps

        founder + principal interaction architect
            man + machine interface works

        http://blog.mmiworks.net: on interaction architecture

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 15:36, peter sikking <peter@mmiworks.net> wrote:
> both KDE and GNOME will happily take the patches.

I'm afraid that just isn't true for GNOME. I work quite a bit on GTK
and GNOME (my boss is Matthias Clasen...), and I can tell you that
there would be no way such a non-standard looking dialog would be
merged into such a core part of the toolkit. There would have to be a
very compelling reason to move the printer dialog out of process as
this would greatly complicate the printing process. It would also be a
massive API and ABI break, and considering GTK3 has just released, I
see quite unlikely.

> there is a lot of enthusiasm for it at both platforms.

But no contributors? No upstream commits in 5 years?

> about the HIG: in the spec you are looking at is a KDE/GNOME agnostic
> meta spec, the implementation is done for KDE and GNOME separately,
> fully HIG-compliant.

It's not a meta-spec, it's a Human Interface Guideline specific to the
GNOME desktop. If we're making a CPD implementation to work to the
GNOME HIG, it's not going to look anything like the CPD implementation
for KDE. So then we're just left with a DBus interface that can't
actually do anything much more than we could before.

>> So basically, I'm not sure what the CPD buys us. Looking at
> I am not sure what you mean exactly. please be a bit more
> precise about what you do not see working, from which perspective
> (technical, color workflows, or something else).

These are my three target users: http://colord.hughsie.com/profiles.html

None of these people would be able to choose an option from a dropdown
just listing the ICC filenames by filename. And they shouldn't have to
when we can map from qualifier to icc profile automatically...

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 24, 2011, at 10:05 AM, Richard Hughes wrote:

> It's not a meta-spec, it's a Human Interface Guideline specific to the
> GNOME desktop. If we're making a CPD implementation to work to the
> GNOME HIG, it's not going to look anything like the CPD implementation
> for KDE. So then we're just left with a DBus interface that can't
> actually do anything much more than we could before.

I think the CPD in the wiki is meant to be a very rudimentary mockup to provide a visual is all. I don't think it's meant to be fixed in stone. Naturally it needs to fit into the HIG for Gnome and KDE independently, and be conscious of how it would be presented on mobile platforms one day in the near future as well. So it can't be using 95% white space like the mockups do. To me, it's understood because it's unworkable as a fixed layout.

> 
>>> So basically, I'm not sure what the CPD buys us. Looking at
>> I am not sure what you mean exactly. please be a bit more
>> precise about what you do not see working, from which perspective
>> (technical, color workflows, or something else).
> 
> These are my three target users: http://colord.hughsie.com/profiles.html
> 
> None of these people would be able to choose an option from a dropdown
> just listing the ICC filenames by filename. And they shouldn't have to
> when we can map from qualifier to icc profile automatically...

Agreed. Also I'll point out we shouldn't list ICC profiles by filename anyway. They have internal names and that's what the user should see. If you have rollovers that show a URI for where this profile is located, that could show filename.


Chris Murphy

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 17:34, Chris Murphy <lists@colorremedies.com> wrote:
> Naturally it needs to fit into the HIG for Gnome and KDE independently...

http://people.freedesktop.org/~hughsient/temp/CommonPrintDialog.png

I'm not sure there is a HIG rule that isn't being broken in that
screenshot. The current GTK print dialog isn't perfect by any means,
but it at least confirms to the HIG and users are familiar with where
the controls are located.

> If you have rollovers that show a URI for where this profile is located, that could show filename.

I'm not sure the filename and path is interesting in any way
whatsoever. It's just an implementation detail.

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[peter sikking]

Richard Hughes wrote:

> http://people.freedesktop.org/~hughsient/temp/CommonPrintDialog.png
> 
> I'm not sure there is a HIG rule that isn't being broken in that
> screenshot.

funny, I did not even recognise that screenshot as having anything
to do with the cpd design.

where on earth did you find that?

very funny to fuel a discussion based on that.

    --ps

        founder + principal interaction architect
            man + machine interface works

        http://blog.mmiworks.net: on interaction architecture

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 17:59, peter sikking <peter@mmiworks.net> wrote:
> where on earth did you find that?

The gtk-dialog example in the common-printing-dialog bzr repository.

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[peter sikking]

Richard Hughes wrote:

> On 24 February 2011 17:59, peter sikking <peter@mmiworks.net> wrote:
>> where on earth did you find that?
> 
> The gtk-dialog example in the common-printing-dialog bzr repository.


and the development state of that part of the project is..?

    --ps

        founder + principal interaction architect
            man + machine interface works

        http://blog.mmiworks.net: on interaction architecture

Re: [Printing-architecture] Common Printing Dialog and color management

[Hal V. Engel]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Thursday, February 24, 2011 10:17:57 AM Richard Hughes wrote:
> On 24 February 2011 17:59, peter sikking <peter@mmiworks.net> wrote:
> > where on earth did you find that?
> 
> The gtk-dialog example in the common-printing-dialog bzr repository.
> 
> Richard.
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Are you sure your looking in the right place?  I have been mostly looking at 
the Qt/KDE version so I was not sure what the GTK version looked like but I 
was pretty sure it was very similar to the Qt/KDE version.    I just had a 
look at the current GTK version to make sure and the screen shot looks nothing 
like it.  The Qt/KDE and GTK versions of the CPD have  stylistic differences 
that you would expect between GTK and Qt versions of the same app and the GTK 
dialog and it's preview are bigger than the Qt/KDE version.  But both are way 
different from your screen shot.

Hal

[-- Attachment #2: Type: text/html, Size: 3595 bytes --]

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

From the wiki URL provided on the CPD, I have a few concerns:

1. "Showing paper color" is fraught with peril and can totally set up the wrong end user expectations. The issue of chromatic adaptation is really not straight forward because user adaptation is unknown. They could be partially adapted, fully adapted, or not at all adapted. State of user adaptation needs to be known to do this in a way that doesn't actually hurt the user and make things worse. I definitely would not have this feature on by default. Professionals in some ways shouldn't need it because their display white should be fairly close to paper white anyway, otherwise they have even more serious adaptation issues. And last, the surrounding white point will be the display native white point, and when you have a small preview that "shows paper color" you have color appearance surround effects that really necessitate the inclusion of a color appearance model to do the simulation correctly. None of this is the case right now. So I'm not sure really why this is being included, who exactly it's going to help - what's the usage scenario.

Yes Photoshop does this in their print dialog, I don't think it's that useful, honestly. Maybe the motivation is coming from users used to Photoshop, I'm not sure.

2. There is this notion that "high end users" will want to be able to quickly turn off color management. This is confusing in the wiki. What the high end user wants is to ensure there isn't a conflict between application pre-matching content for print, and then the downstream doing additional conversions (i.e. in GhostScript/lcms). So yes, if those applications depend on pre-matching, you will need a clear mechanism for this to be disabled in the print dialog. I will warn that this area is also fraught with peril based on experiences with Mac OS and Windows. 

a. First I'd question why we even have applications that prematch data. Historically this has been because certain features weren't available downstream in the printing pipeline, like black point compensation, so we had to convert using RelCol+BPC in the application. If the printing architecture allows for RelCol+BPC, then there's no reason to clutter the workflow with color management options in the application, and color management options in the print dialog.

b. The instant you're going to have two sets of controls for color management, application and print dialog, you end up in the snare we've been in for almost 10 years on Mac OS and Windows that I would like to see not engineered again if possible. I think it's possible everyone who has put in their two cents into this color management in the CPD are simply used to this paradigm and it seems to make sense. I think it's an atrocious user experience, even for high end users. If we can do better, we should do better. Two sets of conflicting color management settings: application and print dialog is just, inane. So what Apple did was come up with a way to get the application to communicate its intent to prematch data, in an (very undocumented way, something open source doesn't tend to need to be as worried about), and thereby get the print dialog's defaults to automatically disable print pipeline color management so that there would not be this effect called "double color management." If the document is color managed twice, especially with assumptions, we end up with a mess.

So that's why I go back to a. If the print architecture is sophisticated enough, seems like if the application is going to use the CPD, that it would know that it doesn't need to prematch because it's using a new CPD that understands proper color management. And in that case does not need to present conflicting settings to the user that the user will then have to sort out; or that engineers of this system will have to compute contingencies for.

3. So I'm going to go out on a ledge and say, with not much effort, you could build a system that meets the requirements of low, mid, and high end users and consolidate the behaviors that are in the three bullet points under the chart in the wiki. I find the implied workflow in those three bullet points to be confusing, misleading, and well - basically untrue although I understand where they're coming from due to our legacy past on Windows and Mac OS. (And I am considering those legacy because those OS's have inherited some nasty baggage for various reasons).

4. "Soft proof" I wish we could remove this term from our lexicon. This is a very high end feature that is really difficult to achieve even for very high end users. It requires an extremely standardized environment, or it requires the use of advanced color appearance models. I have no issue with ensuring that it can be implemented into user's workflows, but the idea that "mid end users" will be using a CPD preview to soft proof is a lunacy asylum. It's not going to help them one little bit and it adds unnecessary engineering that will not work at all. Maybe the original idea behind this is "fake soft proofing" versus "real soft proofing" but when I use the term soft proofing I am thinking of an event where there is a very close similarity between print and preview. This is very difficult to arrive at for most users because they're in non-standard viewing conditions, and simply the quantity of light available can make the different between "spot on" and "ew that's a dark print". It's not subtle.

5. I think the CPD probably needs to interface with colord, to present one of four possibilities for the destination profile (the printer profile), in order of priority:
	a.) A custom profile chosen by the user, directly in the CPD.
	b.) An indication that the application is going to prematch data. I realize I'm arguing against this is in 2a above, but if it's going to be an enabled workflow anyway, then the CPD should inform the user that the application is set to prematch data, not require them to choose such a "set by application" option. I'm not sure if there is a role here for colord to get this info from the app, or if the app talks to the CPD directly. Probably the later.
	c.) The profile for the printing condition based on *cupsICCProfile which I think colord is going to be aware of, so in this case colord forwards this setting to the CPD.
	d.) The profile for the printing condition based on *cupsICCProfile not being present in (legacy) PPDs. We need to assume something, what's it going to be? This is probably sRGB for any desktop inkjet printer, and might even work for quite a few color laser printers, which can receive both RGB and CMYK data. If the printer is CMYK only and you don't have *cupsICCProfile in the PPD and you don't have a user selection - well you're basically screwed but you have to pick something, or fail the job. And almost no matter what you pick for CMYK it will be wrong. So we probably need some really conservative CMYK space to use that is probably a separate discussion.

So at the very least, in c. colord needs to integrate with the CPD and let it know what that *cupsICCProfile is. And in the case of d.) we might want colord forward a user chosen default to the CPD, so the user doesn't have to keep choosing something sensible, if the default colord has in mind is not ideal.

6. "Using the preview" section of the wiki. 

a.  On the one hand the wiki says "This is an essential part of describing and showing exactly what a user is getting" and then proceeds to show a mockup of the print dialog where "auto assign" and "automatic" are used for ICC color profile and Rendering intent. This is confusing because automatic is just another word for random. It's definitely not describing anything exact. There is a cascading set of fallback for an automatic population of this dialog, but it should show exactly what is going to be used. Auto is not exact.

b.  Also, the term "ICC color profile" is vague. What's this profile referring to? Is it a source profile? Is it an intermediate profile? Is it a destination profile? It should be specific. Maybe it should say "Printer profile".


7. I think having "ICC color profile" and "rendering intent" in two different parts of the print dialog is confusing. Pick one area, stick with it.


I think that's all I have at the moment.

Chris



On Feb 24, 2011, at 8:36 AM, peter sikking wrote:

> Richard Hughes wrote:
> 
>> I've been doing quite a lot of research in to the Common Printing
>> Dialog in the last two days for my colord integration. I'm really not
>> sure where it fits in my color managed architecture plans.
>> 
>> From my perhaps-naïve point of view, CPD seems to have 3 main problems:
>> 
>> * There hasn't been any code merged in 5 *years*, even though quite a
>> lot of code has already been written.
>> * Neither GTK or KDE seem to want to include a new UI that doesn't
>> match either of their HIG guidelines.
> 
> both KDE and GNOME will happily take the patches. there is a lot of
> enthusiasm for it at both platforms. just not to do the work. so we
> have to get it to work as a large infrastructure project, then it
> can go in.
> 
> about the HIG: in the spec you are looking at is a KDE/GNOME agnostic
> meta spec, the implementation is done for KDE and GNOME separately,
> fully HIG-compliant.
> 
>> * Every single PPD file on the planet would need to be modified to
>> support the CPD.
> 
> Till has ensured that the cpd is backward compatible with any
> (decent) PPD file on the planet. apart from that all major
> printer manufacturers have been planning and gearing up for
> PPD amending that will unlock the full cpd potential.
> 
>> So basically, I'm not sure what the CPD buys us. Looking at
>> http://wiki.openusability.org/wiki/printing/index.php/Photo_printers_parameter_specifications#Color_Management_and_the_CPD
>> I'm not convinced mixing the color management settings in with the
>> printing options makes a lot of sense either.
> 
> 
> now it is getting interesting.
> 
> I am not sure what you mean exactly. please be a bit more
> precise about what you do not see working, from which perspective
> (technical, color workflows, or something else).
> 
>    --ps
> 
>        founder + principal interaction architect
>            man + machine interface works
> 
>        http://blog.mmiworks.net: on interaction architecture
> 
> 
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 17:23, Chris Murphy <lists@colorremedies.com> wrote:
> We need to assume something, what's it going to be? This is probably sRGB for any desktop inkjet printer...

This is something I've been struggling with for the last couple of
days. I think it's sane to assume the default profile to use with
untagged content or for a missing device profile is going to be sRGB.
Does this even need to be configurable?

If yes, is it device-specific, user specific or system specific?
Surely if you're worried about the default fallback colorspace, you
might as well manually assign the specific output profile to the
specific device and then you don't care about the fallback anymore.

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 24, 2011, at 10:33 AM, Richard Hughes wrote:

> On 24 February 2011 17:23, Chris Murphy <lists@colorremedies.com> wrote:
>> We need to assume something, what's it going to be? This is probably sRGB for any desktop inkjet printer...
> 
> This is something I've been struggling with for the last couple of
> days. I think it's sane to assume the default profile to use with
> untagged content or for a missing device profile is going to be sRGB.
> Does this even need to be configurable?

Probably not. But, if it will be assumed to be sRGB, then the CPD "Printer profile" popup menu should be populated with sRGB IECblahblah blah, and not "auto assign" which just makes me want to poke myself in the eye with a stick.

For CMYK printers, well it's another matter because a default CMYK profile for a printing press might cause problems on a CMYK only inkjet or laser printer or copier. Those are rare workflows, usually it's a customer or canned CMYK profile from a manufacturer, or the print driver will accept incoming RGB and convert internally to CMYK in some magic black box manner. But it's possible we need to consider a CMYK path all the way to the printer: it's legitimate to just make that CMYK path a pass through option. In which case it would be great if the CPD knows already what the application is going to be printing with some metadata (hey it's already getting a thumbnail preview, why not the color space of the image?) and the CPD can say "CMYK Passthrough" for the default "Printer profile" option. Not a bad punt for now actually....might be best to just leave CMYK untouched.


> If yes, is it device-specific, user specific or system specific?
> Surely if you're worried about the default fallback colorspace, you
> might as well manually assign the specific output profile to the
> specific device and then you don't care about the fallback anymore.

I'm thinking of users. Not rational beings. The only reason why I'm considering it at all is because I'm inclined to not consider it at all, and that is often a red flag for missing something important. I don't think it is in this case, I think you can just have your last fall back as sRGB for RGB and CMYK pass through for CMYK. For grayscale - well hmmm, it could go either way. Use the sRGB curve, or leave it as it is.


Chris

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 17:41, Chris Murphy <lists@colorremedies.com> wrote:
> ...and not "auto assign" which just makes me want to poke myself in the eye with a stick.

Heh, you made me laugh out loud.. :-)

> Not a bad punt for now actually....might be best to just leave CMYK untouched.

Yup, that was my strategy too.

> I'm thinking of users. Not rational beings.

Fair point, but even non-rational beings shouldn't have to understand
what a fallback profile is used for.

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 24, 2011, at 10:46 AM, Richard Hughes wrote:

> On 24 February 2011 17:41, Chris Murphy <lists@colorremedies.com> wrote:
>> ...and not "auto assign" which just makes me want to poke myself in the eye with a stick.
> 
> Heh, you made me laugh out loud.. :-)

It's more sensible to put "No Idea" everywhere you'd see "Automatic".


>> Not a bad punt for now actually....might be best to just leave CMYK untouched.
> 
> Yup, that was my strategy too.

It's consistent with Windows and Mac OS also. *shrug* And that's not a bad thing in this instance.

> 
>> I'm thinking of users. Not rational beings.
> 
> Fair point, but even non-rational beings shouldn't have to understand
> what a fallback profile is used for.

No, I don't know that it makes sense to spin precious engineering cycles on them either. That's why I'm not a fan of this distinction of "low end, mid end, high end" user and all the different paths and behaviors this implies coding for. I think you build one path, one set of logical structures, it includes all the users. Even a high end user can be a low end user when they print to a color laser printer and don't care about super accuracy. And even a low end user wants to start out with prints that don't look like dog crap out of the gate before they choose some option to make it look "better".

Chris

Re: [Printing-architecture] Common Printing Dialog and color management

[Kai-Uwe Behrmann]

Am 24.02.11, 10:52 -0700 schrieb Chris Murphy:
> On Feb 24, 2011, at 10:46 AM, Richard Hughes wrote:
>> On 24 February 2011 17:41, Chris Murphy <lists@colorremedies.com> wrote:
>>> Not a bad punt for now actually....might be best to just leave CMYK untouched.
>>
>> Yup, that was my strategy too.
>
> It's consistent with Windows and Mac OS also. *shrug* And that's not a bad thing in this instance.

As soon as somewhere in the print path appears a Cmyk default, its a 
failed assumtion. Not actual robust.

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

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 24, 2011, at 12:18 PM, Kai-Uwe Behrmann wrote:

> Am 24.02.11, 10:52 -0700 schrieb Chris Murphy:
>> On Feb 24, 2011, at 10:46 AM, Richard Hughes wrote:
>>> On 24 February 2011 17:41, Chris Murphy <lists@colorremedies.com> wrote:
>>>> Not a bad punt for now actually....might be best to just leave CMYK untouched.
>>> 
>>> Yup, that was my strategy too.
>> 
>> It's consistent with Windows and Mac OS also. *shrug* And that's not a bad thing in this instance.
> 
> As soon as somewhere in the print path appears a Cmyk default, its a failed assumtion. Not actual robust.

True. It would be wrong almost no matter what. Might as well just punt and make it a pass through color model. Same would be the case for DeviceN, and CMYK is much closer to DeviceN than are RGB and device independent spaces.

Chris Murphy

Re: [Printing-architecture] Common Printing Dialog and color management

[Kai-Uwe Behrmann]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1521 bytes --]

Am 24.02.11, 14:39 -0000 schrieb Richard Hughes:
> I've been doing quite a lot of research in to the Common Printing
> Dialog in the last two days for my colord integration. I'm really not
> sure where it fits in my color managed architecture plans.
>
> From my perhaps-naïve point of view, CPD seems to have 3 main problems:
> 
> * There hasn't been any code merged in 5 *years*, even though quite a
> lot of code has already been written.
> * Neither GTK or KDE seem to want to include a new UI that doesn't
> match either of their HIG guidelines.

As usual: citation needed. That leads to a contructive dialog.
Marginalisation is no good style.

> * Every single PPD file on the planet would need to be modified to
> support the CPD.

You can not be serious about this.

> So basically, I'm not sure what the CPD buys us. Looking at
> http://wiki.openusability.org/wiki/printing/index.php/Photo_printers_parameter_specifications#Color_Management_and_the_CPD
> I'm not convinced mixing the color management settings in with the
> printing options makes a lot of sense either.

CPD runs as a user process. Thus the user relation is first class. While 
xxxtoraster is a server side process running as user lp. How might lp 
know, which ICC profile is the actual one and from which user? On 
which mechanism does the scheme rely on? It was brought up several 
times. I never read a convincing answere for that question.


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

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 24, 2011, at 12:13 PM, Kai-Uwe Behrmann wrote:
> 
> 
>> * Every single PPD file on the planet would need to be modified to
>> support the CPD.
> 
> You can not be serious about this.

Well in a set of slides I found from the Open Printing Summit 2009, the CPD is expected to use the Extended Format proposed for PPD. So if that's still proposed and not done...

If I read these slides right, there is built in graceful degradation of the CPD in terms of options, depending on platform: no GUI, mobile GUI, reduced GUI (netbook, regular user default on desktop perhaps), and expanded. In order for the CPD to be drawn correctly and degrade options properly for each of these levels, its seems to me that the PPDs would need to be modified.


> 
>> So basically, I'm not sure what the CPD buys us. Looking at
>> http://wiki.openusability.org/wiki/printing/index.php/Photo_printers_parameter_specifications#Color_Management_and_the_CPD
>> I'm not convinced mixing the color management settings in with the
>> printing options makes a lot of sense either.
> 
> CPD runs as a user process. Thus the user relation is first class. While xxxtoraster is a server side process running as user lp. How might lp know, which ICC profile is the actual one and from which user? On which mechanism does the scheme rely on? It was brought up several times. I never read a convincing answere for that question.

The profiles to use get rolled into the PDF print spool file at the time it's created (or modified using a pdftopdf filter). If the user has specified one, it would definitely need to be in the PDF print spool file, or we're going to need a sidecar for metadata...eek. I see no reason why it can't go in the PDF using CUPS PDF which supports such job ticket info.

Chris

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

OK I just thought of a reason why you can't always punt and pass through CMYK. It's possible an application will print a CMYK document, and the printer has no idea what CMYK is. In that case you either have to fail the print job, or you have to assume some CMYK space (like FOGRA39 or GRACoL or whatever), and convert to RGB probably sRGB or if there is a *cupsICCProfile convert to that.

So as long as it's CMYK to CMYK, you can pass through. If it's CMYK to RGB you'd need other handling.

Chris Murphy

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 21:42, Chris Murphy <lists@colorremedies.com> wrote:
> In that case you either have to fail the print job, or you have to assume some CMYK space

So, in the case of CYMK, it's not just as case where we can "assume
sRGB" like we can RGB with a clear conscience. It kinda comes back to
my original question, is this a per-user preference, or a per-system
policy?

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 24, 2011, at 3:08 PM, Richard Hughes wrote:

> On 24 February 2011 21:42, Chris Murphy <lists@colorremedies.com> wrote:
>> In that case you either have to fail the print job, or you have to assume some CMYK space
> 
> So, in the case of CYMK, it's not just as case where we can "assume
> sRGB" like we can RGB with a clear conscience. It kinda comes back to
> my original question, is this a per-user preference, or a per-system
> policy?

Ha it's a per instance preference. The document should be self describing (tagged) to prevent this event from being questionable in the first place. In my view any application that lets a user work on CMYK that does not tag its own data is asking for trouble - by rights CMYK print jobs going to non-CMYK devices should fail. But that's not such a great sort of degradation for users.

Apple and Microsoft require applications to honor conversion to RGB on demand - i.e. the system knows the driver being selected is RGB at the time the dialog pops up and the printer is chosen and the system informs and requires the application submit RGB at the time the job is spooled. So that makes conversion the responsibility of the application. Not the system. I tend to agree with this strategy.

Farther downstream, I would think GhostScript has some assumption it uses when incoming file is CMYK and outgoing file must be RGB (or vice versa). I don't know presently where this logic is handled.

If you're going to have some system level service handle this correction, well you have various points where that could occur and if you're really going to build such a thing, you might consider including spot color and DeviceN into the plan so that, even if you don't build in such support now, you don't have an "oh shit" later on when you find the location where this is handled in the print pipeline is not ideal. Ideal would mean downstream from the app, but upstream from rasterizing, but downstream enough to know the capabilities of the printer, even in fact how well it registers colors is a nice bit of info to have when properly building device values for print.


Chris

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 22:27, Chris Murphy <lists@colorremedies.com> wrote:
> In my view any application that lets a user work on CMYK that does not tag its own data is asking for trouble

Isn't any app capable of outputting CMYK going to ask the user for an
embedded profile? Outputting CMYK is a pretty power-user feature, and
unspecified CMYK isn't really anything useful at all.

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 24, 2011, at 3:43 PM, Richard Hughes wrote:

> On 24 February 2011 22:27, Chris Murphy <lists@colorremedies.com> wrote:
>> In my view any application that lets a user work on CMYK that does not tag its own data is asking for trouble
> 
> Isn't any app capable of outputting CMYK going to ask the user for an
> embedded profile? Outputting CMYK is a pretty power-user feature, and
> unspecified CMYK isn't really anything useful at all.

Unknown / not necessarily. It's only been in the last few years that Photoshop started embedding ICC profiles in CMYK images by default. It is common in prepress (usually due to emotionally unstable reasons) to strip CMYK profiles from images and save them untagged.

How they became CMYK? Well they can get there by creating a CMYK illustration file from scratch and designing in CMYK. No conversion to CMYK actually occurred. But yes, to display that CMYK image/illustration on an RGB device implies some kind of transform. Whether it's ICC based or not...usually that would be the case. But historically developers have simply used inversion. 100%C is 0%R (100%G+100%B), etc. which gets you really overly saturated CMYK images on screen, completely not color accurate. But you can at least see what you're doing. Recent versions of QuarkXPress work this way I think still, by default. So I can't vouch for apps on Linux, how they will behave with respect to CMYK. They very well may be thinking of plotters and such and never have considered anything other than RGB for display, and therefore just used 1/d conversion.


Chris

Re: [Printing-architecture] Common Printing Dialog and color management

[Richard Hughes]

On 24 February 2011 22:51, Chris Murphy <lists@colorremedies.com> wrote:
>  It is common in prepress (usually due to emotionally unstable reasons) to strip CMYK profiles from images and save them untagged.

Urgh. Uncool. In this situation, won't the "press" be doing something
custom with Ghostscript and not just clicking "File->Print, OK" and
hoping for the best?

Richard.

Re: [Printing-architecture] Common Printing Dialog and color management

[Chris Murphy]

On Feb 25, 2011, at 2:10 AM, Richard Hughes wrote:

> On 24 February 2011 22:51, Chris Murphy <lists@colorremedies.com> wrote:
>> It is common in prepress (usually due to emotionally unstable reasons) to strip CMYK profiles from images and save them untagged.
> 
> Urgh. Uncool. In this situation, won't the "press" be doing something
> custom with Ghostscript and not just clicking "File->Print, OK" and
> hoping for the best?

Prepress already has a specific press condition in mind by the time they are manipulating files, and so they are producing /DeviceCMYK + spot PDF that they expect a RIP to honor exactly. All color management is assumed to have occurred a long time before this, usually in native application files. So the app does this conversion and produces a press ready PDF that is completely untagged.

There are cases were prepress insists on stripping profiles in CMYK TIFF and JPEG also, and then dropping those into a page layout application. They too have been converted to CMYK for a specific press condition and absolutely positively do not want them getting converted again, so in their rule book the best way to ensure there aren't any additional conversions of CMYK TIFF that might have black only text treatment in them (which become 4 color black text if they are converted, which is instantly a crap print job someone has to eat, usually prepress), or any number of other registration anomalous behaviors, they strip embedded color profiles from documents: TIFFs, JPEG, EPS, PDF, you name it. /DeviceCMYK is the way it's done.

And of course, color on the web is a problem. No tags there at all. Stripped on purpose. And I know very very few readers that honor EXIF metadata which often contains Adobe RGB as the color space for the image. But apps that assume sRGB don't check EXIF and assume these Adobe RGB images are actually sRGB. Bad. EXIF color space is a big missing link for applications.


Chris Murphy