[Openicc] Print-colormanagement,
application->CUPS->gutenprint
Leonard Rosenthol
leonardr at pdfsages.com
Mon Apr 18 20:52:36 EST 2005
At 05:46 AM 4/18/2005, Jan-Peter Homann wrote:
>Looking at the color-structure of document during printing, we have mainly
>three types of documents:
>1. flat-color RGB-documents
>2. flat-color CMYK-ducuments
>3. mixed-color documents
>(every image, vector-object or text-object can have his own profile and
>his own rendering intent.
I would actually change this a bit...
1) flat color raster documents (either RGB or CMYK)
2) flat color mixed object type (vector, text, raster) documents (either
RGB or CMYK)
3) mixed color documents
The reason is that handling of raster documents is different than
non-raster, because of the introduction of the RIP (eg. pstoraster) into
the process...
>Printing documents of type 1 or 2, we need only one colortransformation
>from the document-colorspace to the printer-colorspace. As I wrote in
>mails before, I strongly recommend, to do this colortransformation in
>
>D. gutenprint
For my type 1, I would agree with this.
>For "3.3 mixed-color documents", we have to flatten the color of
>individual objcets to the document-colorspace before doing the
>colortransformtion to the printer-space.
>The color-falttening can be done in:
>A. Colormanagement in the application
>B. colormanagement in the RIP based on CSA/CRD instead ICC
Agreed.
>If we try do B. "colormanagement in the RIP" we have to take in
>consideration, that PostScript don´t supports ICC-profiles and
>rendering-intents. Instead of this, the profiles of the individual objects
>and their rendering-intents have to be converted to CSA.
>Every combination of profile and rendering intents results to an
>individaul CSA.
>The document-colorspace must be converted to an CRD. If individual objects
>are specified with differnt rendering intents, individual CRDs have to be
>calculated from the document-colorspace in combination with the rendering
>intents.
>At the end of this processm every object in the mixed-color document is
>specified with his individual pairs of CSA and CRD which have to processed
>in the RIP.
Yes, a good description is at
<http://www.boscarol.com/pages/cms_eng/075-pcm.html>.
This is one reason why Adobe is moving away from Postscript to PDF
- and having all their applications generate it directly (avoiding
Distiller and Postscript) and their RIP support it natively.
If we consider that Gnome already offers direct PDF generation out
of GnomePrint, that KDE is working on same (though further behind last time
I looked), and some applications (eg. Scribus) can do the same - we have a
better path for color managed workflows. And since Ghostscript/pstoraster
also does pdftoraster (as does Mac OS X, obviously) - the software involved
doesn't change.
>In daily practice, this process is extreme unstable. Thats, why ALL
>colormanagement-experts recommend NOT to use
>"B. colormanagement in the RIP"
I don't know where you get "all" from, since on a variety of other
mailing lists this is certainly not the recommendation given. Also, as a
member of the PDF/X, PDF/A and Ghent Working Group standards committees -
I can tell you that these aren't recommendations we make either.
However, I will grant you that we are discussing the production of
a PDF for use in the printing/publishing workflow - and NOT going "direct
to print"...
>The best solution for mixed color documents is
>"A. Colormanagement in the application"
This is fine, IF you have enough information at this point in the
workflow concerning the final printer profile (eg. the user is going direct
to their attached printer) - OR you someone who believes that CMYK is CMYK
(and doesn't need to be color managed or profiled).
Leonard
---------------------------------------------------------------------------
Leonard Rosenthol <mailto:leonardr at pdfsages.com>
Chief Technical Officer <http://www.pdfsages.com>
PDF Sages, Inc. 215-938-7080 (voice)
215-938-0880 (fax)
More information about the openicc
mailing list