Re: [cups-devel] ICC profile support for PostScript printers?

On Sun, 07 Aug 2016 13:29:07 +0200
Helge Blischke <[email protected]> wrote:

> > Am 06.08.2016 um 21:08 schrieb Alexey Galakhov
> > <[email protected]>:
> > 
> > Hi,
> > 
> > I'm trying to get color profiles to work - again. This time my
> > printer has native PostScript support. Digging in the source code
> > of CUPS I did not find anything that could apply an *.icc file from
> > cupsICCProfile to a PostScript. The ps2ps utility filter does not
> > do that. Am I missing something?
> > 
> > Regards,
> > Alexey  
> 
> As far as I know, printers which speak PostScript natively have (or
> should have) built-in color profiles with respect to the selected
> media type / media color. If the printer has a hard disk, custom ICC
> profiles should be loadable by a printer specific utility (that may
> be a printer specific PostScript program which may use proprietary
> operators not belonging to the standard PostScript language).

This particular model does not have such a possibility. I made my own
profile using ColorMunki and argyll and now I'm trying to use it.

> The only ICC support implemented with CUPS is the handling of special
> PPD keywords described in the section „CUPS PPD Extensions“ of the
> CUPS documentation, and – to my knowledge – evaluation of these
> keywords are only implemented for the xxxtoraster filters
> (cgpdftoraster, pdftoraster, pstoraster, gstoraster, …) which
> transform PostScript of PDF to the cups-raster format.

That's exactly what I mean. I found this evaluation in xxxtoraster
only. Thank you, you just confirmed what I suspected. 

> If you need more, you’ll have to rewrite (or write a wrapper for) the
> stops filter which generates e.g. PostScript CRDs from selected ICC
> profiles (using utilities like spice from the lcms2 package), but be
> aware that a lot of PostScript rips implement proprietary routines
> for color management which are not (or only roughly) compatible with
> CRDs, so I really cannot recommend this approach.

But what if we just let ghostscript or poppler convert the input to
DeviceN using the given ICC profile? Or just embed CRD into PS and then
filter it through gs (at least for some printers)?

We should either do that or convert the ICC to CRD since the color
profile should be used and not just silently ignored. Any thoughts?

And I'd like to move the colord stuff to cupsd completely, so that the
color profile will always be part of the printing job. Side stepping
the usual cups job path seems to be a bad idea.

Regards,
Alexey
_______________________________________________
cups-devel mailing list
[email protected]
https://www.cups.org/mailman/listinfo/cups-devel