[Openicc] Fwd: colord Printing Plans

[Michael Vrhel]

Forgot to cc in OpenICC on this...

---------- Forwarded message ----------
From: Michael Vrhel <michael.vrhel at artifex.com>
Date: Fri, Feb 25, 2011 at 9:02 AM
Subject: Re: [Openicc] colord Printing Plans
To: Chris Murphy <lists at colorremedies.com>



Chris,

Yes this is only applicable for the cross-mode case.  I agree that having
different defaults in different regions is going to be needed (e.g. An
agreed upon Fogra CMYK type in Europe).   SWOP TR003 2007 CMYK is the
recommended default for XPS undefined CMYK values and will be the "default"
that comes with ghostscript, but which can be easily changed.   What default
is used by Adobe Acrobat?  Does is vary by region?

Michael


On Fri, Feb 25, 2011 at 1:31 AM, Chris Murphy <lists at colorremedies.com>wrote:

> I'm assuming that these defaults are only applicable for cross color mode
> transforms. i.e. /DeviceRGB assumed as sRGB converted to SWOP CMYK if the
> output space for the printer is CMYK. Or if incoming data is CMYK but the
> printer is RGB, you'd assume a SWOP to sRGB transform.
>
> I think we're going to have to make sure that CMYK is tagged with something
> differently in different regions. As I previously mentioned, ideally we'd
> use a heuristic to conditionally tag objects based on their region of
> ORIGIN, not the region those CMYK objects are being printed in. But that
> heuristic may be too complicated to actually implement.
>
> I'm not opposed to SWOP as a default as long as it's SWOP2006_Coated3, TR
> 003 based. I don't think TR 005 is that appropriate for most printing. I'd
> rather see it be based on TR 006 which is GRACoL 2006 Coated 1 which is also
> ISO 12647 compatible and I think similar to one of the FOGRA
> characterization sets, maybe 27 or 28 (eek).
>
> If the SWOP being used is TR 001 based, it should be deprecated.
>
> Chris
>
>
>
> On Feb 25, 2011, at 1:00 AM, Michael Vrhel wrote:
>
> Wow.  I missed out on a nice conversation.
>
> Just a few comments so that everyone understands how ghostscript deals with
> color management for PS and PDF.   Every color is defined in terms of an ICC
> profile.   If the source color is DeviceRGB, DeviceGray or DeviceCMYK it
> will be assigned an ICC profile, which can be specified on the command
> line.  If one is not specified then a default one will be used (sRGB,
> SWOPCMYK, sgray).
>
> If we have a PS color space that is CIEA, CIEABC, CIEDEF(G) an equivalent
> ICC profile is created so that the same CMM can handle all color management
> and need not worry about PS color management.  The same occurs for CalGray
> and CalRGB PDF color spaces.  Shortly, I will be adding the ability to
> specify device profiles based upon object types.  In this case, different
> device profiles can be used for images, text, and graphic objects.  This
> makes it easier to maintain nice black text and nice images.
>
> Michael
>
> On Thu, Feb 24, 2011 at 5:11 PM, Graeme Gill <graeme at argyllcms.com> wrote:
>
>> Chris Murphy wrote:
>>
>>> I admit this is unique on Linux. On Mac OS and Windows, the legacy RGB
>>> path is not
>>> PostScript but QuickDraw and GDI, and for Mac OS today now that QuickDraw
>>> is deprecated
>>> it is Quartz which can do either RGB or CMYK.
>>>
>>
>> This may be so for color unsophisticated applications, but anything
>> sophisticated
>> has used "PostScript Bypass" to inject its own PS into the print job on
>> MSWin and Mac.
>>
>>
>>  it in the first place. If the application is seriously producing untagged
>>> data across
>>> the board including saving out its own document format, then neither that
>>> developer nor
>>> its users really care one bit about color. I am not opposed to the idea
>>> of building
>>>
>>
>> This isn't strictly true. They expect DeviceXXX to be a "reasonable" color
>> space,
>> not the actual device colorspace. For RGB that means something that
>> compares
>> to what they see on their display. For CMYK, that means something that
>> compares
>> to a standard printing press or the Pantone CMYK swatches. Any system that
>> is to be
>> regarded as having satisfactory color, meets these expectations. (Take
>> that as a
>> lesson from spending 10 years developing PS RIPS).
>>
>> Graeme Gill.
>>
>> _______________________________________________
>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110225/c32f3e7f/attachment-0001.htm>