Bug 691108 - Garbled raster output from cups device with -r600x600
Summary: Garbled raster output from cups device with -r600x600
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: CUPS driver (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Ray Johnston
: 691203 (view as bug list)
Depends on:
Reported: 2010-02-12 07:33 UTC by Tim Waugh
Modified: 2010-03-19 08:48 UTC (History)
3 users (show)

See Also:
Word Size: ---

tp0.ppd (37.40 KB, text/plain)
2010-02-12 07:34 UTC, Tim Waugh
in.ps.bz2 (390.56 KB, application/octet-stream)
2010-02-12 07:35 UTC, Tim Waugh
Screenshot of rasterview output (28.86 KB, image/png)
2010-02-12 07:36 UTC, Tim Waugh

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Waugh 2010-02-12 07:33:37 UTC
When the -r600x600 option is used, the output from the cups driver is incorrect.
 I am using revision 10631.

Original report:
Comment 1 Tim Waugh 2010-02-12 07:34:51 UTC
Created attachment 5949 [details]
Comment 2 Tim Waugh 2010-02-12 07:35:57 UTC
Created attachment 5950 [details]

bunzip2 in.ps.bz2
PPD=tp0.ppd gs -sDEVICE=cups -r600x600 -dSAFER \
  -dNOPAUSE -dBATCH -sOutputFile=out.rast
rasterview out.rast
Comment 3 Tim Waugh 2010-02-12 07:36:35 UTC
Created attachment 5951 [details]
Screenshot of rasterview output
Comment 4 Till Kamppeter 2010-02-12 10:04:35 UTC
The CUPS Raster driver seems to be a completely broken design. Mike Sweet
promised a lot of feature for it in his documentation of CUPS PPD extensions.
Many features, especially for duplex printing did not get implemented and also
the general design is broken. He did not maintain the driver any more since the
ESP/GPL Ghostscript merger.

I have found a lot of bugs in the CUPS Raster driver and tried to fix them.
Unfortunately I have hit severe design problems when working on bug 691029.

It looks like that the driver needs to get cleaned up somehow, perhaps even

Everyone uses CUPS Raster but no one wants to maintain the CUPS Raster output

Perhaps we must move driver developers away from CUPS Raster and use IJS or
OpenPrinting Vector instead.

Comment 5 Ray Johnston 2010-02-12 11:56:44 UTC
At the current time, I suspect that OpenPrinting Vector is also not very stable
-- just a general impression.

In general, support of 'vector' devices is much more difficult. We (Artifex)
actively maintain the pdfwrite and ps2write vector devices. Some others get
less complex vector devices also have active support pxl*** (Hin-Tak) and
pswrite (Artifex, but low priority).

So far, Artifex has not taken on the opv* devices.

The 'private' PPD extensions (which turn into cups device parameeters) may
be a problem, but I think it is not yet time to empty "bath that includes
the baby" since implementing all of the functionality in a new device will
also require a great effort.

With repect to IJS, We would need to survey the features supported via CUPS
custom PPD entries and see how much work they would need with IJS. This may
lead to a similar situation -- To implement features beyond standard Adobe
defined 'setpagedevice' support that CUPS may require more work than fixing
the cups device implementation.
Comment 6 Till Kamppeter 2010-02-12 15:51:18 UTC
Ray, as I am not such a Ghostscript expert, can you help me fix this bug and
also bug 691029, in a way that they get both fixed?
Comment 7 Hin-Tak Leung 2010-02-12 17:51:12 UTC
Tim: presumably you have tried reverting r10631 and it does fix the problem? I
am just a bit surprised the kind of change in r10631 causes the problem seen in
the screenshot.

Till: so far despite heavy promotion, 3rd-party (as in
not-from-the-people-who-promoted-it) uptake of opvp hasn't happened. cups raster
is at least a bit older and have some knowledgeable people who know about it
other than Mike Sweet.
Rewriting just means substituting one set of problems with a different set.
e.g. even going through the built-in vector interface in gs, there are
limitations e.g. bug 690948 and bug 689980 .
Comment 8 Till Kamppeter 2010-02-13 02:05:47 UTC
Hin-Tak, I do not ask Ray (or anyone else) for help on a rewrite but for help on
simply fixing these bugs.
Comment 9 Tim Waugh 2010-02-16 07:04:29 UTC
> Tim: presumably you have tried reverting r10631 and it does fix the problem?
> I am just a bit surprised the kind of change in r10631 causes the problem
> seen in the screenshot.

Reverting both r10631 and r10625 fixes the problem.
Comment 10 Hin-Tak Leung 2010-02-22 18:03:24 UTC
The resolution seems to have nothing to do with the problem - I can reproduce
with -r2 to get a 16x21 bitmap - one is mostly white while the other is mostly

PPD=tp0.ppd gs -sDEVICE=cups -r2 -dSAFER \
  -dNOPAUSE -dBATCH -sOutputFile=out.rast

(-r1 gives a setscreen error, probably too low). The outcome looks like it is
some sort of color-mapping/color-separation error? 
Comment 11 Till Kamppeter 2010-02-22 23:32:36 UTC
Can you try undoing on rev 10314 in Ghostscript 8.71? Perhaps this change caused
the problem and not the fixes for bug 691029.
Comment 12 Hin-Tak Leung 2010-02-23 11:15:47 UTC
> Can you try undoing on rev 10314 in Ghostscript 8.71? Perhaps this change
caused the problem and not the fixes for bug 691029.

I have an old r10457 binary lying around and that works correctly, so this
breakage happens after r10457 and before r10710. Also, as Tim's downstream
report at the redhat bugzilla, it is against 8.70 with 10625/10631 backported,
not svn HEAD or 8.71. 

This is the fedora 12 change log (and the breakage is between 8.70-2 and 8.70-5):
* Mon Jan 25 2010 Tim Waugh <twaugh@redhat.com> 8.70-5
- Fixed pdftoraster so that it waits for its sub-process to exit.
- Another gdevcups duplex fix from upstream revision 10631
  (bug #541604).

* Fri Jan 22 2010 Tim Waugh <twaugh@redhat.com> 8.70-4
- New ghostscript-cups sub-package for some additional filters:
  pdftoraster; pstopxl.  CUPS package still owns pstoraster for now.

* Thu Jan 21 2010 Tim Waugh <twaugh@redhat.com> 8.70-3
- Fixed gdevcups duplex output (bug #541604) by backporting upstream
  revision 10625.

Comment 13 Hin-Tak Leung 2010-03-09 04:47:35 UTC
Strangest bug - I found the smallest change which would fix the problem, but have no idea what's going on: the smallest change is simply getting rid of the width_old+height_old construct (half of r10631):

iff --git a/cups/gdevcups.c b/cups/gdevcups.c
index 6871bcd..21a76b6 100644
--- a/cups/gdevcups.c
+++ b/cups/gdevcups.c
@@ -2704,8 +2704,6 @@ cups_put_params(gx_device     *pdev,      /* I - Device info */
   gdev_prn_space_params        sp;             /* Space parameter data */
   int                  width,          /* New width of page */
                         height;                /* New height of page */
-  static int            width_old = 0,  /* Previous width */
-                        height_old = 0; /* Previous height */
   ppd_attr_t            *backside = NULL,
                         *backsiderequiresflippedmargins = NULL;
   float                 swap;
@@ -3245,17 +3243,12 @@ cups_put_params(gx_device     *pdev,    /* I - Device info */
     * Don't reallocate memory unless the device has been opened...
-    * Also reallocate only if the size has actually changed...
-    if (pdev->is_open && (width != width_old || height != height_old))
+    if (pdev->is_open)
-      width_old = width;
-      height_old = height;
-      * Device is open and size has changed, so reallocate...
+      * Device is open, so reallocate...
       dprintf4("DEBUG2: Reallocating memory, [%.0f %.0f] = %dx%d pixels...\n",


In fact just removing the assignment line (width_old = width;height_old = height;) would fix the problem. It looks like some sort of compiler or alignment bug.

I have tried stuffing the two static variables into the device_cups struct and put the initialtion in cups_open(), but that has no effect. It probably involves looking at the disassembler with and without those two lines to see what's going on. Anybody else wants to give this a go?
Comment 14 Till Kamppeter 2010-03-09 16:38:17 UTC
Fixed in SVN rev 10890.
Comment 15 Till Kamppeter 2010-03-09 17:05:02 UTC
The problem was that the bitmap memory did not get reallocated when the color depth has changed. This also changes the bitmap size. The fix add two static variables to track color depth changes.
Comment 16 Hin-Tak Leung 2010-03-19 08:48:12 UTC
*** Bug 691203 has been marked as a duplicate of this bug. ***