| Summary: | Garbled raster output from cups device with -r600x600 | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Tim Waugh <twaugh> |
| Component: | CUPS driver | Assignee: | Ray Johnston <ray.johnston> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | au+ghostscript, htl10, till.kamppeter |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
tp0.ppd
in.ps.bz2 Screenshot of rasterview output |
||
|
Description
Tim Waugh
2010-02-12 07:33:37 UTC
Created attachment 5949 [details]
tp0.ppd
Created attachment 5950 [details]
in.ps.bz2
bunzip2 in.ps.bz2
PPD=tp0.ppd gs -sDEVICE=cups -r600x600 -dSAFER \
-dNOPAUSE -dBATCH -sOutputFile=out.rast
rasterview 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 redesigned. Everyone uses CUPS Raster but no one wants to maintain the CUPS Raster output device. 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 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 . 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 black: 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 <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. ------------------------------- 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? 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. *** |