462872 - Under Linux/Unix Firefox (and also Thunderbird) should output send print jobs in PDF to the printing system and not in PostScript

Status: RESOLVED FIXED

(Core :: Printing: Output, enhancement)

Description

[Till Kamppeter]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.3) Gecko/2008101315 Ubuntu/8.10 (intrepid) Firefox/3.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.3) Gecko/2008101315 Ubuntu/8.10 (intrepid) Firefox/3.0.3

I am Till Kamppeter, leader of the OpenPrinting work group at the Linux Foundation.

As you can see on the page referenced above OpenPrinting has agreed on switching
from PostScript to PDF as standard print job format. This decision was made
between printing system and driver developers, application developers, desktop
developers, and many major printer manufacturers.

I want to ask you whether you can switch from PostScript to PDF as print job
output format also in Firefox and Thunderbird, as the most important web browser and mail client for Linux and Unix. The change should not be very complicated as the GTK printing functionality is already capable of rendering the printing output into PDF files.

Print jobs can be sent in principle as PDF on all Linux and Unix systems with CUPS 1.2 or newer. Even if CUPS does not process them in PDF format it works as CUPS converts them to PostScript then.

You could make it run-time configurable (via "Edit"/"Preferences") or depending on whether the system is Linux or Unix with CUPS 1.2.x or newer (this way they do it in Qt).

As you can also see on the referenced web page, KDE and Qt applications already
send jobs in PDF and OpenPrinting has organized the development of the CUPS
filters for the PDF printing workflow.

Debian and Ubuntu already include CUPS packages with PDF-based printing workflow.

Reproducible: Always

Steps to Reproduce:
Print out of Firefox or Thunderbird and look inyo the /var/log/cups/error_log. The incoming job is of the format "application/postscript" ("Loglevel debug" must be set in /etc/cups/cupsd.conf).


Expected Results:  
Jobs from Firefox and Thunderbird should be in PDF format.

Comment 1

[u285178]

When Firefox first started using cairo for printing it was using PDF format. Bug 415425 changed the format to PS because transparent images were printed as black.

The other issue is that gtk_printer_accepts_pdf() always returns TRUE regardless of whether the PDF format is supported. I've added a note about this to https://bugzilla.gnome.org/show_bug.cgi?id=560177#c6

Comment 2

[Till Kamppeter]

The problems of black backgrounds in images in PDF files are solved now, after various bug fixes in Ghostscript and Poppler, so PDF can now safely be used as printing output.

Comment 3

[Till Kamppeter]

All the mentioned problems are solved, so we should be able to safely switch to PDF output now.

Comment 4

[u285178]

Attachment: print as pdf where possible

Attached is a patch to make printing use PDF if supported by the printer.

gtk_printer_accepts_pdf() has been fixed in gtk+ 2.24 so this function can be used to check if the printer supports PDF.

Comment 5

[Ilja Sekler]

(In reply to comment #4)

> gtk_printer_accepts_pdf() has been fixed in gtk+ 2.24 so this function can be
> used to check if the printer supports PDF.

On Ubuntu 10.10, Firefox with this patch (and <https://bugzilla.mozilla.org/attachment.cgi?id=502460>, of course) applied still passes PS instead of PDF to CUPS, so probably either CUPS or gtk2 on Ubuntu lies. Would it be better to offer a preference to override detection and enforce PDF?

I get perfect prints of <http://weblogs.mozillazine.org/asa/archives/2010/12/new_firefox_4_betas.html> out of my HP inkjet printer only with a dirty private hack when I swap kOutputFormatPS and kOutputFormatPDF in

format = (gtk_printer_accepts_ps(mGtkPrinter)) ? nsIPrintSettings::kOutputFormatPS
                                               : nsIPrintSettings::kOutputFormatPDF;

Comment 6

[u285178]

(In reply to comment #5)
> On Ubuntu 10.10, Firefox with this patch (and
> <https://bugzilla.mozilla.org/attachment.cgi?id=502460>, of course) applied
> still passes PS instead of PDF to CUPS, so probably either CUPS or gtk2 on
> Ubuntu lies.

That's because the patch contains a gtk version check. gtk versions older than 2.24 lie about the PDF print capability so we fallback to PS in that case. This is probably a good thing as it ensures that if the gtk is new enough to correctly report the PDF print capability, the distro will also have recent versions of poppler and ghostscript that have fixed the PDF printing bugs.

> Would it be better to offer a preference to override detection and
> enforce PDF?

Probably not. There is no immediate benefit to using PDF. This is more about providing longer term benefits such as:

- Avoiding rasterization of transparency on printers that can print PDF directly

- Avoid unnecessary conversion of PS to PDF then back to PS in cups

- As PDF is replacing PS as the standard printer language, most of my cairo PS/PDF work will be focused on improving and optimizing the cairo PDF output. The PS surface will only get bug fixes.

Comment 7

[Ilja Sekler]

(In reply to comment #6)
> (In reply to comment #5)
>> On Ubuntu 10.10, Firefox with this patch [...] applied still
>> passes PS instead of PDF to CUPS, so probably either CUPS or
>> gtk2 on Ubuntu lies.
> 
> That's because the patch contains a gtk version check. gtk versions
> older than 2.24 lie about the PDF print capability so we fallback
> to PS in that case.

Sorry, I simply mixed up gtk2 and gnome versions :-(
Of course, the check for gtk_minor_version fails on Ubuntu 10.10.

>> Would it be better to offer a preference to override detection and
>> enforce PDF?
> 
> Probably not. There is no immediate benefit to using PDF.

I have to disagree. The benefit is major and immediate. Gecko PS output has severe issues at the moment when dealing with transparency. The visual impression of printing semi-transparent elements is the following: they get rendered to the screen resolution first (text is hinted to the screen resolution), then the bitmap is scaled up to 300dpi resolution and so dumped into PS. This looks very bad. But even usual 300dpi image fallbacks are perceptibly blurry when printed on a 600dpi inkjet printer.

The similar issue in respect to PDF output <https://bugzilla.mozilla.org/show_bug.cgi?id=624152> has a patch waiting for checkin, with this patch as well as prior to the regression passing Gecko PDF output directly to CUPS worked and works perfectly.

This is why it would be so nice to have a user_pref to allow testers and ordinary users to easily workaround Gecko, Cairo, Ghostscript, gtk2 and CUPS limitations and bugs without a need to build their own hacked versions.

Comment 8

[u285178]

(In reply to comment #7)
> I have to disagree. The benefit is major and immediate. Gecko PS output has
> severe issues at the moment when dealing with transparency. The visual
> impression of printing semi-transparent elements is the following: they get
> rendered to the screen resolution first (text is hinted to the screen
> resolution), then the bitmap is scaled up to 300dpi resolution and so dumped
> into PS. This looks very bad. But even usual 300dpi image fallbacks are
> perceptibly blurry when printed on a 600dpi inkjet printer.

If this is only occurring with PS you may be seeing this bug:

https://bugs.freedesktop.org/show_bug.cgi?id=24692

Can you try testing with cairo master to see if it has been fixed?

Comment 9

[Ilja Sekler]

(In reply to comment #8)

> If this is only occurring with PS you may be seeing this bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=24692
> 
> Can you try testing with cairo master to see if it has been fixed?

Yes, thank you, this is exactly the bug I saw and I can confirm that this is fixed for PostScript in git master.

Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110114 Firefox/4.0b10pre built from <http://hg.mozilla.org/mozilla-central/rev/67846d45d7cf> with --enable-system-cairo and required patches (cairo from <http://cgit.freedesktop.org/cairo/commit/?id=14afb69d3dc889715451cab6f54ec6ce73b431dd>).

Comment 10

[Karl Tomlinson (:karlt)]

gtk_printer_accepts_pdf() fixed in GTK for 2.24 here:
http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=7de568a2aec5c8d4edb5d1319ed10cfe6280c99c
And PDF used in GTK 2.24 from here:
http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=ed4605e597e8ac341d6fd4c60709ef4d88383fed

Comment 11

[Karl Tomlinson (:karlt)]

Comment on attachment 501949 [details] [diff] [review]
print as pdf where possible

Thanks.
r+ with the unnecessary brackets around gtk_printer_accepts_pdf(mGtkPrinter) removed.

Comment 12

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/dacd66ab4dc4