[Openicc] Print-Color-Pipeline: Learning from TurboPrint and Photoprint

Jan-Peter Homann homann at colormanagement.de
Fri Feb 11 14:00:51 PST 2011


Hello all, hello Gerhard
Applying some kind of color management or color manipulation after 
PDFtoRaster is for some tasks quite common.
If you e.g. want to simulate the result of an expensive print process 
(e.g. offset printing) on a cheap device (e.g. inkjet) - which is known 
as proofing in the graphic arts - you often have to simulate the paper 
color of the final printing process. This is not possible inside PDF, 
because only PDF objects can colormanaged inside PDF and not areas 
without any objects.

Also color effects for the whole print like e.g. sepia are much easier 
applied after PDFtoRaster.

I´m currently not a CUPS specialist, but I could imagine, that a Filter 
RasterToRaster applied after PDFtoRaster is nothing completely strange 
in CUPS workflows...

Further more, the core of the worfklows I´m currently working on, is 
clever handling of profiles and settings in
- documents
- Common Printing Dialogue
- Printer Driver

my goal is:
- make handling of profiles and settings transparent to the user and 
easy to handle
- allow the usage of the profile and settings both in PDFToRaster or 
RasterToRaster

best regards
Jan-Peter





Am 11.02.11 15:51, schrieb Gerhard Fuernkranz:
> Am 11.02.2011 14:04, schrieb Robert Krawitz:
>> Jan-Peter said -- correctly, in my view -- that concentrating on flat color documents *as a first step* is the way to go.  It's not the end goal, it's simply a first step that would achieve something useful as a proof of concept.
>>
> Robert, what I mean is that enhancing the ghostscript-based PS/PDF
> rendering path with simple (as a first step) color management
> functionality is likely not more expensive either, but results in a more
> general solution (usable implicitly for all document formats, after
> converting them to PS/PDF by filters, which already exist anyway), while
> still fitting well with the PS and PDF color management semantics as
> defined by the PLRM and PDF specs (any attempt to do the color
> management for PS/PDF documents outside the RIP does IMO not fit with
> the color management semantics defined by the PLRM and PDF specs, so I'm
> not sure whether it should be considered an option at all). So I think
> you get more for the money when starting with a PS/PDF-based approach -
> but that's just my humble opinion, of course.
>
> Regards,
> Gerhard
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>


-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de




More information about the openicc mailing list