"Spooled PDF File Rejected" from GTK+ LPR backend

[geofft]

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.

[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.

[geofft]

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

 http://patch-tracker.debian.org/patch/series/view/gtk+2.0/2.18.3-1/061_use_pdf_as_default_printing_standard.patch

[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,
    061_use_pdf_as_default_printing_standard.patch:
  - for the rationale for the PDF for printing one see:
    https://wiki.ubuntu.com/PDFasStandardPrintJobFormat

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

[jdreed]

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.

[davidben]

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

 http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format

[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.

[jdreed]

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.

[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
 
 try:
     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)
 

[jdreed]

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

[jdreed]

 http://kb.mit.edu/confluence/x/IQdS

[adehnert]

Replying to jdreed:

 http://kb.mit.edu/confluence/x/IQdS

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.)