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

[Chris Murphy]

On Feb 11, 2011, at 7:51 AM, Gerhard Fuernkranz wrote:

> 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.

I tend to agree, but I am not familiar with the effort involved in the two proposed strategies.

If the flat implementation is "proof of concept" i.e. not encouraged for production use, OK, that sounds like a beta. But for subjecting users to this in an actual distribution, I would not recommend it. You can't expect applications to treat a myriad pile of PDF's of different flavors and specs to unwind those PDFs and turn them into normalized (single color space) flat (no live transparency) PDFs. You've got to be able to have pass throughs to the print system and let a PDF printing system do its job. That's kinda the point is that applications don't have to be overly smart about it.

And also, we need to consider the display in all of this as well, the application that submits PDF/A to GS and then back to display should be using all of this same effort. We are calling it (I'm guilty also) of calling this a printing pipeline, but it is a PDF rendering pipeline. It will be used for print and display and it should produce the same good results. A display is an output device.

Chris