[Pkg-cups-devel] Bug#625925: Uses incorrect path to default colour profile

[Ben Hutchings]

On Sat, 2011-05-07 at 10:54 +0100, Roger Leigh wrote:
> On Sat, May 07, 2011 at 05:17:58AM +0100, Ben Hutchings wrote:
> > Printing to my HP LaserJet 4Plus currently fails.  The error message
> > for the job is:
> > 
> > File '/System/Library/ColorSync/Profiles/sRGB Profile.icc' not found
> > 
> > This path is presumably correct for OS X but obviously not for Linux!
> > It is present in the /usr/lib/cups/driver/gutenprint.5.2 binary.
> 
> This path is unconditionally put into generated PPD files by genppd.c:

Well, that's rather silly!

>   /* Macintosh color management */
>   gzputs(fp, "*cupsICCProfile Gray../Grayscale: \"/System/Library/ColorSync/Profiles/sRGB Profile.icc\"\n");
>   gzputs(fp, "*cupsICCProfile RGB../Color:      \"/System/Library/ColorSync/Profiles/sRGB Profile.icc\"\n");
>   gzputs(fp, "*cupsICCProfile CMYK../Color:     \"/System/Library/ColorSync/Profiles/Generic CMYK Profile.icc\"\n");
>   gzputs(fp, "*APSupportsCustomColorMatching: true\n");
>   gzputs(fp, "*APDefaultCustomColorMatchingProfile: sRGB\n");
>   gzputs(fp, "*APCustomColorMatchingProfile: sRGB\n");
> 
> gutenprint is currently orphaned.  I no longer have a printer to test
> it with, so I can no longer maintain it adequately.

This seems like a big problem, since cups recommends gutenprint over
foomatic (and I found the latter does work for me).

(Also, the situation of multiple drivers for the same hardware is just
as confusing with printers as it is with graphics or wireless cards...)

> In the absence of
> a new maintainer, I'm continuing to made uploads of new upstream
> releases, but without the level of QA I would consider necessary for
> a properly maintained package (I used to test all the major components
> printed correctly under a variety of conditions for all new upstream
> releases and for all but the most trivial packaging changes).  But
> other than that, which I'm doing purely as a service to existing users,
> I am not capable to properly maintaining the package.  I've been looking
> for a new maintainer for at least two years now.
> 
> You can find the latest upstream release here:
> http://people.debian.org/~rleigh/gutenprint_5.2.7-1_amd64.changes
> http://people.debian.org/~rleigh/gutenprint_5.2.7-1.dsc
> I would be interested to know if this fixes the issue, though
> it does still contain the offending lines there might be other
> related changes which cause it not to error out.
> 
> Note that this might equally be a bug in the cups server itself for
> not ignoring the directive in the absence of a valid ICC profile or
> using a fallback.

Given that it seems to be a longstanding bug in gutenprint that
previously had no effect, there may be a case for working around it in
cups.  However, failing when a configuration file refers to a
nonexistent file doesn't seem like a bug.

> This would need taking to cups and gutenprint
> upstream.  I don't have the time to do that myself, but both teams
> are responsive to issues such as this.
> 
> The code in question was tweaked in 5.2.7 (not yet uploaded) but
> was otherwise unchanged since 5.2.1, which has been around in
> unstable since early 2009, so if this is recent breakage I would
> suspect it's a changed behaviour in CUPS itself.

I upgraded cups more recently (2011-03-19) than gutenprint (2010-08-17).
I might not have tried printing since March.

cups seems to have recently (version 1.4.5-3) got a new PDF rasteriser
which certainly appears to use ICC profile information from the PPD.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-cups-devel/attachments/20110510/4ae11a95/attachment.pgp>