415425 - Transparent backgrounds of images print as black under Linux

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Bill Gianopoulos [:WG9s]]

Attachment: testcase

This seems to be Linux only.  Transparent backgrounds of images are printing as black.  The image in the attachment demonstrates the issue.

Comment 1

[Bill Gianopoulos [:WG9s]]

Attachment: workaround - backout part of 193001 that prefers pdf if printer supports it

Bug 193001 added code that prints using PDF if the printer supports it.  It seems that transparent backgrounds don't work under PDF with the current trunk code.

Comment 2

[Bill Gianopoulos [:WG9s]]

CC'ing people involved with bug 193001 and cairo.

Comment 3

[Michael Ventnor]

Attachment: Give PS priority over PDF by default

So it seems that our PDF surface code is pants-on-head atrocious, and doesn't deserve priority over PS if the printer supports both. This patch switches the checks so that PS will always win over PDF if the printer supports it.

This may also fix other issues?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm surprised, I thought the cairo PDF code was very similar to the PS code, slightly better maintained if anything. Bill, you're not using --with-system-cairo, are you?

Comment 5

[Michael Ventnor]

I don't know. In the past we have had problems with the PDF surface that we didn't with PS (no images and widgets) and even bug 414314 has a discussion about PDF being the cause.

Of course I may be talking rubbish and PDF is indeed the better option...

Another thing is that we always update to Cairo git instead of the latest stable. Isn't that a bit of a crazy thing to do in such a late stage of the Firefox 3 period? That might also be the cause.

Comment 6

[Bill Gianopoulos [:WG9s]]

(In reply to comment #4)
> I'm surprised, I thought the cairo PDF code was very similar to the PS code,
> slightly better maintained if anything. Bill, you're not using
> --with-system-cairo, are you?
> 
I am not using --with-system-cairo, and the problem occurs with official trunk nightlies as well as with my own builds.

Comment 7

[u285178]

If you have found a bug in the cairo PDF output could your please send the PDF to the cairo list or cairo bugzilla so the problem can be fixed.

I am not aware of any issues in the cairo PDF image embedding. Does your printer actually support PDF or is the PDF being converted by some other application? I had a look at the gtk source and could not see that gtk_printer_accepts_pdf is set based in the printer capabilities. It seems to always be set to true.

If your printer does not support PDF 1.4 or later I would expect using the cairo PS output to give better results. Although bug 406376 would also need fixing.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Gah :-(. So this is really a GTK bug, then. And even if it was returning something meaningful from gtk_printer_accepts_pdf, we'd also need an API to tell us which PDF level is supported, right? Of course we'll also want an API to tell us which PS level is supported, but at least we can use PS level 2 without problems.

So let's go back to PS for now, fix 406376 by defaulting to level 2, and hope that GTK+ gets sorted out in the future.

Comment 9

[Bill Gianopoulos [:WG9s]]

(In reply to comment #7)
> I am not aware of any issues in the cairo PDF image embedding. Does your
> printer actually support PDF or is the PDF being converted by some other
> application? I had a look at the gtk source and could not see that
> 
My printer is an HP DeskJet 648C.  As far as I know, it does not do either postscript or PDF natively.  I suspect the PDF is being converted to postscript and then to the PCL the printer wanted in the first place. So, by preferring PDF over postscript, I think an entire extra conversion process is taking place to get the output the a format the printer actually understands.

Comment 10

[Reed Loden [:reed]]

Checking in widget/src/gtk2/nsDeviceContextSpecG.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsDeviceContextSpecG.cpp,v  <--  nsDeviceContextSpecG.cpp
new revision: 1.100; previous revision: 1.99
done

Comment 11

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