| Summary: | Strange printing behavior with GS 9.0. | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Eugene <TheDZhon> |
| Component: | CUPS driver | Assignee: | Michael Vrhel <michael.vrhel> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | andyrtr, devurandom, foutrelis, gnugv_maintainer, htl10, iosonofabio, mike, sjakub, till.kamppeter, twaugh, unsuspicious.fakename+ghoscr |
| Priority: | P4 | ||
| Version: | 9.00 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
sample paper
error.log, original file, printed file, scan thereof djd1400.ppd C09-print-20101109-pstops-djd1400.ps First page of raster output from gs 8.71 Second page of raster output from gs 8.71 First page of raster output from gs 9.00 Second page of raster output from gs 9.00 Raster output of gs 8.71 (from import.ps generated using pdf2ps 8.71) Raster output of gs 9.00 (from import.ps generated using pdf2ps 8.71) It should use the new width and height values when reallocating memory. |
||
I confirm this bug report with a different printer (and driver). My CUPS logs also show no error. System info: ArchLinux AMD64 CUPS 1.4.4 GS 9.00 Splix 2.0.0 XEROX Phaser 6110MFP (via network, no USB) Confirming for printing PDF files as a website (Chromium) using net-print/cups-1.4.4-r2, app-text/ghostscript-gpl-9.00, net-print/gutenprint-5.2.5-r1. Also see the downstream Gentoo bug at http://bugs.gentoo.org/show_bug.cgi?id=341207 Can you provide a CUPS error_log in debug mode, as described under "CUPS error_log" on https://wiki.ubuntu.com/DebuggingPrintingProblems and also capture the print job input as described under "Capturing print job data" on the same page? The instructions are originally written for Ubuntu but should also work on any other distribution using CUPS. If "sudo ..." does not work, get root in another terminal window and enter the commands without "sudo" there. Please attach the error_log and the captured print job file to this bug report. Created attachment 6878 [details]
error.log, original file, printed file, scan thereof
(In reply to comment #4) > Created an attachment (id=6878) [details] > error.log, original file, printed file, scan thereof P.S. The scan only shows the first corrupted page (no 2). Now I am able to reproduce the bug with a direct call of Ghostscript on the command line. Ghostscript version is the current state of SVN, but also can be the 8.71 which comes with Ubuntu Maverick (probably one of the backported fixes contains this bug). Run the following command line with the attached PPD file and PostScript input file: PPD=djd1400.ppd gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout C09-print-20101109-pstops-djd1400.ps > out.raster Then see the result on the second page using rasterview from http://www.easysw.com/~mike/rasterview/ The input file is derived from devurandom's attachment via cupsfilter -m application/vnd.cups-postscript -p djd1400.ppd cups-error-report-20101109/C09-print-20101109.ps > C09-print-20101109-pstops-djd1400.ps The PPD file is of HPLIP 3.10.6, generated via /usr/lib/cups/daemon/cups-driverd cat drv:///hpcups.drv/hp-deskjet_d1400_series.ppd > djd1400.ppd No changes in the PPD's default settings were done. Created attachment 6881 [details]
djd1400.ppd
PPD file to reproduce the problem as shown above
Created attachment 6882 [details] C09-print-20101109-pstops-djd1400.ps PostScript input file to reproduce the problem as described above Probably broken by color management stuff, assigning to Michael Vrhel. *** Bug 691759 has been marked as a duplicate of this bug. *** You may be interested in the downstream bug report at the ArchLinux distro page, there seem to be some comments about the two bugs being related: https://bugs.archlinux.org/task/21388 Can you supply some screen shots of what you are seeing? This does not sound like a color issue form the text descriptions. Michael Vrhel: This is what I am getting. C09_a-gs-8.71.png and C09_b-gs-8.71.png is the first and second page of the rasterview output of the procedure described by Till Kamppeter when ghostscript 8.71 is used. C09_a-gs-9.00.png and C09_b-gs-9.00.png is the same, but using ghostscript 9.00. Also, I included what I am getting when I use the same procedure, but instead of using C09-print-20101109-pstops-djd1400.ps file I used 'import.ps' file generated from http://www.andy-roberts.net/misc/latex/tutorial5/import.pdf using pdf2ps command. Now, that command is part of the ghostscript as well, so I converted import.pdf file twice, using 8.71 (creating import_8.71.ps file that had 1.9MB) and 9.00 version (creating import_9.00.ps that had 8.7MB!). The raster output of gs 8.71 from both import_8.71.ps and import_9.00.ps looks fine. The raster output of gs 9.00 from import_9.00.ps looks fine, but the output (of gs 9.0) from import_8.7.ps has the image inverted. I will include screenshots for those. Created attachment 6893 [details]
First page of raster output from gs 8.71
Created attachment 6894 [details]
Second page of raster output from gs 8.71
Created attachment 6895 [details]
First page of raster output from gs 9.00
Created attachment 6896 [details]
Second page of raster output from gs 9.00
Created attachment 6897 [details]
Raster output of gs 8.71 (from import.ps generated using pdf2ps 8.71)
Created attachment 6898 [details]
Raster output of gs 9.00 (from import.ps generated using pdf2ps 8.71)
Any progress? Getting the same messed up pages above page 1 with up to date archlinux x86_64, canon pixma 5300. Now, is this related to those other two bugs mentioned in archlinux bugtracker along with this one or not? Or even closely related / a duplicate of bug 691539? Should they be added as depends on or something? I don't get what this issue has to do with colour management... http://bugs.ghostscript.com/show_bug.cgi?id=691539 http://bugs.ghostscript.com/show_bug.cgi?id=691586 Also: Anyone tried yet, if the "partial patch" attached to bug 691539 changes anything for this one? Created attachment 7098 [details] It should use the new width and height values when reallocating memory. After some bisecting, it appears that the issue was introduced in r11149. Further looking into it, I noticed that the old width and height values were used in a memory reallocation call, which apparently causes this weird behavior. I'll attach my patch which seems to correct the behavior noticed above (with C09-print-20101109-pstops-djd1400.ps). If those affected can test this patch and confirm that it works for them (or not), that'd be great. Unfortunately, bug 691759, which was marked as a duplicate of this bug, remains. Therefore, I'm assuming it's a different issue. (In reply to comment #22) > I'll attach my patch which seems to correct the behavior noticed above (with > C09-print-20101109-pstops-djd1400.ps). If those affected can test this patch > and confirm that it works for them (or not), that'd be great. Tested successfully under the following conditions: System info: ArchLinux AMD64 CUPS 1.4.4 GS 9.00 Splix 2.0.0 XEROX Phaser 6110MFP (via network, no USB) It works (no garbaged output). Thanks a lot. > Unfortunately, bug 691759, which was marked as a duplicate of this bug, > remains. Therefore, I'm assuming it's a different issue. I agree, that seems to be unrelated, since I used to have this bug but not bug 691759. Till or Eugene, Can you confirm that rev 12005 fixes this issue? Thanks (In reply to comment #24) > Can you confirm that rev 12005 fixes this issue? The issue is still present in r12006. Please see my patch above. It's quite small and seems to solve the corrupt output after the first page, but of course it needs review for correctness and completeness. However, r12005 seems to fix bug 691759 (which was previously --incorrectly-- marked as a duplicate of this bug; I believe it should be marked as a duplicate of bug 691760 instead). OK. That would appear to be the issue. I will push your patch through and if it comes back ok with the regression test, I will commit it. I have tested with 12005 and the bug is still present for me. The patch works for me, too, but the patch could be wrong. It re-introduces bug #690435. So do not commit it. First, the function gdev_prn_maybe_realloc_memory() in base/gdevprn.c is defined like this: int gdev_prn_maybe_realloc_memory(gx_device_printer *prdev, gdev_prn_space_params *old_sp, int old_width, int old_height, bool old_page_uses_transparency) It wants to have the OLD widths, heights, transparency usage, and space params. It seems that the new values have to be provided inside the prdev structure. The problem seems to be this one: /* We set the old dimensions to -1 if we have a color depth change, so that memory reallocation gets forced. This is perhaps not the correct approach to preven crashes like in bug 690435. We keep it for the time being until we decide finally */ if (color_set) { width_old = -1; height_old = -1; } else { width_old = pdev->width; height_old = pdev->height; } To force a memory reallocation when the color depth has changed, the old width and height are set to dummy values. This seems to break memory reallocation at least for some cases, like in this bug. Replacing the "-1"s in the code piece of the previous comment by "1"s fixes this bug and bug #690435, but I do not know why this works. I found it out simply by testing. So this is not necessarily the correct solution but also only a workaround. I have committed it as SVN rev. 12007 for the time being. Please test with more files whether my solution proposed in the previous comment is really stable and free of regressions. (In reply to comment #29) > Replacing the "-1"s in the code piece of the previous comment by "1"s fixes > this bug and bug #690435, but I do not know why this works. I found it out > simply by testing. So this is not necessarily the correct solution but also > only a workaround. > > I have committed it as SVN rev. 12007 for the time being. r12007 still fails for me. The command I used is the one posted above: PPD=../djd1400.ppd ./bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout ../C09-print-20101109-pstops-djd1400.ps >../out.raster && rasterview ../out.raster From the second and on, pages still look like http://bugs.ghostscript.com/attachment.cgi?id=6896. Sorry, now it is also fails for me. So these dummy values on color depth change seem to be generally wrong. Can you try SVN rev 12008? Thanks. I tried r12010 and I can't reproduce either this issue, or the segfault on bug 690435. :) Great, thank you very much. Closing this since Till's fix appears to have fixed the issue. |
Created attachment 6843 [details] sample paper Hello, I have following troubles with printing. When i add new text printjob with at least 2 pages (e.g. pdf file), first page looks normally, but other duplicates current page on each paper. It looks like layered document with text shifts. (see attachment). If i print pdf as image (force), all pages look well. (of course, with less smooth fonts). System info: Gentoo Linux AMD64 CUPS 1.4.4 GS 9.00 HPlip 3.10.9 HP DeskJet 1460 (1400 Series PPD) cups logs with debug mode dont contain any errors.