[Openicc] colord Printing Plans

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

Chris Murphy

On Feb 24, 2011, at 8:51 AM, Till Kamppeter wrote:

> Looks nice, but there is one question:
> 
> What happens if the application from which the job is sent and the printer are not on the same machine or not even on the same local network. CUPS has all capabilities for networked printing, even through the internet. Does this mechanism also work in such a situation? Is it really needed to have an extra daemon? Is it not possible to do everything with CUPS (perhaps with patches to CUPS)?
> 
> Do have made the code of pdftoraster and pstoraster available somewhere? pstoraster is perhaps even not needed as due to the nature of Ghostscript accepting both PDF and PostScript as input probably pdftoraster also accepts PostScript and does the right thing with it.
> 
> About Foomatic, you do not need to be an expert in Perl. Programming languages are not that different. In case of questions simply ask me. And the part which is probably the most important for you, foomatic-rip, is already converted to C from version 4.0.0 on.
> 
>   Till
> 
> On 02/24/2011 02:46 PM, Richard Hughes wrote:
>> I was talking to the ghostscript guys quite a lot yesterday about
>> changes required for platform icc integration. I'm sharing what I'm
>> doing here in case anyone else wants to give me a hand or has better
>> ideas to share.
>> 
>> The basic idea is to teach pstoraster, pdftoraster and foomatic a way
>> to get the best icc output profile for the printed document using
>> colord.
>> The input profiles and rendering intents ideally come from the PDF or
>> PS file, and colord doesn't get involved in this at all.
>> 
>> In a hope to understand the architecture I've drawn this diagram:
>> http://colord.hughsie.com/img/cups-plan.png -- corrections welcome.
>> 
>> What I've already done:
>> 
>> * Rewritten pstoraster from shell to C to allow me to use libdbus with
>> a mainloop
>> * Added code to pstoraster.c and pdftoraster.c to get the desired icc
>> profile from colord
>> * Set the device icc profile for gs>= 9.01
>> 
>> What needs to be done:
>> 
>> * Add code to foomatic to do the same. I'm no expert in perl, but DBus
>> has a pretty good DBus binding available.
>> 
>> Does this sound sane? Ideas and comments welcome. Thanks.
>> 
>> Richard
>> _______________________________________________
>> 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