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

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
16 years ago
8 years ago

People

(Reporter: eyalroz, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 112971 [details]
this image prints correctly
(Reporter)

Comment 2

16 years ago
Created attachment 112972 [details]
this image prints incorrectly
(Reporter)

Comment 3

16 years ago
Created attachment 112973 [details]
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.
(Reporter)

Comment 4

16 years ago
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

16 years ago
related: bug 141656, bug 137637

Comment 6

16 years ago
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

15 years ago
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

15 years ago
I can confirm this bug, transparent parts of the image print as black.
Assignee: rods → core.printing
QA Contact: sujay → owen-bugzilla

Comment 9

13 years ago
I confirm this bug with WinXp SP2, Firefox 1.0.7.
(Reporter)

Comment 10

13 years ago
Created attachment 200918 [details]
the HTML to print

whoops, testcase HTML referred to the same image twice.
Attachment #112973 - Attachment is obsolete: true

Comment 11

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

Comment 12

12 years ago
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.
(Reporter)

Comment 13

12 years ago
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.
OS: Windows 2000 → Windows XP

Comment 14

12 years ago
Confirmed here with Firefox 1.5.0.7 (Windows XP)

Comment 15

12 years ago
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

12 years ago
Created attachment 244732 [details]
Image logo that prints incorrectly, has white background

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

Comment 17

12 years ago
Created attachment 244733 [details]
Correct image ImageMagick Verbose Identify

Adding ImageMagick identification for correct image.

Comment 18

12 years ago
Created attachment 244734 [details]
Incorrect image ImageMagick Verbose Identify

Updated

12 years ago
Attachment #244732 - Attachment description: Image that prints with black background, internal bg is white → Image logo that prints incorrectly, has white background

Comment 19

12 years ago
Created attachment 244735 [details]
Incorrect logo image ImageMagick Verbose Identify

Comment 20

12 years ago
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?

Updated

12 years ago
Duplicate of this bug: 235097

Comment 22

11 years ago
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

11 years ago
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

11 years ago
@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/
(Reporter)

Comment 26

11 years ago
With 2007-09-22, both images print incorrectly...

Comment 27

11 years ago
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

11 years ago
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. 

Thanks for testing.

-> WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Updated

11 years ago
Flags: in-testsuite?

Comment 30

11 years ago
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

11 years ago
(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.

Updated

10 years ago
Duplicate of this bug: 466635

Comment 33

10 years ago
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
Assignee: printing → english-us
Status: RESOLVED → REOPENED
Component: Printing: Output → English US
Flags: in-testsuite?
OS: Windows XP → All
Product: Core → Tech Evangelism
QA Contact: irixman+bugzilla → english-us
Hardware: PC → All
Resolution: WORKSFORME → ---
Version: Trunk → unspecified

Comment 35

10 years ago
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".
(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.
Assignee: english-us → nobody
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago10 years ago
Component: English US → Printing: Output
OS: All → Windows XP
Product: Tech Evangelism → Core
QA Contact: english-us → printing
Hardware: All → PC
Resolution: --- → WORKSFORME
Version: unspecified → Trunk

Comment 37

10 years ago
(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

10 years ago
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!

Updated

8 years ago
You need to log in before you can comment on or make changes to this bug.