[Openicc] colord Printing Plans

Gerhard Fuernkranz nospam456 at gmx.de
Thu Feb 24 13:10:54 PST 2011


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



More information about the openicc mailing list