Bug 691733 - Strange printing behavior with GS 9.0.
Summary: Strange printing behavior with GS 9.0.
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: CUPS driver (show other bugs)
Version: 9.00
Hardware: PC Linux
: P4 major
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-27 21:33 UTC by Eugene
Modified: 2011-01-08 13:23 UTC (History)
11 users (show)

See Also:
Customer:
Word Size: ---


Attachments
sample paper (215.04 KB, image/jpeg)
2010-10-27 21:33 UTC, Eugene
Details
error.log, original file, printed file, scan thereof (797.81 KB, application/x-gzip)
2010-11-09 09:17 UTC, devurandom
Details
djd1400.ppd (17.05 KB, text/plain)
2010-11-09 15:13 UTC, Till Kamppeter
Details
C09-print-20101109-pstops-djd1400.ps (578.89 KB, application/postscript)
2010-11-09 15:14 UTC, Till Kamppeter
Details
First page of raster output from gs 8.71 (44.40 KB, image/png)
2010-11-11 17:55 UTC, Jakub Schmidtke
Details
Second page of raster output from gs 8.71 (52.73 KB, image/png)
2010-11-11 17:56 UTC, Jakub Schmidtke
Details
First page of raster output from gs 9.00 (44.18 KB, image/png)
2010-11-11 17:56 UTC, Jakub Schmidtke
Details
Second page of raster output from gs 9.00 (176.50 KB, image/png)
2010-11-11 17:56 UTC, Jakub Schmidtke
Details
Raster output of gs 8.71 (from import.ps generated using pdf2ps 8.71) (27.25 KB, image/png)
2010-11-11 17:57 UTC, Jakub Schmidtke
Details
Raster output of gs 9.00 (from import.ps generated using pdf2ps 8.71) (27.16 KB, image/png)
2010-11-11 17:57 UTC, Jakub Schmidtke
Details
It should use the new width and height values when reallocating memory. (862 bytes, patch)
2011-01-07 09:04 UTC, Evangelos Foutras
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene 2010-10-27 21:33:22 UTC
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.
Comment 1 Fabio Zanini 2010-10-28 12:47:22 UTC
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)
Comment 2 devurandom 2010-11-03 08:30:50 UTC
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
Comment 3 Till Kamppeter 2010-11-08 22:48:21 UTC
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.
Comment 4 devurandom 2010-11-09 09:17:58 UTC
Created attachment 6878 [details]
error.log, original file, printed file, scan thereof
Comment 5 devurandom 2010-11-09 09:19:29 UTC
(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).
Comment 6 Till Kamppeter 2010-11-09 15:11:33 UTC
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.
Comment 7 Till Kamppeter 2010-11-09 15:13:09 UTC
Created attachment 6881 [details]
djd1400.ppd

PPD file to reproduce the problem as shown above
Comment 8 Till Kamppeter 2010-11-09 15:14:53 UTC
Created attachment 6882 [details]
C09-print-20101109-pstops-djd1400.ps

PostScript input file to reproduce the problem as described above
Comment 9 Till Kamppeter 2010-11-09 21:22:37 UTC
Probably broken by color management stuff, assigning to Michael Vrhel.
Comment 10 Chris Liddell (chrisl) 2010-11-10 11:54:10 UTC
*** Bug 691759 has been marked as a duplicate of this bug. ***
Comment 11 Fabio Zanini 2010-11-11 11:26:47 UTC
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
Comment 12 Michael Vrhel 2010-11-11 17:21:38 UTC
Can you supply some screen shots of what you are seeing?  This does not sound like a color issue form the text descriptions.
Comment 13 Jakub Schmidtke 2010-11-11 17:54:35 UTC
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.
Comment 14 Jakub Schmidtke 2010-11-11 17:55:01 UTC
Created attachment 6893 [details]
First page of raster output from gs 8.71
Comment 15 Jakub Schmidtke 2010-11-11 17:56:07 UTC
Created attachment 6894 [details]
Second page of raster output from gs 8.71
Comment 16 Jakub Schmidtke 2010-11-11 17:56:24 UTC
Created attachment 6895 [details]
First page of raster output from gs 9.00
Comment 17 Jakub Schmidtke 2010-11-11 17:56:56 UTC
Created attachment 6896 [details]
Second page of raster output from gs 9.00
Comment 18 Jakub Schmidtke 2010-11-11 17:57:33 UTC
Created attachment 6897 [details]
Raster output of gs 8.71 (from import.ps generated using pdf2ps 8.71)
Comment 19 Jakub Schmidtke 2010-11-11 17:57:48 UTC
Created attachment 6898 [details]
Raster output of gs 9.00 (from import.ps generated using pdf2ps 8.71)
Comment 20 devurandom 2010-12-14 11:58:10 UTC
Any progress?
Comment 21 unsuspicious.fakename+ghoscr 2010-12-17 10:52:53 UTC
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?
Comment 22 Evangelos Foutras 2011-01-07 09:04:42 UTC
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.
Comment 23 Fabio Zanini 2011-01-07 10:07:33 UTC
(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.
Comment 24 Michael Vrhel 2011-01-07 17:08:55 UTC
Till or Eugene,

Can you confirm that rev 12005 fixes this issue?  

Thanks
Comment 25 Evangelos Foutras 2011-01-07 18:04:03 UTC
(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).
Comment 26 Michael Vrhel 2011-01-07 18:34:18 UTC
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.
Comment 27 Till Kamppeter 2011-01-07 19:12:27 UTC
I have tested with 12005 and the bug is still present for me.
Comment 28 Till Kamppeter 2011-01-07 19:47:28 UTC
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.
Comment 29 Till Kamppeter 2011-01-07 23:36:20 UTC
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.
Comment 30 Till Kamppeter 2011-01-07 23:48:03 UTC
Please test with more files whether my solution proposed in the previous comment is really stable and free of regressions.
Comment 31 Evangelos Foutras 2011-01-08 07:30:09 UTC
(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.
Comment 32 Till Kamppeter 2011-01-08 10:31:18 UTC
Sorry, now it is also fails for me. So these dummy values on color depth change seem to be generally wrong.
Comment 33 Till Kamppeter 2011-01-08 10:38:01 UTC
Can you try SVN rev 12008? Thanks.
Comment 34 Evangelos Foutras 2011-01-08 12:24:30 UTC
I tried r12010 and I can't reproduce either this issue, or the segfault on bug 690435. :)
Comment 35 Till Kamppeter 2011-01-08 12:29:13 UTC
Great, thank you very much.
Comment 36 Michael Vrhel 2011-01-08 13:23:51 UTC
Closing this since Till's fix appears to have fixed the issue.