[Openicc] Printing Plans GhostScript

Tue Mar 1 14:19:00 PST 2011

I think that this is a very fundamental ideological issue that needs to be more fully considered before coding. Just my opinion. It may be we dead end, and beyond which spec changes or clarifications are needed.

Based on the majority handling of PDFs for display and print in the real world, the defacto policy is that /DeviceRGB does not really exist. It's always assumed to be something else, 99% of the time sRGB. You don't really have a pass through for RGB. Not unless you go PDF/X which you cannot be assured will be displayed or printed correctly outside of an explicitly conforming PDF/X system. And there isn't an equivalent for PDF/X for PostScript.

Chris Murphy

On Mar 1, 2011, at 3:11 PM, edmund ronald wrote:

> There is another way to do things, and this is to bring up a skeleton
> V0.5, and let apps sort themselves out; according to what the
> application developers do, and what CUPS does, we can then pick a
> strategy in V0.8 that is compatible with having a decent working set
> of apps for the user, and minimal design effort and maintenance for
> the Color Management architects and volunteers. It's presumptuous to
> think we can get it right at the first try, anyway.
> 
> Edmund
> 
> On Tue, Mar 1, 2011 at 10:49 PM, Chris Murphy <lists at colorremedies.com> wrote:
>> The converse is that you start taking responsibility for other people's mess. Both paths have consequences for users.
>> 
>> If /DeviceRGB is going to sometimes be assumed to mean sRGB when the output is RGB or CMYK, then we immediately need some way to communicate "pass through" that is not in the PDF or CUPS specs. So that is why I suggested this need should be brought up with those who code the CUPS filters and Ghostscript because those items are the ones that need to understand the new token.
>> 
>> If you're going to second guess /DeviceRGB, then it's inherently a more complicated implementation that needs to be created, because now it's opt-out. Not opt-in.
>> 
>> In opt-out (meaning, color management happens unless the application opts out):
>> 
>> If the application is *dumb* then that means it also has no ability to generate a pass through token. The PDF or PS spool from such an application arrives at: pdftopdf, pdftops, pstops, pstopdf filters, where /DeviceRGB, /DeviceGray, /DeviceCMYK stamped out of it in favor of specific spaces. [While I include PostScript here for completeness, I'm personally in favor of ignoring stupid PostScript devices whose PPDs make unclear how the PostScript should be formed.]  I suggest doing this with CUPS prefilters because I don't think it's necessarily a good idea to compel Ghostscript to make these assumptions. If they are in prefilters, those assumptions are possibly easier to change, but again this is a question for those who are responsible for these pieces. If it doesn't happen in CUPS filters, then it must happen in GhostScript which means Ghostscript needs to understand the pass through token.
>> 
>> If the application is smart, then it should properly tag all objects. Anything that is /DevicexxxX would need an additional token to inform the downstream piece that in fact /DevicexxxX designation should stay intact and not substituted with default source spaces. This token could be singular, applies to the whole document meaning "any instance of /DevicexxxX should remain as such". Or the token is per object. I think once is sufficient, I don't see a use case for even allowing mixed mode untagged content.
>> 
>> In opt-in (meaning, color management only happens if the application requests it):
>> 
>> Then you only have smart apps. Dumb apps always produce "pass through" spool files.
>> 
>> 
>> Mac OS today is opt-out. On Mac OS, you need a pretty smart application to opt-out. While we can make this more stable than Mac OS is, it's still something that has to be designed: that pass through "token" in the spool file.
>> 
>> Windows today is opt-in. Windows gets away with it because they've told all of their ISV's that untagged incoming RGB is to be treated as sRGB. And this has been replicated on Mac OS by default as well. So the default behavior on the two platforms is in parity. The Windows opt-in paradigm is proven to be more reliable for professionals who build custom profiles, because they only need applications that are dumb to ensure a pass through, no special token is needed.
>> 
>> For the vast majority of consumers, I think it's a stretch to propose that the Microsoft sRGB paradigm is inadequate.
>> 
>> Chris
>> 
>> On Mar 1, 2011, at 2:07 PM, edmund ronald wrote:
>> 
>>> I disagree. I vote we subject all apps creating untagged (but not really device) data to Darwinian selection, and let their maintainers be subjected to a rain of complaints. In the end a few decent apps with smart responsive developers will be left standing - the Adobe monopoly shows that having one app in each niche is amply sufficient.
>>> 
>>> Edmund
>>> 
>>> On Tue, Mar 1, 2011 at 8:11 PM, Michael Vrhel <michael.vrhel at artifex.com> wrote:
>>> Hal,
>>> 
>>> I agree, the reality of the world is that there are a lot of bad PDF files out there and Ghostscript has to robustly handle the good the bad and the ugly. <wlEmoticon-smile[1].png>
>>> 
>>> Michael
>>> 
>>> From: Hal V. Engel
>>> Sent: Tuesday, March 01, 2011 9:47 AM
>>> To: openicc at lists.freedesktop.org
>>> Subject: Re: [Openicc] Printing Plans GhostScript
>>> 
>>> On Tuesday, March 01, 2011 02:15:32 AM Kai-Uwe Behrmann wrote:
>>>> Hello Michael,
>>>> 
>>>> Am 28.02.11, 22:09 -0800 schrieb Michael Vrhel:
>>>>> Hi Jan-Peter,
>>>>> 
>>>>> So yes, ghostscript does apply ICC base color transformations on
>>>>> Postscript files and this is true even for DeviceRGB and DeviceCMYK.
>>>>> I need to add in the interface for rendering intent and black point
>>>>> compensation. That will be coming shortly. In fact, I am also adding in
>>>>> the ability to specify different output profiles for graphics, images,
>>>>> and text as ghostscript keeps track of these objects during rendering,
>>>>> even through transparency blending. The specification for these
>>>>> options is primarily through the CLI but can be made through special
>>>>> configurations.
>>>> 
>>>> Would it possible to pass those profiles along the PDF document itself?
>>>> 
>>>>> As far as "turning off" transformations for DeviceRGB or DeviceCMYK, that
>>>>> will occur in cases where the source and destination profiles are the
>>>>> same.
>>>> 
>>>> We came several time to the conclusion that this scheme is not realy
>>>> robust. So we would be happy you could point us to an other mechanism as
>>>> well.
>>> 
>>> The reason that this is not robust is that the user app currently has no way to specify the source profiles to be used when the GS pdftoraster filter is called and no way to know what profile will be used by the print system so that it can specify a matching output color space.
>>> 
>>> The reason that this whole DeviceXXX thing is an issue is because we have so many dumb apps and libraries that use DeviceRGB and DeviceGray for objects that really should be taged with either sRGB or an equivalent CalRGB tag for RGB images and generic gray ICC profile or a CalGray tag for monochrome images. Dealing with these malformed PDFs causes all sorts of headaches.
>>> 
>>>> 
>>>>> The obvious example occurs if I have a document that has an RGB image and
>>>>> a CMYK image and I am printing to a CMYK device. In this case, the RGB
>>>>> image will have to be transformed in some manner. That transformation
>>>>> is under your control by specifying the desired default RGB source
>>>>> profile to use. For the CMYK image, if you did not want the data
>>>>> touched, you should make sure that your default CMYK source profile is
>>>>> the same as your destination profile. The CMYK data will then pass
>>>>> through unmolested.
>>>> 
>>>> Will adding a OutputIntent to a PDF/X (A/E) be honoured for DeviceXXX
>>>> objects by Ghostscript? Leonard pointed this requirement out [1].
>>>> It could then be used to pass through unmolested Cmyk or DeviceN to a
>>>> according configured printer.
>>> 
>>> Why not unmolested RGB and Gray as well? Any app that is smart enough to create PDF spool files with the OutputIntent set should be assumed to be smart enough to know what it is doing and the PDF spec should be fully honered. The issue with assuming a color space for DeviceXXX objects should, if possible, be limited to apps that don't know better. At this point there do not appear to be any CM dumb apps that can create PDF spool files with the OutputIntent set. This is definitiely true for Qt apps that are using the standard Qt PDF printing chain.
>>> 
>>> The issue here is retargeting. If the print system receives a spool file with an OutputIntent that is different from what the system would use normally that device and settings what should it do. One of the reasons for using DeviceXXX for objects along with an OutputIntent is to allow for retargeting. Under those conditions it is assumed that the DeviceXXX objects are in the OutputIntent color space. This is to allow for the output to be retargeted to a different device if needed using an OutputIntent --> new device color space transform for all DeviceXXX objects. This means that setting the OutputIntent is also not a robust solution unless there is some way for the app creating the spool file to query the system for the devices profile so that it can use that for the OutputIntent. This could be done using Oyranos or colord but this means that the app creating the PDF needs to be not only aware of color but also needs to knwo what printer is being targeted and how to get it
>>  's default profile for the print mode being used.
>>> 
>>> The basic issue always come back to the fact that most of the apps on peoples machines are producing malformed PDF files that by default use DeviceXXX and do not set the OutputIntent. If we were following the PDF spec. and DeviceXXX data would be passed through to the printer unchanged with unpredictable results for many apps. In addition, if the DeviceXXX objects did not match the color mode of the printer (IE. DeviceRGB but printer is a CMYK only or is set to CMYK in CUPS) or if the PDF has more than one DeviceXXX type (like DeviceRGB and DeviceGray which is possible with the current Qt PDF code) then the print job would fail. The problems is users expect stuff to "just work" and following the specification will fail for some number of print jobs with most software currently being used. This means that we need to do things like get the Qt PDF code fixed to be inline with the PDF specification and work at getting good PDF code into other libraries that support printing lik
>>  e GTK+. This is going to take some effort.
>>> 
>>>> 
>>>> kind regards
>>>> Kai-Uwe Behrmann
>>> 
>>> 
>>> _______________________________________________
>>> openicc mailing list
>>> openicc at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>> 
>>> 
>>> _______________________________________________
>>> openicc mailing list
>>> openicc at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>> 
>>> _______________________________________________
>>> openicc mailing list
>>> openicc at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/openicc
>> 
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>> 