GTK apps should send PDF to CUPS when printing

[Till Kamppeter]

To implement the Blueprint "PDF as standard print job format"

https://blueprints.edge.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format

applications need to output PDF instead of PostScript when printing.

GTK applications still output PostScript. This can be changed by applying a simple patch which is attached.

This makes for example GEdit and GIMP (built-in standard dialog) sending PDF to CUPS.

Other programs, like evince and Firefox still send PostScript. Here there are probably similar patches needed in the applications themselves.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+2.0 - 2.14.3-0ubuntu2

---------------
gtk+2.0 (2.14.3-0ubuntu2) intrepid; urgency=low

  * debian/patches/061_use_pdf_as_default_printing_standard.patch:
    - launchpad patch to use pdf as default printing standard (lp: #258421)

 -- Sebastien Bacher <email address hidden> Thu, 25 Sep 2008 00:47:22 +0200

[Till Kamppeter (till-kamppeter)]

evince and several other applications are not affected by the GTK patch applied here. They need additional patches to output PDF instead of PostScript when printing, perhaps also in the individual applications.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

I tried forcing evince to output pdf. It sort of works, but the pdftopdf filter consumes very large amounts of memory on large-ish documents. For a 5 meg pdf file, the resident size of pdftopdf grew to 1.6 gigabytes and the machine was swapping like crazy before I killed the process.

I'm attaching the patch to evince that I used.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

It's possible the out-of-memory problems would be alleviated by the patch in http://bugzilla.gnome.org/show_bug.cgi?id=557112 .

[Till Kamppeter (till-kamppeter)]

Johan, can you try the patch to see whether evince printing works better then? Thanks.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Unfortunately, the patch from the gnome bug didn't help. Evince still produces very large pdf output files for some documents.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Wow. The poppler pdf output seems to be... less than optimal. Running pdfimages on a 3-page pdf that came from the evince "Print preview" functionality gave me 10 000 ppm images. Poppler seems to embed bitmaps into the pdf, one for each character of text.

No wonder the file is huge. Possibly related thread: http://lists.freedesktop.org/archives/cairo/2007-January/009096.html

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

The reason for the huge files is a bug in Cairo that was fixed very recently. See http://bugs.freedesktop.org/show_bug.cgi?id=12769

Would there be any chance of the Cairo fix going into Jaunty? If not, it's probably better to leave Evince as it is.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Sorry, make that "bug in poppler".

[Sebastien Bacher (seb128)]

the poppler changes are far to be trivial and probably for next cycle rather

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

With Karmic and poppler 0.11, the above patch to make evince output PDF works much better.

The PDF file that evince gives to cups is now just slightly bigger than the original, instead of being a factor of 100 larger, like it was before.

[Till Kamppeter (till-kamppeter)]

seb128, Poppler is fixed now in Karmic. Could you apply the Evince patch for Karmic's evince? Thanks.

[Sebastien Bacher (seb128)]

not sure that's something we want to change in a stable serie or a sru candidate

[Till Kamppeter (till-kamppeter)]

I thought about Karmic.

[Sebastien Bacher (seb128)]

sorry I read the previous comment too quickly, I will upload after the alpha freeze, could you open an upstream bug about that too?

[Till Kamppeter (till-kamppeter)]

Upstream bug added: http://bugzilla.gnome.org/show_bug.cgi?id=585442

[Till Kamppeter (till-kamppeter)]

seb128, not that the evince patch is not working correctly. It makes jobs sent to a real printer being sent in PDF, but it also emits PDF if the user prints to a file and chooses PostScript as output format. Probably some additional check is needed.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

The patch just papers over the fact that the original check is buggy: file_format is always set to the null string, when it should be "pdf" or "ps".

I'll try to figure out why this happens.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

I believe the bug is in this line in ev-print-operation.c:

file_format = gtk_print_settings_get (print_settings, GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT);

... but the key GTK_PRINT_SETTINGS_OUTPUT_FILE_FORMAT is only defined for the "output to file" pseudo-printer, according to http://library.gnome.org/devel/gtk/unstable/GtkPrintSettings.html

I'm attaching a new patch. If file_format is NULL (which it is for any real printer) or "pdf" (which it is when you select "print to file" and choose pdf as the format), the patch will make evince output pdf.

If file_format is "ps" (which it will only be if you select "print to file" and choose ps as the format), the patch will make evince output postscript.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Here's a slightly updated patch that uses gtk_printer_accepts_pdf().

[Till Kamppeter (till-kamppeter)]

Did you test this patch whether it actually works? Does gtk_printer_accepts_pdf(printer) results in True if printer is a CUPS queue?

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Yes, I tested that and it does work. But the patch with gtk_printer_accepts_pdf had a bug - apparently that function always returns true for the print to file "printer", even if the user selects postscript. Updated patch attached.

[Till Kamppeter (till-kamppeter)]

Thank you for the patches.

There is one possibility to make it even better: It should be checked what the input file format is and if it is the same as the print output format selected by your patch (PDF or PostScript), the input file should be sent directly to CUPS instead of evince re-rendering it.

[Bartek (tschew)]

Hi Till, I'm only familiar with the pagination parts of ev-print-operation (the re-rendering bit) and not with the initialisation steps so I might be off: As far as I understand gtk-print-operation is used for real printer targets in evince > 2.24 so evince does not do any re-rendering. (for instance, multiple pages per sheet works correctly for a real printer but has a number of bugs when exporting to file)

Except maybe in the case of printing multiple pages per sheet and printer drivers that don't natively support it. (not sure about this though, a quick glance does not reveal any relevant conditionals)

[Till Kamppeter (till-kamppeter)]

Another suggestion is the following (I do not know whether this is perhaps already implemented):

CUPS has sophisticated page management methods: N-up, selected pages, scale to fit, even/odd pages, ... These work very well if the page management is completely left to CUPS and not a part already done by evince or GTK Print and another part by CUPS. This is important because the page management actions have to be done in the correct order. For example if both 4-up and odd pages are selected, the first sheet should come out with page 1, 2, 3, 4 and the second with page 9, 10, 11, 12. So the N-up has to be done before filtering out every second sheet. For selected page ranges it is different. If the user selects 2-up and wants to print only page 1, 5-10, 16, and 17, he should get the following sheets: 1/5, 6/7, 8/9, 10/16, 17/blank.

So the best would be that in case of printing to a CUPS queue to always send the full document in PDF (the input file if it was already PDF) and the page management options as IPP attributes, as well as the PPD options. Then CUPS will do everything to get the document correctly printed.

[Bartek (tschew)]

I think the argument against doing what you suggest is that some printer drivers mess up the page management (is this even true? I don't know how cups operates and which part does the pagination.) and the evince guys wanted to produce a write once run everywhere solution.

Using gtk-print-operation the ranges and sheets that you mention should come out correctly (ie printing to a real printer with a recent version of evince), at least they do for me.

As for printing to file (which is known broken for the cases you mention) I have a patch in bug http://bugzilla.gnome.org/show_bug.cgi?id=583429 which operates the way you explain it. The only thing remaining to be fixed is reverse printing of multiple pages per sheet.

I wrote a test-script (http://bugzilla.gnome.org/show_bug.cgi?id=583976) for automatically testing different print setting combinations and it should be possible to adapt it to test printers other than "print to file". (it uses the accessiblity extensions to interact with the UI)

[Till Kamppeter (till-kamppeter)]

CUPS page management is completely independent of the printer driver. It happens in the pdftopdf filter (in Ubuntu and Debian unstable) or in the pstops filter (all other Linux distros).

Having the page management completely be donme by evince is also no problem, but it must be really completely done by evince, and it must have all functionality of the CUPS page management.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Adding a final, functionally equivalent but slightly cleaned-up version of the patch.

As for punting the page management to CUPS, code just landed in evince that does the page management with gtkprint: http://bugzilla.gnome.org/show_bug.cgi?id=557112

So presumably gtk is now the proper place for changing that.

[Till Kamppeter (till-kamppeter)]

Johan, thank you very much for your patch. It works perfectly. "Print to file" gives the selected file format and printing to a CUPS queue sends PDF. The output fioles are also small and do not have text converted to bitmaps. All is perfect now.

With this patch applied there should be no complaints any more that printing from evince gives bad quality, is too slow, or even does not work at all.

[Sebastien Bacher (seb128)]

Thank you for your work there, could you add your updated patch to the upstream bug for review?

[Sebastien Bacher (seb128)]

the issue is fixed in karmic