[Openicc] colord Printing Plans

[Chris Murphy]

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/17cd1712/attachment.html>