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

[mejo]

Hello,

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:

+-------------------------+
| ERROR NAME; |
| undefined |
| COMMAND; |
| Q |
| OPERAND STACK; |
+-------------------------+

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 http://www.openprinting.org/download/PPD/Brother/BR5270_2_GPL.ppd

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
CupsErrorLog:

Date: Tue Jun 28 13:13:29 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426)
Lpstat: device for Brother-HL-5270DN: lpd://192.168.1.75/PASSTHRU
MachineType: LENOVO 4180W1H
Papersize: a4
PpdFiles: Brother-HL-5270DN: Brother HL-5270DN BR-Script3
ProcEnviron:
 LANGUAGE=de:en
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
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)
dmi.bios.date: 05/13/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 83ET56WW (1.26 )
dmi.board.asset.tag: Not Available
dmi.board.name: 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:
dmi.product.name: 4180W1H
dmi.product.version: ThinkPad T420
dmi.sys.vendor: LENOVO

[Adrian Johnson (ajohnson-redneon)]

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 file.ps

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

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: https://www.dab-bank.de/Service/Kontakt/

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 http://www.kyoceradocumentsolutions.de/index/serviceworld/downloadcenter.false._.FS1020D._.DE.html#LINUX

Exactly the same web page (https://www.dab-bank.de/Service/Kontakt/) 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://fs1020d.fritz.box:9100',
                       '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://fs1020d.fritz.box:9100',
                                 'document-format-default': u'application/octet-stream',
          ...

[Thomas Mayer (thomas303)]

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

https://www.cups.org/str.php?L3950+P-1+S0+C0+I0+E0+Qfirefox

[Thomas Mayer (thomas303)]

Maybe related: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/369503

[Thomas Mayer (thomas303)]

The guys at cups do not feel responsible for linux issues as documented in https://www.cups.org/str.php?L4715

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 http://www.openprinting.org/download/printdriver/debian/dists/lsb3.2/main/binary-amd64/openprinting-ppds-postscript-kyocera_20130319-1lsb3.2_all.deb 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:

How-To-Repeat:
- 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 https://boerse.dab-bank.de/maerkte-kurse/aktien.html 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 https://www.dab-bank.de/Service/Kontakt/ 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)]

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

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

I've sent the pdf files to http://pdf-analyser.edpsciences.org 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 (http://cairographics.org)

working print-to-file-cups-from-evince.pdf is reported to be created by cairo 1.13.1 (http://cairographics.org). 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)]

Cairo 1.9.5 dates back to ~2009/2010 according to http://cairographics.org/news/.

. 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 http://cairographics.org/news/.

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

[Thomas Mayer (thomas303)]

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.

[Till Kamppeter (till-kamppeter)]

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.

[Till Kamppeter (till-kamppeter)]

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

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

https://github.com/mozilla/gecko-dev/blob/master/gfx/cairo/README
http://cgit.freedesktop.org/cairo/commit/?id=12d521df8acc483b2daa844d4f05dc2fe2765ba6 (where they forked at 2010-01-21)

[Till Kamppeter (till-kamppeter)]

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

Created attachment 8660794
PDFs-FF40.tar.gz

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150826185918

Steps to reproduce:

Environment:
I have FF 40.0.3 and TB 38.2.0, ubuntu 14.04.3, Kernel 3.19, standard CUPS setup with Kyocera FS-1020d printer, PPD installed from various places (tried PPD provided by ubuntu, by Kyocera and by openprinting project .deb file), Printer with Paper Feeder option, 128M option, Kyocera Printserver (builtin).

All user specific settings for printing were reset in about:config (variables which contain 'print' in the name).

Reproduce with:
Case 1 (test1.pdf taken from cups):
- Open web page https://boerse.dab-bank.de/maerkte-kurse/aktien.html
- Print page

Case 2 (test2.pdf taken from cups):
- Open web page https://www.dab-bank.de/Service/Kontakt/
- Print page

Case 3 (print-to-file.pdf/print-to-file-cups.pdf):
- Open web page https://www.dab-bank.de/Service/Kontakt/
- Print to PDF File via printer dialog (cups_pdf), store to print-to-file.pdf
- Print the exported file with lpr (print-to-file-cups.pdf from /var/spool/cups)

Case 4 (print-to-file-cups-from-evince.pdf):
- Open web page https://www.dab-bank.de/Service/Kontakt/
- Print to PDF File via printer dialog (cups_pdf), store to print-to-file.pdf
- Print with evince (print-to-file-cups-from-evince.pdf from /var/spool/cups)

Actual results:

Case 1:
- Similar web page prints just perfectly

Case 2 + 3:
- Printer heats up, but does not print. Print job is lost, even cups thinks it was printed.

Case 4:
- Evince (which has Cairo 1.13) can print FF's ouput pdf file perfectly

Expected results:

Expected result: All 4 test cases should be printed.

[Thomas Mayer (thomas303)]

I experience similar problems with Thunderbird 38.2.0. Note that >90% of all web pages and emails print out just fine, so in general everything works (printer configuration and printer hardware work in general, and there are no problems with other applications. Using chromium (Version 44.0.2403.89 Ubuntu 14.04, 64-bit) I don't have the problem.

The difference with evince is that it uses Cairo 1.13 (~2014) while Gecko uses a patched version of Cairo 1.9.5 (~2010).

In the meantime there have been a lot of improvements to Cairo in respect to PDF: http://cgit.freedesktop.org/cairo/log/?qt=grep&q=pdf

Ubuntu printing maintainer and leader of the OpenPrinting project, Till Kamppeter sees a high likelyhood that this issue is fixed as soon as gecko/FF/TB is updated to a recent Cairo version (or Gecko's Cairo version gets patched respectively).

This issue affects multiple ubuntu users on launchpad, and I experience it myself for years (since at least ~2011).

[Thomas Mayer (thomas303)]

I reported upstream bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1204551

[Till Kamppeter (till-kamppeter)]

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

[Thomas Mayer (thomas303)]

There is also a tracking bug 739096 for the Cairo version. This bug deals with other issues (e.g. performance of graphics), so it is not a duplicate. However, bug 739096 might fix this issue (bug 1204551) as well in case you don't want to go for patching Cairo 1.9.5 again.

[Thomas Mayer (thomas303)]

As of FF 47.0, ubuntu 16.04, one of the test scenarios (Case 2) still does not print (with the other scenarios not tested again):

- Open web page https://www.dab-bank.de/Service/Kontakt/
- Print page

=> Printer Kyocera fs-1020d shows some action (fan blows, led indicates to get data), but then nothing prints out, and the printer goes idle again. As if nothing had happened. The print job is not visible to ubuntu any more which can be considered as a data loss (no print job, no printed page, no error visible to user).

[Thomas Mayer (thomas303)]

@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)]

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

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 https://www.dab-bank.de/Service/Kontakt/ on my old Kyocera fs-1020d. Same for https://boerse.dab-bank.de/maerkte-kurse/aktien.html.

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/mozconfig.in
dpkg-buildpackage -rfakeroot -uc -b
sudo dpkg -i firefox_47.0+build3-0ubuntu0.16.04.1_amd64.deb

I can't wait to see FF and TB to come shipped with a new version of libcairo.

[Thomas Mayer (thomas303)]

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 https://www.dab-bank.de/Service/Kontakt/ on my old Kyocera fs-1020d. Same for https://boerse.dab-bank.de/maerkte-kurse/aktien.html.

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/mozconfig.in
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.

[Till Kamppeter (till-kamppeter)]

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.

[Thomas-mayer (thomas-mayer)]

Reproduced against current nightly build 50.0a1 (2016-06-18)

[Thomas Mayer (thomas303)]

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. https://hg.mozilla.org/mozilla-central/rev/0edb40641826 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)]

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

[Pander (pander)]

See also https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/1306849 and https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/1076218

[Thomas-mayer (thomas-mayer)]

Similar issues with brother printers: https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/1306849

Not sure if this is also libcairo related.

[Carl-Daniel Hailfinger (hailfinger)]

See https://bugs.launchpad.net/ubuntu/+source/foomatic-db/+bug/1306849/comments/42 for a workaround for the broken Firefox

[Michael (linuxmagic)]

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

[Mathew Hodson (mhodson)]

From comments in bug 739096, this should depend on bug 739096. Do you still see the issue in Firefox 90 or later?

[Thomas Mayer (thomas303)]

Hi Mathew, just a few weeks ago, I got rid of my Kyocera-FS1020d (which was built in 2004, almost two decades ago and still running).

That said, I cannot test anything with this printer any more. Maybe someone else is still affected and can test what happens?

[madbiologist (me-again)]

@mejo, @Adrian Johnson - Can you still reproduce this bug on Firefox 90 or later?

[Paul White (paulw2u)]

Upstream bug was closed "RESOLVED INCOMPLETE" on 2021-08-16
Ubuntu tasks did not expire due to bug watch
No response to comment #37 for over one year so closing