[Openicc] GoSoC 2011: CPD and target printing

Scott Geffert scott at cdiny.com
Mon May 16 05:39:37 PDT 2011 

When I see "Open ICC"  on this list it implies that solutions should be universal and open. I think Graeme's point regarding standardized print processing and print dialogs is the way to go. 
> 
>> have a standard and routinely tested method for printing
>> in device space, then any and every application could be used
>> for reliably printing a test target.

Applications are currently unreliable because each party has been forced to create their own workarounds to address a lack of standards when it comes to print dialogs and processing. I argue that if we continue to cater to the status quo (printing charts only through Adobe or dedicated color apps) we are actually not truly addressing the problem. Frankly forcing users to use special applications in order to open up certain functionality runs counter to the idea of open standards.

I also like the idea of charts being tagged to trigger certain (null) behavior. I have enjoyed using the Mirage printing plug in for Epson printers in that when you attempt to print an untagged file the software places a watermark over the print preview that alerts the user that the file will be printed with no color management. This software has solved a lot of the current issues as it delivers consistent results regardless of the OS version or Adobe Product, but my problem is that users are forced to shell out money for a tool that would not be necessary at all if the print drivers were standardized across all operating systems. Also this tool only works via Photoshop and only works with Epson printers. The developers of tools like Mirage deserve credit for creating innovative tools that solve problems, but clearly it would be a whole lot better if these capabilities were built into the OS. With these foundations in place application developers can be freed up to develop innovative solutions instead of wasting resources chasing printing issues.

Imagine the cost to Adobe, Epson and other application developers to constantly chase this problem. It is in everyones best interest to move towards a more universal experience that fully supports ICC protocols.

Scott




On May 16, 2011, at 1:28 AM, openicc-request at lists.freedesktop.org wrote:

> Send openicc mailing list submissions to
> 	openicc at lists.freedesktop.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.freedesktop.org/mailman/listinfo/openicc
> or, via email, send a message with subject or body 'help' to
> 	openicc-request at lists.freedesktop.org
> 
> You can reach the person managing the list at
> 	openicc-owner at lists.freedesktop.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openicc digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Google Summer of Code 2011: The Common Printing Dialog
>      and Color Management (Richard Hughes)
>   2. Re: Google Summer of Code 2011: The Common Printing Dialog
>      and Color Management (Michael Sweet)
>   3. Re: GoSoC 2011: CPD and ... Mike Sweet workflow (Graeme Gill)
>   4. Re: GoSoC 2011: CPD and target printing (Graeme Gill)
>   5. Re: GoSoC 2011: CPD and ... Mike Sweet workflow (Chris Murphy)
>   6. Re: GoSoC 2011: CPD and target printing (Chris Murphy)
>   7. Re: Google Summer of Code 2011: The Common Printing	Dialog
>      and Color Management (Graeme Gill)
>   8. Re: Google Summer of Code 2011: The Common	Printing	Dialog
>      and Color Management (Chris Murphy)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 15 May 2011 21:23:16 -0400
> From: Richard Hughes <hughsient at gmail.com>
> Subject: Re: [Openicc] Google Summer of Code 2011: The Common Printing
> 	Dialog and Color Management
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <BANLkTikHfsJ_thr1Xf8Xkf4nXeQsbn0_ig at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On 15 May 2011 20:59, Michael Sweet <msweet at apple.com> wrote:
>> The major weakness I see in the colord DBUS interface is that registrations
>> go away when the registerer :) goes away...
> 
> Only for TEMP scope. When you do CreateDevice() or CreateProfile()
> then the first parameter is the ID, and the second is the scope.
> 
> Scope TEMP is 'process' (e.g. if CUPS crashes they get removed),
> NORMAL is 'system', i.e. gets removed on reboot but not on process
> exit, and DISK is permanent, and gets saved in a database to live
> across reboots.
> 
> Richard.
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 15 May 2011 18:54:26 -0700
> From: Michael Sweet <msweet at apple.com>
> Subject: Re: [Openicc] Google Summer of Code 2011: The Common Printing
> 	Dialog and Color Management
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <7ED3AA18-FDE8-451B-A5A2-4D3296EA9768 at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII
> 
> Hmm, that's different than I remember when you originally submitted your patches; sounds like we should be using DISK to be consistent with the semantics of ColorSync WRT cupsd...
> 
> On May 15, 2011, at 6:23 PM, Richard Hughes wrote:
> 
>> On 15 May 2011 20:59, Michael Sweet <msweet at apple.com> wrote:
>>> The major weakness I see in the colord DBUS interface is that registrations
>>> go away when the registerer :) goes away...
>> 
>> Only for TEMP scope. When you do CreateDevice() or CreateProfile()
>> then the first parameter is the ID, and the second is the scope.
>> 
>> Scope TEMP is 'process' (e.g. if CUPS crashes they get removed),
>> NORMAL is 'system', i.e. gets removed on reboot but not on process
>> exit, and DISK is permanent, and gets saved in a database to live
>> across reboots.
>> 
>> Richard.
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 16 May 2011 13:02:42 +1000
> From: Graeme Gill <graeme at argyllcms.com>
> Subject: Re: [Openicc] GoSoC 2011: CPD and ... Mike Sweet workflow
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <4DD093D2.3000401 at argyllcms.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Chris Murphy wrote:
>> I definitely don't want to see users printing targets from OpenOffice. It's completely
>> unreasonable to assume some random application does not implement color management
>> internally, regardless of what a CPD says is happening.
> 
> True, but this is exactly the point. If the color processing for each
> application is different and inscrutable, how can a test chart be
> reliably printed from any application ?
> 
> In contrast, if the standard print processing and print dialogs
> have a standard and routinely tested method for printing
> in device space, then any and every application could be used
> for reliably printing a test target.
> 
> [I do like the idea of this facility being a programmer option though,
>  allowing the complexity to be tailored to the intended application
>  audience.]
> 
> Graeme Gill.
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 16 May 2011 13:06:17 +1000
> From: Graeme Gill <graeme at argyllcms.com>
> Subject: Re: [Openicc] GoSoC 2011: CPD and target printing
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <4DD094A9.9060504 at argyllcms.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Chris Murphy wrote:
> 
>> On both Mac OS and Windows it's always been best practices, until recently, to print
>> targets from Photoshop with No Color Management, or directly from the profile
>> generation app (e.g. ColorMuni or Eye One Match). It is NOT best practices to do it
>> with a web browser, or a word processing application. I don't even test that workflow,
>> I would never recommend it, I do not expect that it should work correctly. Those apps
>> have nothing to do with custom profiling at all. I completely disagree with the idea
>> that every app should have the ability to print profile targets. It's one tenth of one
>> percent of the market.
> 
> You are quite right, that it's not practical. But note the problem with
> the Mac is that it stopped being possible to reliably print test charts
> in Photoshop and Apples own program, preview.
> 
> But again, this is my point - if the basic capability was inherent
> in the printing system, then any and every application would
> be reliably capable of printing test charts, better ensuring that the
> test chart prints reflect the all the other printing conditions accurately.
> 
> [ie. this moves things towards robust, away from brittle. ]
> 
> Graeme Gill.
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Sun, 15 May 2011 22:54:51 -0600
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] GoSoC 2011: CPD and ... Mike Sweet workflow
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <2A792478-04B3-4ABE-B909-95027A4F1118 at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> On May 15, 2011, at 9:02 PM, Graeme Gill wrote:
> 
>> Chris Murphy wrote:
>>> I definitely don't want to see users printing targets from OpenOffice. It's completely
>>> unreasonable to assume some random application does not implement color management
>>> internally, regardless of what a CPD says is happening.
>> 
>> True, but this is exactly the point. If the color processing for each
>> application is different and inscrutable, how can a test chart be
>> reliably printed from any application ?
> 
> I don't listen to music files with Photoshop, or LibreOffice, or TextEdit. Apps have purpose, I use them for their intended purpose.
> 
>> 
>> In contrast, if the standard print processing and print dialogs
>> have a standard and routinely tested method for printing
>> in device space, then any and every application could be used
>> for reliably printing a test target.
> 
> This is an assumption. You can't actually know this is true without testing it first.
> 
> There could be a mandate that any and every application doesn't do an upstream conversion prior to submission of the target to the print pipeline, but you'd then have to somehow create system induced booby trap to make any such application implode at launch as an indicator that it was unreliable and printing profile targets.
> 
> Otherwise you need a published matrix of apps that work according to the mandate of non-conversion prior to submission to the print pipeline, and those that don't.
> 
> I dunno but I think maintaining an API and one reference app is way, way easier than this.
> 
> 
> Chris Murphy
> 
> ------------------------------
> 
> Message: 6
> Date: Sun, 15 May 2011 23:05:38 -0600
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] GoSoC 2011: CPD and target printing
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <180236E8-EEE0-4CD8-A416-F28D6BE32FDA at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On May 15, 2011, at 9:06 PM, Graeme Gill wrote:
> 
>> Chris Murphy wrote:
>> 
>>> On both Mac OS and Windows it's always been best practices, until recently, to print
>>> targets from Photoshop with No Color Management, or directly from the profile
>>> generation app (e.g. ColorMuni or Eye One Match). It is NOT best practices to do it
>>> with a web browser, or a word processing application. I don't even test that workflow,
>>> I would never recommend it, I do not expect that it should work correctly. Those apps
>>> have nothing to do with custom profiling at all. I completely disagree with the idea
>>> that every app should have the ability to print profile targets. It's one tenth of one
>>> percent of the market.
>> 
>> You are quite right, that it's not practical. But note the problem with
>> the Mac is that it stopped being possible to reliably print test charts
>> in Photoshop and Apples own program, preview.
> 
> I know it seems related, but they it's a figment of our imagination. It's just a knee jerk reaction to the problems on Mac OS to say we want all users to have a master off switch for system level color transformations, and then put that master switch in the print dialog.
> 
> 
>> But again, this is my point - if the basic capability was inherent
>> in the printing system, then any and every application would
>> be reliably capable of printing test charts, better ensuring that the
>> test chart prints reflect the all the other printing conditions accurately.
> 
> Again you don't know this. It may be true an overwhelming majority of the time with today's apps, but that's only because so many are clueless when it comes to color management. If and when more of them are, you can't be assured that the developers of these apps anticipate some arcane desire by someone to use their app to print profile targets, and haven't already converted content the moment the image data (the target in this case) enters application domain.
> 
> It's misleading, and it's clutter for all but a teeny tiny number of users. If it's going to get hidden by default, which it should to prevent clutter for most users, now it's no longer discoverable for the users who'd need it. Putting it into the print dialog, you're hosed from multiple angles no matter what angle you look at it from. It appears to not belong in the print dialog.
> 
> And if you're going to have apps that trigger the revelation of this option in the print dialog, I don't see why that isn't already a special target printing application right then and there.
> 
> Chris Murphy
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 16 May 2011 15:09:36 +1000
> From: Graeme Gill <graeme at argyllcms.com>
> Subject: Re: [Openicc] Google Summer of Code 2011: The Common Printing
> 	Dialog and Color Management
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <4DD0B190.9020305 at argyllcms.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hal V. Engel wrote:
> 
>> B. There is significant disagreement over how to handle target printing that
>> appears to break down into two approaches.
>> 
>> Use a specialized app.  A slight variation on this would be to approach one of
> 
>> C. The other option is to put controls in the print UI for target printing.
>> This might be OK as a stop gap pending creating a specialized app.
> 
> You are missing the third alternative, which is to tag
> the test files.
> 
> I've done a rough draft of such an approach, and put it here:
> <http://www.argyllcms.com/SCPS_Tag.txt> if you are interested.
> 
> [We used this approach very successfully on the ColorBus RIP]
> 
> This approach does not exclude others. An application could have
> an option to add this tag, or a printer configuration or print
> dialog could have an option of adding or overriding the tag.
> 
> Graeme Gill.
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Sun, 15 May 2011 23:28:47 -0600
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] Google Summer of Code 2011: The Common	Printing
> 	Dialog and Color Management
> To: Open ICC Color Managment <openicc at lists.freedesktop.org>
> Message-ID: <29A733C0-C394-4703-BDD2-6B722EBF5EAE at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> On May 15, 2011, at 11:09 PM, Graeme Gill wrote:
> 
>> Hal V. Engel wrote:
>> 
>>> B. There is significant disagreement over how to handle target printing that
>>> appears to break down into two approaches.
>>> 
>>> Use a specialized app.  A slight variation on this would be to approach one of
>> 
>>> C. The other option is to put controls in the print UI for target printing.
>>> This might be OK as a stop gap pending creating a specialized app.
>> 
>> You are missing the third alternative, which is to tag
>> the test files.
> 
> This is interesting. But it could still be assumed to be sRGB (or something else) and converted to Display RGB (or something else) prior to being submitted to the print pipeline. I don't know of an example application that behaves this way, but that it probably doesn't exist doesn't mean it's not out there, or won't be. If I enable full color management in Firefox, I don't know for sure that it does NOT behave this way when printing. It very likely doesn't, but to know this, it'd have to be tested.
> 
> What I like about this is some way to bomb proof the target itself. Maybe if it does get converted, this affects a checksum somehow, and causes a different layer to be printed by Ghostscript rather than the target data - a layer that when printed informs the user that the target is unreliable.
> 
> I still prefer a dedicated app, honestly. It's not enough that the target is printed correctly for profiling - we need assurance that it has been. Printing a target is a bit of a leap of faith with each new application I print from, each new OS/manufacturer print driver I use.
> 
> 
> Chris Murphy
> 
> ------------------------------
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> End of openicc Digest, Vol 62, Issue 76
> ***************************************
>

More information about the openicc mailing list