PNG Images Printed Incorrectly

Created attachment 112971
this image prints correctly

Created attachment 112972
this image prints incorrectly

Created attachment 112973
the HTML to print

Actually, testing the printing again, with the attachment links instead of my
local PNG files, now both images are misprinted for some reason.

This bug may be related to the PNG display bugs, 155470 and 146202, but it's not
a duplicate of them since the problem here is printing, not display.

related: bug 141656, bug 137637

on

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20021213

This URL triggers the bug

http://tubes.ominix.com/art/a/animals/hippopotamus-01.png

When I print
http://www.pinkjuice.com/howto/vimxml/pics/cos_pattern.png
in Mozilla (1.4.1, Windows ME) I get a black rectangle the size of the pic.

email: tobiasreif pinkjuice com

I can confirm this bug, transparent parts of the image print as black.

I confirm this bug with WinXp SP2, Firefox 1.0.7.

Created attachment 200918
the HTML to print

whoops, testcase HTML referred to the same image twice.

*** Bug 342325 has been marked as a duplicate of this bug. ***

Confirming bug for Windows XP, Firefox 1.5, further confirming the probability that this is not driver related.

I have another image that has similar behavior. It was processed using Inkscape and Irfanview, if that helps at all.

What we need is someone who knows his way around the PNG format to tell us what's so special about these PNGs we're trying to print.

Confirmed here with Firefox 1.5.0.7 (Windows XP)

According to ImageMagick's "identify", the "correct" image has a white background, while the "incorrect" one has a black background. It sounds like the browser is mixing in the image's background color for transparent pixels.

It might be useful to try printing <http://entropymine.com/jason/testbed/pngtrans/>.

Created attachment 244732
Image logo that prints incorrectly, has white background

This image doesn't seem to have a black background.

Created attachment 244733
Correct image ImageMagick Verbose Identify

Adding ImageMagick identification for correct image.

Created attachment 244734
Incorrect image ImageMagick Verbose Identify

Created attachment 244735
Incorrect logo image ImageMagick Verbose Identify

I did some investigating, not sure this info will help though, as I was unable to pinpoint the crucial difference.

Definitely doesn't affect it: Interlacing

The correct and incorrect images are actually quite different in composition. The correct one is:

- DirectClass
- Grayscale
- Gray alpha
- Has a white background color

While the incorrect one is:

- Pseudomap
- Grayscale
- Gray alpha
- Uses a colormap that's 256 large
- Has a non-standard resolution
- Has a rgb(1,1,1) background color.

The incorrect logo image is:

- Directmap
- RGB with 8-bit channels
- Transparent Alpha
- White background color

When I convert the logo image to grayscale using Irfanview, then the image prints properly. When I convert it to monochrome using ImageMagick, it still fails to print properly. I note that the latter used a colormap, the former did not. In fact, the monochrome version of the logo is extremely similar to incorrect image due as: both use PseudoClass and a color map. The only substantial difference is that while the incorrect image has 8-bit gray and 1-bit alpha, the incorrect monochrome logo image has 1-bit gray and 8-bit alpha.

Unfortunately, I still have been unable to get correct printing for RGB color PNGs with transparency. Can anyone else help?

*** Bug 235097 has been marked as a duplicate of this bug. ***

My apologies if it's improper or wrong to ask this here, but could someone please look into fixing this print problem? PNG images are growing more popular every day, and I see them make beautiful additions to many websites.

Considering this bug was first reported 4 years ago, with dozens of duplicates appearing since then, and now IE is the one printing images better, I really hope this will be given slightly more priority than it has.

Someone even suggested a correction in a patch (see duplicate bug 235097), but it sadly wasn't up to code with current codepaths, so it was promptly ignored and discarded. Perhaps someone could look into that and making a proper addition to Firefox 3?

Please help someone! What we see is not what prints! Much appreciate it.

D. Rippstein,

Tell me about it. I've been saying about this bug for ages, and I'd fix it, but I'm not a print guru. And I suspect that's the problem - nobody coding FF right now really is. At least, that's the best reason I know that it hasn't been fixed. Firefox's printing is getting quite embarrassingly bad now. I think it's about time MoCo hired a printing guru.

@D.Rippstein: It's not 4 years, but at least 5 years ago that this bug was reported, see https://bugzilla.mozilla.org/show_bug.cgi?id=141656

@Jeremy: I'd like to second your observation that printing in FF has become nothing but an embarresment. And it's not just "cosmetic" problems like the one this ticket is about - if you e.g. try to print Germany's most popular news-page - www.spiegel.de - Firefox will enter an endless loop (there is another ticket on that).

Too sad that FF development is heading to add new colorful toys every month instead of fixing basic functionality like printing.

Does the problem still occur in a recent trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

With 2007-09-22, both images print incorrectly...

The trunk build downloaded 01-October-2007 prints images correctly as far as I can tell --- when will this fix become part of a primary distribution???

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092504 Minefield/3.0a9pre
(In reply to comment #25)
> Does the problem still occur in a recent trunk build?
Attachment 112972 WFM on trunk. Someone with permissions should close this bug.

(In reply to comment #27)
> when will this fix become part of a primary distribution???
Gecko 1.9 (FF 3) is expected end of 2007 (or later, IMHO). First beta in October.

Thanks for testing.

-> WORKSFORME

Testing with the nightly shows that the start and end points of a route on Google Maps do not apply transparency correctly in the print preview.

Url I used for testing:

http://maps.google.com/maps?f=d&hl=en&geocode=&time=&date=&ttype=&saddr=860+E+2+St,+Brooklyn,+NY+11230&daddr=1050+e+2+st&sll=40.625386,-73.968136&sspn=0.005032,0.009956&ie=UTF8&ll=40.626062,-73.975121&spn=0.005032,0.009956&z=17&om=1

 Tested with: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre

(In reply to comment #30)

1. This bug is about confusing black and white.
2. This bug is about printing, print preview is irrelevant.
3. I can confirm. Print preview looks bad at all with your example, compared with Opera (white lines between the seperate images).

So it's probably a known bug (or two). Please file a new one, if you cant't find it.

*** Bug 466635 has been marked as a duplicate of this bug. ***

I've investigated this, and come to the conclusion that Firefox's behaviour is correct, and Google Maps' code is incorrect. My full explanation is here:
http://www.game-point.net/misc/googlemaps/

Please bug Google Maps to fix their code. I have no idea why they tell the browser to print non-transparent GIFs instead of the perfectly good transparent PNGs used on the browser screen.

In reply to comment #33:

So the site is broken. Reporter, you might be interested in http://www.mozilla.org/projects/tech-evangelism/site/procedures.html

Tony, this bug works, confirmed in comment 27 and 28. The original issue was printing attachment 112972.

Comment 33 is unrelated and is probably talking about bug 282434 "fails to correctly print route maps in Google Maps".

(In reply to comment #35)
> Tony, this bug works, confirmed in comment 27 and 28. The original issue was
> printing attachment 112972 [details].

Ah, sorry. Well, whoever wants to bug Google can file a Tech-Ev bug and follow the procedures in the URL in comment #34.

(In reply to comment #34)
> In reply to comment #33:
>
> So the site is broken. Reporter, you might be interested in
> http://www.mozilla.org/projects/tech-evangelism/site/procedures.html

I've had a reply from a Google dev after posting in their groups about this:

> Hi Jeremy (Jez),
>
> Your analysis of the printing bug is dead-on, all except for the reasons
> behind it. Firefox 1 and 2 had a nasty habit of printing transparent pixels
> in an image as solid black (you can still see this in the waypoint markers if
> you install FF2), so we added this "compromise" to print non-transparent
> light gray instead. This behavior was FINALLY fixed in firefox 3, although
> we didn't notice for a while.
>
> I'll be fixing this bug soon, although it won't make it to production
> immediately, especially during the holidays.

So looks like we won't need to evangelize on this one. :-D

Jeremy, while your investigation is interesting (thanks!), Google Maps printing issues are unrelated here. This bug is about wrong printing of some transparent PNGs in general.
This bug is closed as WORKSFORME since 2007-10-02 in 1.9 (Fx3), as long as attachment 112972 prints correctly.

Google's old workaround, resulting from this bug, is probably bug 282434 or part of it. If that's the case, comment in that bug. People CCd there might be interested.

Thanks again for your investigation!