[Openicc] colord Printing Plans

[Chris Murphy]

And in the case of RGB content being printed to a PostScript device, the content is color managed before it gets turned into PostScript. (In the case of CMYK, it's pass through in any event, except for display and then there's a transform.)

On Feb 24, 2011, at 2:40 PM, Chris Murphy wrote:

> I understand but if you want color managed PostScript output, you need something that understands how to properly write out PostScript files with CSAs and CRDs before it even gets to GhostScript. I think it's easier for application engineering to pick either PDF or PS and the way documents are to be color managed for PDF is way more logical and is known to work. And PostScript CSAs and CRDs have always been a nightmare. So even if GhostScript will look at a PostSCript's CSAs and CRDs and turn them into ICC profiles and color manage the document correctly, the PostScript would have to be properly built that way in the first place - and that is extraordinarily rare. Even Adobe applications manage to not get this correct and AFAIK the whole adventure was abandoned a long time ago. (Due in no small part to the licensees of PostScript doing their own thing, sometimes ignoring or substituting CSAs and CRDs, and making the whole idea of document portability completely break.)
> 
> So at least on Mac OS and Windows, PostScript is treated as pass through and is not color managed at all. It's basically treated as CMYK - punt, and get it to the destination. 
> 
> Chris Murphy
> 
> 
> On Feb 24, 2011, at 2:10 PM, Gerhard Fuernkranz wrote:
> 
>> Am 24.02.2011 18:27, schrieb Chris Murphy:
>>> You'll want to talk to the Ghostscript folks about this, but I will suggest that the sequence of filters should be to use PDF as long as possible, color manage the PDF, flatten it to output space, then convert to PostScript. If you have the PDF converted to PostScript early on and then color manage it, you're in potentially nasty territory because there is technically no ICC based color management in PostScript at all. In PDF you have ICC profiles, which are to be converted into CSA (color space arrays) and CRD (color rendering dictionaries) in PostScript. And that's just a clusterf*ck to be really charitable. I would not expect or encourage the Ghostscript folks look to solve the issues of PostScript color management. I would consider PostScript to be a done, ready to print language, and totally device dependent. Color management happens before PS generation.
>>> 
>> 
>> Ghostscript is both, a Postscript and PDF RIP, i.e. it accepts either
>> Postscript or PDF documents as input, and there is no need to convert
>> PDF to Postscript first, or vice versa (it's even possible to mix, e.g.
>> to send a Postscript prologue for setting up various printing
>> parameters, and then send a PDF document to gs). Both, the Postscript
>> and PDF rendering is basically color managed.
>> 
>> My understanding is that the color management in gs 9.x was
>> re-implemented from the scratch. The color transformations are now
>> completely ICC-based, CSAs in PS documents are now internally converted
>> to ICC profiles, and I think CRDs are no longer supported for describing
>> the output color space (but an ICC profile must be used instead).
>> 
>> [ See
>> http://svn.ghostscript.com/ghostscript/trunk/gs/doc/GS9_Color_Management.pdf
>> I hope most issues discussed in this paper still apply and are reflected
>> in the implementation. ]
>> 
>> Btw, my feeling is that Linux printing is still Postscript dominated,
>> i.e. most applications which have a print functionality still seem to
>> produce Postscript output, some can alternatively generate PDF, and only
>> few applications produce other print formats. So I think the ability to
>> print Postscript format is still as important as printing PDF format.
>> Using ghostscript as Postscript&PDF to Raster RIP, you get both features
>> simultaneously anyway (and both color managed). If on the other hand for
>> instance Poppler should be the preferred PDF to Raster RIP, then the
>> question arises how to handle Postscript documents. Either we need
>> additionally a ghostscript-based PS to Raster filter (but if we need
>> this filter anyway, why have a separate filter for rasterizing PDF
>> then?), or else use a PS to PDF pre-filter (again this distiller filter
>> would need to be ghostscript-based, but IMO it should not flatten
>> anything, but rather preserve all color spaces from the PS document in
>> the generated PDF output, so that the subsequent PDF to Raster filter
>> can do the color transformations and the flattening to the printer color
>> space, in the same way as it is done for PDF documents being printed).
>> 
>> Regards,
>> Gerhard
>> 
>> _______________________________________________
>> 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