GTK apps should send PDF to CUPS when printing

Bug #258421 reported by Till Kamppeter on 2008-08-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
evince (Ubuntu)
Ubuntu Desktop Bugs
gtk+2.0 (Ubuntu)

Bug Description

To implement the Blueprint "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.

Related branches

Till Kamppeter (till-kamppeter) wrote :
Changed in gtk+2.0:
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

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

Changed in gtk+2.0:
status: New → Fix Released
Changed in gtk:
status: Unknown → New
Till Kamppeter (till-kamppeter) wrote :

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.

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.

It's possible the out-of-memory problems would be alleviated by the patch in .

Till Kamppeter (till-kamppeter) wrote :

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

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

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:

The reason for the huge files is a bug in Cairo that was fixed very recently. See

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

Sorry, make that "bug in poppler".

Sebastien Bacher (seb128) wrote :

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

Changed in evince:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist

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.

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

Sebastien Bacher (seb128) wrote :

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

I thought about Karmic.

Sebastien Bacher (seb128) wrote :

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

Changed in evince:
status: Unknown → New

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.

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.

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

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.

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

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

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.

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) wrote :

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)

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) wrote :

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

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.

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:

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

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.

Changed in evince (Ubuntu):
status: New → In Progress
status: In Progress → Triaged
Sebastien Bacher (seb128) wrote :

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

Changed in evince:
status: New → Fix Released
Sebastien Bacher (seb128) wrote :

the issue is fixed in karmic

Changed in evince (Ubuntu):
status: Triaged → Fix Released
Changed in evince:
importance: Unknown → Wishlist
status: Fix Released → New
Changed in gtk:
importance: Unknown → Wishlist
Changed in gtk:
status: New → Fix Released
Changed in evince:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.