191099 - Some PNGs with transparency printed black-on-white, some white-on-black

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect)

Description

[Eyal Rozenberg]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030121
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030121

For the soon-to-be-attached example, the browser renders the PNG images properly
- black on white - but the first one is printed black-on-white while the other
is printed white-(or gray)-on-black. I have tested this with several PS printing
drivers so it's probably not driver-related.

Reproducible: Always

Steps to Reproduce:
Load the page in mozilla, than print it to a printer or a PS file.

Comment 1

[Eyal Rozenberg]

Attachment: this image prints correctly

Comment 2

[Eyal Rozenberg]

Attachment: this image prints incorrectly

Comment 3

[Eyal Rozenberg]

Attachment: 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.

Comment 4

[Eyal Rozenberg]

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.

Comment 5

[R.K.Aa.]

related: bug 141656, bug 137637

Comment 6

[Joseph Wang]

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

Comment 7

[Tobias Reif]

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

Comment 8

[Dave Kimberley]

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

Comment 9

[Claude Fortier]

I confirm this bug with WinXp SP2, Firefox 1.0.7.

Comment 10

[Eyal Rozenberg]

Attachment: the HTML to print

whoops, testcase HTML referred to the same image twice.

Comment 11

[Jean-Michel Reghem]

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

Comment 12

[Edward Z. Yang]

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.

Comment 13

[Eyal Rozenberg]

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.

Comment 14

[Benjamin Kalytta]

Confirmed here with Firefox 1.5.0.7 (Windows XP)

Comment 15

[Kenneth Herron]

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

Comment 16

[Edward Z. Yang]

Attachment: Image logo that prints incorrectly, has white background

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

Comment 17

[Edward Z. Yang]

Attachment: Correct image ImageMagick Verbose Identify

Adding ImageMagick identification for correct image.

Comment 18

[Edward Z. Yang]

Attachment: Incorrect image ImageMagick Verbose Identify

Comment 19

[Edward Z. Yang]

Attachment: Incorrect logo image ImageMagick Verbose Identify

Comment 20

[Edward Z. Yang]

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?

Comment 22

[D. Rippstein]

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.

Comment 23

[Jez]

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.

Comment 24

[Peter Niemayer]

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

Comment 25

[Mats Palmgren (inactive)]

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

Comment 26

[Eyal Rozenberg]

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

Comment 27

[Eric]

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???

Comment 28

[j.j.]

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

Comment 29

[Mats Palmgren (inactive)]

Thanks for testing.

-> WORKSFORME

Comment 30

[mozbug1]

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

Comment 31

[j.j.]

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

Comment 33

[Jez]

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.

Comment 34

[Tony Mechelynck [:tonymec]]

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

Comment 35

[j.j.]

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

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

Comment 36

[Tony Mechelynck [:tonymec]]

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

Comment 37

[Jez]

(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

Comment 38

[j.j.]

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 [details] 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!