Created attachment 694983 [details] Test file showing the problem Description of problem: Some PDF documents, after conversion to PostScript using xpdf (verified last time against xpdf-3.03-5.fc18.x86_64) fail to print; I see a "systemd[1]: Started CUPS Printing Service." entry in the system log, but that's all. There is no error indication nor any other hint that there might be a problem, but no print job is ever generated, nor any output. Version-Release number of selected component (if applicable): cups-1.5.4-20.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. Print attached test file to your favorite printer. I'm usually just using "lpr testfile.ps". 2. 3. Actual results: No error indications, everything looks OK - but no data gets printed. Expected results: A print job with the expected output should be generated. Additional info: 1) In some so far ununderstood way xpdf is in this game, too, see Bug 901520; when printing with acroread or evince, the document can be printed (but then, some different PostScript output may be generated). 2) gs / gv can display this test file just fine. 3) See also bug 307421 Related entries in /var/log/cups/ : File "access_log" shows the attempts to print the document: ... localhost - - [08/Feb/2013:08:52:26 +0100] "POST /printers/duplex HTTP/1.1" 200 515 Create-Job successful-ok localhost - - [08/Feb/2013:08:52:26 +0100] "POST /printers/duplex HTTP/1.1" 200 123995 Send-Document successful-ok localhost - - [08/Feb/2013:08:54:08 +0100] "POST /printers/lp HTTP/1.1" 200 434 Create-Job successful-ok localhost - - [08/Feb/2013:08:54:08 +0100] "POST /printers/lp HTTP/1.1" 200 124020 Send-Document successful-ok localhost - - [08/Feb/2013:08:55:09 +0100] "POST /printers/lp HTTP/1.1" 200 434 Create-Job successful-ok localhost - - [08/Feb/2013:08:55:09 +0100] "POST /printers/lp HTTP/1.1" 200 124020 Send-Document successful-ok localhost - - [08/Feb/2013:08:57:30 +0100] "POST /printers/lp HTTP/1.1" 200 434 Create-Job successful-ok localhost - - [08/Feb/2013:08:57:30 +0100] "POST /printers/lp HTTP/1.1" 200 124020 Send-Document successful-ok File "page_log" shows: ... duplex wd 2090 [08/Feb/2013:08:52:26 +0100] 1 1 - localhost (stdin) iso_a4_210x297mm two-sided-long-edge lp wd 2091 [08/Feb/2013:08:54:08 +0100] 1 1 - localhost testfile.ps iso_a4_210x297mm one-sided lp wd 2092 [08/Feb/2013:08:55:09 +0100] 1 1 - localhost testfile.ps iso_a4_210x297mm one-sided lp wd 2093 [08/Feb/2013:08:57:30 +0100] 1 1 - localhost testfile.ps iso_a4_210x297mm one-sided File "error_log" is empty, nor are any other logs written.
Created attachment 694988 [details] Strace output for "cups" while attempting to print this file This is the output of "strace -f -o /tmp/xxx -p $(pidof cupsd)" while attempting to print the testfile.
Created attachment 694989 [details] /var/spool/cups/c02094 left behind by this attempt to print The strace output revealed that a file /var/spool/cups/c02094 was left behind. Actually I found a ton of such files from earlier attempts.
What printer model are you using? Please attach both testfile.ps and /etc/cups/ppd/lp.ppd.
(In reply to comment #3) > What printer model are you using? This is a Kyocera Mita FS-3830N printer. > Please attach both testfile.ps and /etc/cups/ppd/lp.ppd. testfile.ps is already there - see attachment #1 [details] above: Test file showing the problem (120.86 KB, application/postscript) 2013-02-08 03:20 EST, Wolfgang Den lp.ppd attached now.
Created attachment 698853 [details] /etc/cups/ppd/lp.ppd
Problem still present in F19 with all updates installed.
There are no problems running filters or running the socket backend, so either the PostScript is bad or the printer is unhappy with it for some other reason. I can certainly say that bug #307421 is not related, as you said that "lpr testfile.ps" exhibits the problem you are seeing. Has this ever worked? Try running "ps2ps testfile.ps newtestfile.ps" to get ghostscript to re-write the PostScript file. Does "lpr newtestfile.ps" work? (Just trying to get clues as to what might be wrong.)
Created attachment 909098 [details] new PS file generated using ps2ps
(In reply to Tim Waugh from comment #7) > There are no problems running filters or running the socket backend, so > either the PostScript is bad or the printer is unhappy with it for some > other reason. > > I can certainly say that bug #307421 is not related, as you said that "lpr > testfile.ps" exhibits the problem you are seeing. > > Has this ever worked? > > Try running "ps2ps testfile.ps newtestfile.ps" to get ghostscript to > re-write the PostScript file. Does "lpr newtestfile.ps" work? (Just trying > to get clues as to what might be wrong.) The problem is still present in F20. I attached a "newtestfile.ps" as requested. "newtestfile.ps" prints fine, while the original "testfile.ps" prints, but is missing the graphics.
So the problem is either xpdf (which produces the postscript) or the printer (which interprets it).
I sent both newtestfile.ps and testfile.ps to my office Canon and they both printed fine (and identically to each other and to how they render in gv). It looks like the issue is specific to your printer. Tim, any idea where this bug should go?
Wolfgang: maybe you could try changing some of the printer options, e.g. * setting resolution to 600dpi instead of 800dpi (i.e. turning off 'pre-rendering enhance') * turning off Smoothing/KIR
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.