452 bytes, image/png
785 bytes, image/png
194 bytes, text/html
2.60 KB, image/png
1.09 KB, text/plain
1.15 KB, text/plain
1.39 KB, text/plain
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.
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.
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.
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.
Assignee: rods → core.printing
QA Contact: sujay → owen-bugzilla
I confirm this bug with WinXp SP2, Firefox 1.0.7.
Created attachment 200918 [details] the HTML to print whoops, testcase HTML referred to the same image twice.
Attachment #112973 - Attachment is obsolete: true
*** 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.
OS: Windows 2000 → Windows XP
Confirmed here with Firefox 18.104.22.168 (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 [details] Image logo that prints incorrectly, has white background This image doesn't seem to have a black background.
Created attachment 244733 [details] Correct image ImageMagick Verbose Identify Adding ImageMagick identification for correct image.
Attachment #244732 - Attachment description: Image that prints with black background, internal bg is white → Image logo that prints incorrectly, has white background
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?
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 [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
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.
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
OS: Windows XP → All
Product: Core → Tech Evangelism
QA Contact: irixman+bugzilla → english-us
Hardware: PC → All
Resolution: WORKSFORME → ---
Version: Trunk → unspecified
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 ago → 10 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
(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 [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!
You need to log in before you can comment on or make changes to this bug.