When the -r600x600 option is used, the output from the cups driver is incorrect.
I am using revision 10631.
Created attachment 5949 [details]
Created attachment 5950 [details]
PPD=tp0.ppd gs -sDEVICE=cups -r600x600 -dSAFER \
-dNOPAUSE -dBATCH -sOutputFile=out.rast
Created attachment 5951 [details]
Screenshot of rasterview output
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.
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.
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?
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
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 .
Hin-Tak, I do not ask Ray (or anyone else) for help on a rewrite but for help on
simply fixing these bugs.
> 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.
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?
Can you try undoing on rev 10314 in Ghostscript 8.71? Perhaps this change caused
the problem and not the fixes for bug 691029.
> 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 <email@example.com> 8.70-5
- Fixed pdftoraster so that it waits for its sub-process to exit.
- Another gdevcups duplex fix from upstream revision 10631
* Fri Jan 22 2010 Tim Waugh <firstname.lastname@example.org> 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 <email@example.com> 8.70-3
- Fixed gdevcups duplex output (bug #541604) by backporting upstream
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
@@ -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;
@@ -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?
Fixed in SVN rev 10890.
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.
*** Bug 691203 has been marked as a duplicate of this bug. ***