Ticket #434 (closed defect: wontfix)

Opened 15 years ago

Last modified 14 years ago

"Spooled PDF File Rejected" from GTK+ LPR backend

Reported by: geofft Owned by:
Priority: normal Milestone: Spring 2010
Component: printing Keywords:
Cc: Fixed in version:
Upstream bug:


If you open a .jpg in Eye Of GNOME (the default JPG viewer), and print it via "Print to LPR", you get the standard "Spooled PDF File Rejected" error page.

Change History

comment:1 Changed 15 years ago by kaduk

We had a user who was getting a "you tried to spool a pdf file" error at Ashdown; if I remember correctly, he said that he was trying to print a text document from the default text editor (gedit?). I am somewhat curious if this is a more systematic issue, though I did not attempt to reproduce it at the time of the report.

comment:2 Changed 15 years ago by geofft

So I was reading the GTK+ source package and came across this Debian patch. I blame the second hunk in it:


comment:3 Changed 15 years ago by geofft

Excerpted from the changelog:

gtk+2.0 (2.15.5-2) experimental; urgency=low

  [ Imported from Ubuntu ]
  * 022_disable-viqr-im-for-vi-locale.patch,
  - for the rationale for the PDF for printing one see:

I wonder how easily we can get the second hunk reverted, since that page doesn't seem to talk about lpr.

comment:4 Changed 15 years ago by jdreed

  • Summary changed from "Spooled PDF File Rejected" from GUI printing in eog to "Spooled PDF File Rejected" from GTK+ LPR backend

Actually, if this affects all GTK+ apps using the LPR backend, this might explain a user who reported that evince was doing the same thing.

I've updated the description of this to reflect this -- change it back if it's inaccurate.

Here's a terrible idea for an interim solution: Have our lpr wrapper (which already does all sorts of unholy things) check if the input is a PDF, and if so, run pdf2ps (or similar) on it.

comment:5 Changed 15 years ago by davidben

Using PDF instead of PS as the print job format seems to have been declared The Future:


comment:6 Changed 15 years ago by geofft

jdreed: That sounds correct. I'm not sure why "Print to LPR" sometimes prints PS and sometimes prints PDF.

davidben: Well, the issue here is that our LPRng servers are unquestionably The Past. There is the other option of asking whether we can get a PDF filter on these servers (or more specifically, a PDF filter that converts PDF to PS instead of spitting out a PS error page) but I don't think anyone's excited about touching them.

cups.mit.edu, printers.mit.edu, etc. all deal with PDF. I don't think there's an assertion that LPD servers should accept PDF in that declaration, so that's why I'm somewhat looking at reverting the Debian patch and requesting backports. I'm not sure if that's harder than getting a PDF filter on the LPRng servers.

comment:7 Changed 14 years ago by jdreed

  • Priority changed from critical to major
  • Milestone set to Spring 2010

At 1/29 release-team, we suggested that our wrappers should check the file type and run pdf2ps if necessary. Producing potentially ugly output is better than producing no output.

We may want to add a cover sheet saying "This file automatically converted to PostScript?" and explain the implications of that, so that at some point in the future we don't spend hours trying to track down a problem with output quality or weird PS errors that is actually a result of pdf2ps.

comment:8 Changed 14 years ago by jdreed

This is complicated. The PDF comes on STDIN, so you need to look at STDIN to see if the first line matches /%PDF-/. But you can't rewind stdin, so you need to play games with StringIO, or read in the entire PDF (which could be several hundred MB), or do other stupid things to convert it. And then you need to play with the job to add a cover sheet explaining how the conversion was done and how to fix it. And it still may not be what the user wants. So I propose that if you try and print a PDF to an LPRng queue, you get whined at via Zenity and/or stderr as appropriate:

So, thoughts on this patch (assuming that we include a real URL)?

Index: files/usr/bin/lpr.debathena
--- files/usr/bin/lpr.debathena	(revision 24415)
+++ files/usr/bin/lpr.debathena	(working copy)
@@ -18,6 +18,7 @@
 import sys
 from subprocess import call, PIPE
 import urllib
+import re
     cupsd = cups.Connection()
@@ -91,6 +92,17 @@
 def execCups(command, queue, args):
     """Pass the command and arguments on to the CUPS versions of the command
+    if re.match("%PDF", sys.stdin.readline()):
+        if os.getenv('DISPLAY'):
+            call(['zenity', '--error', '--text=Cannot spool PDF file to LPRng queue.  See http://kb.mit.edu/whatever'])
+        sys.stdin.readlines()  #To avoid 'broken pipe' from Gtk backend
+        error(3, """
+You cannot print a PDF to an LPRng print queue.
+Convert the job to PostScript first.
+See http://kb.mit.edu/whatever
     new_command = '/usr/bin/cups-%s' % command
     os.execv(new_command, [command] + args)

comment:9 Changed 14 years ago by jdreed

Er, yeah, never mind, that is still reading from stdin.

comment:10 follow-up: ↓ 11 Changed 14 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

comment:11 in reply to: ↑ 10 Changed 14 years ago by adehnert

Replying to jdreed:


This link appears to be dead. I assume it was once some sort of documentation?

The error page I get (when printing with the lpr option in evince to eem, ET's printer) refers to  http://web.mit.edu/answers. That redirects to Confluence. I looked at all the titles under Debathena and Printing on Athena, and read the relevant-looking pages. None of them seemed to even suggest that a spooled PDF would be rejected, much less talk about work-arounds.

It'd be nice if that page gave me something obvious to look at that'd solve my problem.

(Relatedly, it's possibly worth noting that I ran "add-athena-printer eem", and the eem that gave me in the dialog did work.)

Note: See TracTickets for help on using tickets.