printing PDFs (and other complex documents) from GTK applications fails

Bug #802942 reported by mejo on 2011-06-28
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
cups (Ubuntu)
cups-filters (Ubuntu)
firefox (Ubuntu)
thunderbird (Ubuntu)

Bug Description


I'm discovering a bug when printing complex PDFs or other complex documents from GTK applications. Printing complex PDFs from evince, or sometimes even printing comples webpages from firefox result in one error page being printed instead of the document content:

| undefined |
| Q |

My printer is a Brother HL 5270DN. It doesn't matter whether the printer is connected via USB or as network printer. In both cases the described bug does happen. The PPD I use is "Brother HL-5270DN BR-Script3", similar to the one at

I discovered this bug in up-to-date Debian unstable for several years already. Now I switched one of my laptops to Ubuntu Natty (fresh installation), and unfortunately discovered the same bug there as well.

I'm pretty sure that this bug is related to bug #419143, and not really in CUPS, but rather in some library (poppler or cairo) used by GTK applications. The same PDFs that produce the described error in evince, print fine in okular.

I attach an example PDF that doesn't print in evince, but prints fine in okular. It's sufficient to (try to) print page 1 of the document.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: cups 1.4.6-5ubuntu1.2
ProcVersionSignature: Ubuntu 2.6.39-0.5~20110427-generic 2.6.39-rc5
Uname: Linux 2.6.39-0-generic x86_64
Architecture: amd64

Date: Tue Jun 28 13:13:29 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426)
Lpstat: device for Brother-HL-5270DN: lpd://
MachineType: LENOVO 4180W1H
Papersize: a4
PpdFiles: Brother-HL-5270DN: Brother HL-5270DN BR-Script3
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-2.6.39-0-generic root=/dev/mapper/vgsys-root ro quiet splash vt.handoff=7
SourcePackage: cups
UpgradeStatus: No upgrade log present (probably fresh install) 05/13/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 83ET56WW (1.26 )
dmi.board.asset.tag: Not Available 4180W1H
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr83ET56WW(1.26):bd05/13/2011:svnLENOVO:pn4180W1H:pvrThinkPadT420:rvnLENOVO:rn4180W1H:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: 4180W1H
dmi.product.version: ThinkPad T420
dmi.sys.vendor: LENOVO

mejo (jonas-freesources) wrote :
Changed in cups (Ubuntu):
status: New → Confirmed

I've got a Brother HL-5350DN and I have been able to reproduce the same error when using firefox to print webpages with images. This has now been fixed in poppler git. However I am unable to reproduce the problem using the PDF attached to this bug.

Could you try the following:

1. Print Magister-Studienordnung.pdf from evince to a PDF file.

2. Use poppler to convert the PDF to PS:
  pdftops -level3 file.pdf

3. Print the PS file with CUPS filtering disabled:
  lpr -o raw

If that fails to print please attach the PS file.

You could also try the same using PS level 2 (pdftops -level2)

Thomas Mayer (thomas303) wrote :
Download full text (252.8 KiB)

I have the same problem, using up-to-date Ubuntu 14.04.3, uname -a
Linux lat61 3.19.0-28-generic #30~14.04.1-Ubuntu SMP Tue Sep 1 09:32:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Same on earlier Kernels (3.13, 3.16) and even older versions of Ubuntu (12.04 and I also remember of 10.x or 11.x issues). So this problem might be really old.

With my old KyoceraMita FS-1020d (using the built-in network print server, paper feeder option and 128MB additional printer memory):

- Most of the web pages in firefox 40.0.3 print just fine (>90%)
- Most of thunderbird mails print just fine (TB 38.2.0).

Only some specific Mails and Web pages don't print in FF and TB, e. g. I can't print this web page reproducably:

What happens is that I can see the print job for a second in the queue, the printer starts to heat up (network works). But it does not print. The job disappears from the queue with status 'Finished' ('Abgeschlossen' in german) in the list of finished jobs.

Basically, there's two issues: 1st it does not print and 2nd, the job is considered to have finished (which is not true).

I'm using the PPD provided by Ubuntu 14.04.3 as well as the PPD provided by

Exactly the same web page ( prints perfectly using chromium Version 44.0.2403.89 Ubuntu 14.04 (64-bit) using the same printer setup unchanged.

When printing the web page from FF (which does not work), the debug output of cups shows this:

Page 1 (Scheduler not running?):
{'cups_connection_failure': False}
Page 2 (Choose printer):
{'cups_dest': <cups.Dest FS-1020D (default)>,
 'cups_instance': None,
 'cups_queue': u'FS-1020D',
 'cups_queue_listed': True}
Page 3 (Check printer sanity):
{'cups_device_uri_scheme': u'socket',
 'cups_printer_dict': {'device-uri': u'socket://',
                       'printer-info': u'FS-1020D',
                       'printer-is-shared': False,
                       'printer-location': u'home',
                       'printer-make-and-model': u'Kyocera Mita FS-1020D',
                       'printer-state': 3,
                       'printer-state-message': u'Warte auf Abschluss.',
                       'printer-state-reasons': [u'none'],
                       'printer-type': 10621012,
                       'printer-uri-supported': u'ipp://localhost:631/printers/FS-1020D'},
 'cups_printer_remote': False,
 'is_cups_class': False,
 'local_cups_queue_attributes': {'charset-configured': u'utf-8',
                                 'charset-supported': [u'us-ascii', u'utf-8'],
                                 'color-supported': False,
                                 'compression-supported': [u'none', u'gzip'],
                                 'copies-default': 0,
                                 'copies-supported': (1, 9999),
                                 'cups-version': u'1.7.2',
                                 'device-uri': u'socket://',
                                 'document-format-default': u'application/octet-stream',

Thomas Mayer (thomas303) wrote :

There's a cups bug report which was closed unresolved:

Thomas Mayer (thomas303) wrote :

The guys at cups do not feel responsible for linux issues as documented in

In the meantime I further tracked it down:

- Played around with printer drivers, using Kyocera's PPD, the PPD provided by ubuntu and also gave PPD from a try.
- Tried to install lsb-printing package with no changes
- Opened firefox tab about:config and resetted all user/custom variables which contain string "print" in variable name

As all that did not work, I have created at least a test case:

- Print web page in firefox with all printing variables in firefox reset
- Lookup the spooler file in /var/spool/cups
- Try to print it directly with lpr command

Test case 1 (works):
- Print in firefox
- top shows ghostscript (gs) and foomatic-rip process
- The page is printed perfectly
- I found a file in /var/spool/cups which I renamed to test1.pdf
- Direct printing with works fine with cat test1.pdf | lpr -P fs-1020d -# 1

Test case 2 (does not work):
- Print in firefox
- top shows ghostscript (gs) and foomatic-rip process
- The printer receives data (status LED) and heats up, but nothing is printed. Printer gets available again.
- I found a file in /var/spool/cups which I renamed to test2.pdf
- Direct printing also does not work with cat test2.pdf | lpr -P fs-1020d -# 1

Basically this could mean that my printer FS-1020d does not accept the content of test2.pdf while it most of the time works as shown with test1.pdf

Thomas Mayer (thomas303) wrote :

When I choose the "print to file" in the printing dialog in firefox, I get a pdf print-to-file.pdf created by firefox.

I have the same problem when I try print this file with cat print-to-file.pdf |lpr -P fs-1020d -# 1

/var/spool/cups then contains a file which I renamed to pdf print-to-file-cups.pdf

I have the same problem when I try print this file with cat print-to-file-cups.pdf |lpr -P fs-1020d -# 1

Thomas Mayer (thomas303) wrote :

The only workaround I'm aware of is to use the "print to file" dialog and then print the corresponding print-to-file.pdf with evince.

When I print the file with evince, I can find a file in /var/spool/cups which I renamed to print-to-file-cups-from-evince.pdf. Note that this file is 15% smaller than the original.

That said, I think it has something to do with the cups-filters package. At least, the file created by firefox can be read by evince which basically means that it seems to be somehow valid. The processing done by evince renders this document printable via cups on my FS-1020D printer.

Still, I'm not happy with this workaround because printing from firefox and thunderbird is somehow not reliable and many times I think printing is done while it has not even started.

Thomas Mayer (thomas303) wrote :

I've sent the pdf files to to see what the difference is.

All samples provide the same set of fonts.

But there is a difference between the non-working samples and working samples:
non-working test2.pdf and print-to-file.pdf are reported to be created by cairo 1.9.5 (

working print-to-file-cups-from-evince.pdf is reported to be created by cairo 1.13.1 ( Plus, print-to-file-cups-from-evince.pdf is reported to contain an image which is reported to not be contained by non-working print-to-file.pdf (the original of print-to-file-cups-from-evince.pdf)

That said, it could have to do with the cairo version or with some other piece of software which is or is not integrating this image.

Thomas Mayer (thomas303) wrote :

Cairo 1.9.5 dates back to ~2009/2010 according to

. My ubuntu 14.04.3 came shipped with libcairo2 package version 1.13.0~20140204-0ubuntu1.1 which dates back to ~2013/2014 according to

I guess that Firefox 40.0.3 still comes shipped with the old Cairo 1.9.5. Basically that means that the problem eventually is solved as soon as firefox updates to Cairo 1.13.0+.

Changed in cups (Ubuntu):
status: Confirmed → Invalid
Thomas Mayer (thomas303) wrote :

I guess that Cairo is part of the Gecko engine which then is used by firefox and thunderbird.

My Firefox 40.0.3 comes shipped with Gecko/20100101 according to about:support tab:

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0

which basically explains why cairo is so old (as said, cairo 1.9.5 dates to ~2009/2010).

To sum it up, either firefox needs to get a recent gecko engine and/or the gecko engine used for firefox needs to have a recent cairo version.

If that does not solve the problem (maybe mozilla just will not fix it for years), then cups-filters comes into play.

Same applies for thunderbird.

The problem seems to be that Firefox and Thunderbird use too old Cairo libraries. There for I add tasks for these two applications.

To the maintainers of Firefox and Thunderbird: Please check for the maintained versions of Ubuntu which Cairo versions are actually used and if one can somehow use a newer version. If this is not possible then report upstream bugs to Firefox and Thunderbird, at least for the Ubuntu version currently under development.

I closed the CUPS task as this is for sure no CUPS problem.

In cups-filters one could introduce a filter named oldcairopdftopdf to be run before pdftopdf if the incoming PDF is from a too old Cairo version. One could introduce a new MIME type to make CUPS detect such PDF. The new filter would simply run this PDF to some command line progrem which regenerates it, for example Ghostscript with the "pdfwrite" output device.

Such thing would be really an awkward workaround, a fix in Firefox, Thunderbird, and/or Gecko would be the correct solution for this problem.

Thomas Mayer (thomas303) wrote :

As far as I can see, gecko ubstream uses cairo 1.9.5 from 2010-01-21 which they are patching over and over. (where they forked at 2010-01-21)

Then report a bug to them, telling that the print rendering (PDF output) is fixed in Cairo 1.13 and that this needs to get backported somehow into Gecko, either by switching to 1.13 or doing another patch. Please post the link to your bug report(s) here.

Thomas Mayer (thomas303) wrote :
no longer affects: cups

Thank you very much, Thomas, I have subscribed to your upstream bug report now.

Changed in firefox:
importance: Unknown → Medium
status: Unknown → New
Thomas Mayer (thomas303) wrote :

@till-kamppeter As of Firefox 47.0, ubuntu 16.04, this is still not fixed.

During the update (coming from 14.04) I got asked via cups configuration if I wanted to opt-in for pre-filtering via cups. Which I opted in, in the hope that pdfs get rendered in a way my old printer is capable to understand. Still, it does not work.

I still think it's all about the ancient libcairo version FF is shipped with.

There is a FF compiler option --enable-system-cairo which enables the cairo version ubuntu comes shipped with. Would you like to give it a try?

Thomas Mayer (thomas303) wrote :

As of ubuntu 16.04, I can now print some PDFs in evince (16.04 ships v3.18.2), which were not printable before. Therefore, I don't have to use okular for that purpose any more (workaround for 14.04).

Basically, if FF knew about a new libcairo and that helped, this whole issue would be fixed for 16.04 at least (in respect to my printer and my scenarios). Please try the --enable-system-cairo compile option. If it works, maybe a backport to 14.04 is possible as well.

Thomas Mayer (thomas303) wrote :

In ubuntu 16.04, I tried out the libcairo which ubuntu comes shipped with and compiled FF47.0 myself, using the build-option --enable-system-cairo.

After the change, it works: I can finally print on my old Kyocera fs-1020d. Same for

This is the version of libcairo I used (and which also worked!):

apt-cache show libcairo2
Source: cairo
Version: 1.14.6-1

I made the build with:

sudo apt-get install packaging-dev libcairo2 libcairo2-dev
<= install all the dependencies for the build

pull-lp-source firefox xenial
cd firefox-47.0+build3/
echo "ac_add_options --enable-system-cairo" >> debian/config/
dpkg-buildpackage -rfakeroot -uc -b
sudo dpkg -i firefox_47.0+build3-0ubuntu0.16.04.1_amd64.deb

@till-kamppeter Would it be possible to build FF and TB with --enable-system-cairo in the distro, now that it works? I did not run any further testing yet, however. Just my testcase works now and fixes this issue for FF.

Thomas, probably it is possible to build FF and TB with the system's libcairo. I do not know why the maintainers of these packages stick to stone-old libraries which have many bugs which are already fixed in the current version.

But I will not do this fix as I am not the maintainer of FF and TB. The bug is also assigned to these packages so the actual maintainers will see this discussion and hopefully apply the fix. You can help them by attaching patches/debdiffs.

So as we know the solution now and that it is in FF and TB and not in cups and cups-filters, I am closing the appropriate tasks.

Thank you very much for investigating this.

Changed in cups-filters (Ubuntu):
status: New → Invalid
Changed in firefox (Ubuntu):
importance: Undecided → High
Changed in thunderbird (Ubuntu):
importance: Undecided → High
Thomas Mayer (thomas303) wrote :

I guess I know why upstream cairo never made it into Firefox: Mozilla's version of cairo is more like a fork than a version of cairo with a few patches applied.

Not only that: Some of the patches are documented in .patch files and a README. And some are not documented at all with just the change in the lib's files. E. g. does not have a .patch file or README entry.

These days, it would make sense to maintain a git branch of cairo with all the patches applied. Then they would be able to simply merge. And have a dependency to that branch.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Changed in thunderbird (Ubuntu):
status: New → Confirmed
Changed in firefox:
status: New → Unknown
Changed in firefox:
status: Unknown → New
Michael (linuxmagic) wrote :

Is this strictly a Thunderbird Bug? Or should it be moved to a more appropriate package

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.