Created attachment 8744 [details] firefox-google-com-lp1022516.pdf Original bug report from an HPLIP developer at HP: https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1022516 Rendering attached file with color space 1 gives correct output: gs -sDEVICE=cups -dcupsColorSpace=1 -sOutputFile=out1.raster firefox-google-com-lp1022516.pdf You can see it via rasterview out1.raster with rasterview from http://www.easysw.com/~mike/rasterview/index.html Rendering the same file with color space 17 leads to the gray buttons coming out in yellow: gs -sDEVICE=cups -dcupsColorSpace=17 -sOutputFile=out17.raster firefox-google-com-lp1022516.pdf Probably there is a problem with Ghostscript's internal color management. This breaks the output of most modern HP inkjet printers.
Ghostscript version is 9.05 in Ubuntu Precise (12.04) 64-bit.
Ghostscript 9.04 shows the same problem.
Created attachment 8745 [details] out17.ras I'm having trouble reproducing this. With gs9.05 the output file looks correct when viewed in Rasterview (see attached). When I tried gs9.04 I don't get an output file at all, but instead an error: marcos@i7:[11]% gs904 -sDEVICE=cups -dcupsColorSpace=17 -sOutputFile=out17.ras ./firefox-google-com-lp1022516.pdf GPL Ghostscript 9.04 (2011-08-05) Copyright (C) 2011 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. INFO: Start rendering... INFO: Processing page 1... Processing pages 1 through 1. Page 1 GPL Ghostscript 9.04: ./base/gxclrast.c(1972): Bad op ff band y0 = 0 file pos 7719 buf pos 1023/4096 0: fb fd ff aa c5 fb 45 83 fd 39 10: 78 fd 24 63 fb 0f 4e f7 01 40 20: e3 13 3f c8 81 8d af e0 e1 de 30: ff ff ff ff ff ff ff ff ff ff ...
With 9.05 or with the current master, you need to build with COMPILE_INITS=0 to see the problem.....
Chris is correct, COMPILE_INITS=0 is necessary to see this. It does not appear to be a regression, Ghostscript-9.02 does not generate the correct output either, though it's wrong in a different way.
Created attachment 8746 [details] Simplified test file
Seems to be some "clash" between clist and disk based ICC profile resources. For me (default build, with COMPILE_INITS=1): WORKS: ./debugbin/gs -r100 -sDEVICE=cups -dcupsColorSpace=17 -dcupsBitsPerColor=8 -o out17-2.raster firefox-google-com-lp1022516-uc.pdf WORKS: ./debugbin/gs -dMaxBitmap=80000000 -r100 -sDEVICE=cups -dcupsColorSpace=17 -dcupsBitsPerColor=8 -o out17-2.raster firefox-google-com-lp1022516-uc.pdf WORKS: ./debugbin/gs -dMaxBitmap=80000000 -IResource/Init -r100 -sDEVICE=cups -dcupsColorSpace=17 -dcupsBitsPerColor=8 -o out17-2.raster firefox-google-com-lp1022516-uc.pdf WORKS NOT: ./debugbin/gs -IResource/Init -r100 -sDEVICE=cups -dcupsColorSpace=17 -dcupsBitsPerColor=8 -o out17-2.raster firefox-google-com-lp1022516-uc.pdf
Not sure why I assigned this to Robin; seems like it's a Michael issue.
Created attachment 8747 [details] (tentatively) proposed patch This is a fairly complex situation: clist + transparency + "interesting" device profile + Type 2 pattern. I am guessing a little, but it looks to me like the profile for the pattern wasn't being written to the clist from pdf14_clist_fill_path(). The comments indicate this is on purpose, but as it seems to cause a problem, here's a proposed patch so we'll right the profile out more often. Michael, Can you cast an eye over the patch, and let me know what you think?
For me the patch works with Ubuntu's Ghostscript.
Patch committed: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=4f6b9854