Bug 909090

Summary: cups fails to print without error indication
Product: [Fedora] Fedora Reporter: Wolfgang Denk <wd>
Component: xpdfAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 20CC: jpopelka, lsof, tcallawa, twaugh, wd
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-29 11:45:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test file showing the problem
none
Strace output for "cups" while attempting to print this file
none
/var/spool/cups/c02094 left behind by this attempt to print
none
/etc/cups/ppd/lp.ppd
none
new PS file generated using ps2ps none

Description Wolfgang Denk 2013-02-08 08:20:15 UTC
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.

Comment 1 Wolfgang Denk 2013-02-08 08:30:57 UTC
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.

Comment 2 Wolfgang Denk 2013-02-08 08:33:06 UTC
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.

Comment 3 Tim Waugh 2013-02-11 12:56:28 UTC
What printer model are you using?

Please attach both testfile.ps and /etc/cups/ppd/lp.ppd.

Comment 4 Wolfgang Denk 2013-02-18 12:16:30 UTC
(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.

Comment 5 Wolfgang Denk 2013-02-18 12:17:16 UTC
Created attachment 698853 [details]
/etc/cups/ppd/lp.ppd

Comment 6 Wolfgang Denk 2013-10-15 10:50:33 UTC
Problem still present in F19 with all updates installed.

Comment 7 Tim Waugh 2013-11-18 13:49:07 UTC
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.)

Comment 8 Wolfgang Denk 2014-06-16 12:19:15 UTC
Created attachment 909098 [details]
new PS file generated using ps2ps

Comment 9 Wolfgang Denk 2014-06-16 12:20:52 UTC
(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.

Comment 10 Tim Waugh 2014-07-25 10:15:57 UTC
So the problem is either xpdf (which produces the postscript) or the printer (which interprets it).

Comment 11 Tom "spot" Callaway 2014-07-28 15:06:31 UTC
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?

Comment 12 Tim Waugh 2014-07-28 15:24:56 UTC
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

Comment 13 Fedora End Of Life 2015-05-29 08:53:19 UTC
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.

Comment 14 Fedora End Of Life 2015-06-29 11:45:58 UTC
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.