Closed
Bug 235097
Opened 20 years ago
Closed 17 years ago
[printing] png transparency mishandled (to file or to printer)
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 191099
People
(Reporter: beaudoin, Unassigned)
References
()
Details
Attachments
(5 files, 1 obsolete file)
User-Agent: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 PNG images with alpha transparency are printed as if against a solid black background (regardless of the page or image background color). PNG images with binary transparency seem to be handled correctly. http://www.darkknight.net/contact/index.html contains PNG images of both types. Reproducible: Always Steps to Reproduce: 1. Load a web page (sample given) in the Firefox browser 2. Print the page (to file or to printer) 3. Examine the output Actual Results: On Linux, PNG images with alpha transparency are not reproduced at all (printing of background images and colors was enabled). Images with binary transparency printed correctly. Images with alpha transparency showed black banding or were completely black (depending on content). Expected Results: A better behavior would be to composite the images against white first (this would at least save toner). Firefox should actually composite the image first unless the printer driver can be verified to support alpha transparency. Images used as backgrounds should be reproduced when the option to do so is selected.
Reporter | ||
Comment 1•20 years ago
|
||
In page setup, selected "Print Background (colors & images), then printed the page to a file. This matched with the hard copy. Converted the file to PDF format with 'ps2pdf mozilla.ps firefox_linux.pdf' to simplify viewing across platforms.
Reporter | ||
Comment 2•20 years ago
|
||
In page setup, selected "Print Background (colors & images), then printed the page to the printer. Printed the page again using Adobe Acrobat 6.0 Professional.
Reporter | ||
Comment 3•20 years ago
|
||
MSIE not only surprised me by displaying the images correctly, but it also printed them correctly to hard copy and to PDF.
Updated•20 years ago
|
Component: General → Printing
Product: Firefox → Browser
Version: unspecified → Trunk
Updated•20 years ago
|
Summary: [printing] png transparency mishandled (to file or to printer) → [ps][printing] png transparency mishandled (to file or to printer)
Comment 4•20 years ago
|
||
confirmed with linux trunk 20040220 see also bug 141656 (ps, xprint both do the same thing here) reassigning
Assignee: firefox → core.printing
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [ps][printing] png transparency mishandled (to file or to printer) → [printing] png transparency mishandled (to file or to printer)
Comment 5•19 years ago
|
||
This bug may be causing Google Map direction lines to print poorly in Firefox, e.g. if there is a line showing the path of travel it is printed with a black background.
Flags: blocking-aviary1.1?
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Comment 6•19 years ago
|
||
*** Bug 310288 has been marked as a duplicate of this bug. ***
Comment 7•19 years ago
|
||
PDF-Printout of http://www.bundeswahlleiter.de/bundestagswahl2005/ergebnisse/bundesergebnisse/grafik_sitze_99.html
Updated•19 years ago
|
Flags: blocking-aviary2.0?
If Bug 310288 is a duplicate, OS should be changed to ALL.
Updated•19 years ago
|
OS: Linux → All
Comment 9•19 years ago
|
||
*** Bug 311233 has been marked as a duplicate of this bug. ***
Comment 10•19 years ago
|
||
*** Bug 314153 has been marked as a duplicate of this bug. ***
Comment 11•19 years ago
|
||
*** Bug 315079 has been marked as a duplicate of this bug. ***
Comment 12•19 years ago
|
||
http://www.bundeswahlleiter.de/bundestagswahl2005/ergebnisse/bundesergebnisse/grafik_sitze_99.html has no transparency any more. We decided to make background white opaque to prevent the problem, so it cannot be used as test case any more.
Comment 13•19 years ago
|
||
There are plans for some core layout issues with printing that will be addressed for Gecko 1.9, but not on branch.
Flags: blocking-firefox2? → blocking1.8.1-
Comment 14•18 years ago
|
||
*** Bug 340541 has been marked as a duplicate of this bug. ***
Comment 15•18 years ago
|
||
Does this occur because of the SVG file? My test (duplicate bug) is on Wikipedia site (http://en.wikipedia.org/wiki/DVI). In this page you can see 2 pictures of DVI connector (one on the top of the page, another in the middle of the page). I clicked the first one to see its preview but only saw a transparency grid (like you see in Photoshop, all white on IE), then clicked it again oh, I got the picture. On the other hand, the second picture was clicked, previewed (also see transparecy grid with connectors) and displayed all correctly but incorrect printed. I don't know how related about SVG and PNG but this 2 images include 'transparency'.
Comment 16•18 years ago
|
||
Clearly that Firefox cannot handle PNG picture correctly when copying and printing.
Comment 17•18 years ago
|
||
Add to previous comment: I find out that not only the picture I mentioned is printed in black, all the PNG image files in that page are also printed in black, too. "I observe that they are only printed in black on their edge (area outside the connector edge)." Hope this can help solving this bug.
Comment 18•18 years ago
|
||
Gawd, I can't believe this bug *still* hasn't been fixed by Firefox 2 (or Bon Echo, at least). I think it should be made a blocker as it's quite a ridiculous thing that Firefox can render something to screen but not to a printer.
Comment 19•18 years ago
|
||
Its more than a little late to rearchitect printing on the branch, but I think you know that. Cairo might fix this, but that's Fx3
Comment 20•18 years ago
|
||
*** Bug 345963 has been marked as a duplicate of this bug. ***
Comment 21•18 years ago
|
||
This patch does a color mixing of the color white and the pixel value by a mixing ratio determined by the alpha value of the pixel. This should work as long as there is no background color. I have tested it on all the various png images that I found around the Internet and it seems to solve the ugly printing problem. (My first patch to Mozilla. :-)
Comment 22•18 years ago
|
||
(In reply to comment #21) > Created an attachment (id=245787) [details] > Patch fixing the png transparency problem in postscript output > > (My first patch to Mozilla. :-) > If you want to get people to notice a patch, you generally have to ask. See http://www.mozilla.org/hacking/life-cycle.html. It's kind of sad that patches slip through the cracks like this, but that's the way it works at the moment. In this case, your patch is already out of date, because that codepath is no longer used. The new graphics code is in gfx/src/thebes.
Attachment #245787 -
Attachment description: Patch fixing the png transparency problem in postscript output → Patch fixing the png transparency problem in postscript output (obsolete gfx/ps)
Attachment #245787 -
Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Comment 25•16 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.
You need to log in
before you can comment on or make changes to this bug.
Description
•