Last Comment Bug 141656 - Transparent image pixels print white instead of background color of parent element
: Transparent image pixels print white instead of background color of parent el...
Status: RESOLVED FIXED
:
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: All Linux
P2 normal with 7 votes (vote)
: Future
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
:
:
Mentors:
: 164222 164289 184430 191765 224225 240030 294165 (view as bug list)
Depends on:
Blocks: 282434 297977
  Show dependency treegraph
 
Reported: 2002-05-01 19:50 PDT by Roland Mainz
Modified: 2009-09-17 13:46 PDT (History)
37 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Shows Mozilla's lack of transparency support when printed (29.72 KB, application/zip)
2003-07-23 09:09 PDT, Jeremy Morton
no flags Details
fix (9.15 KB, patch)
2005-07-31 20:41 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
fix #2 (10.06 KB, patch)
2005-07-31 22:18 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
kherron+mozilla: review+
Details | Diff | Splinter Review
fix #3 (3.75 KB, patch)
2005-09-26 20:45 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
roc: review+
Details | Diff | Splinter Review
real fix #3 (10.55 KB, patch)
2005-09-29 15:44 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
roc: review+
tor: superreview+
asa: approval1.8b5-
asa: approval1.8rc1-
Details | Diff | Splinter Review

Description User image Roland Mainz 2002-05-01 19:50:49 PDT
RFE: Blend transparent pixels to background color instead of "white",
Currently we blend the transparent parts of an image to white, e.g the color of
a blank sheet of paper.
Unfturtunately this breaks if someone prints with the option "print background
color and images"... it may be usefull to blend to the background color instead.

Can we "peek" the background color pixels in an easy way and blend to that color
instead ?
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2002-05-01 20:18:06 PDT
Note that this breaks sites that have non-background content (eg other images)
under the transparent images in question... So it would be nice to fix this.  :)
Comment 2 User image Roland Mainz 2002-05-01 23:44:55 PDT
Note:
I am _NOT_ requesting full client-side rasterisation of the printer raster (this
is more or less impossible since it _may_ require more memory than a 32bit
application can handle (just think about DIN A0 at 600 DPI =:-)) ...

... only some fill-transparent-pixels-with-bg-color hacking... :)
Comment 3 User image dcone (gone) 2002-05-02 06:39:09 PDT
this is my area
Comment 4 User image Roland Mainz 2002-05-02 07:15:36 PDT
dcone wrote:
> this is my area

Is it possible to implement this outside of the gfx/-layer that a fix affects
all platforms and print modules, please ?
Comment 5 User image dcone (gone) 2002-05-02 09:53:04 PDT
we certainly could get the color to blend to from a xp place.  As far as 
implementation.. thats a platform specific thing.. all the platforms do 
transparency different ways, handle transparent pixels in there own way.
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2003-01-08 09:12:46 PST
*** Bug 164222 has been marked as a duplicate of this bug. ***
Comment 7 User image Boris Zbarsky [:bz] (still a bit busy) 2003-01-08 09:15:33 PST
*** Bug 184430 has been marked as a duplicate of this bug. ***
Comment 8 User image Boris Zbarsky [:bz] (still a bit busy) 2003-01-08 09:15:42 PST
*** Bug 164289 has been marked as a duplicate of this bug. ***
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2003-02-03 11:24:15 PST
*** Bug 191765 has been marked as a duplicate of this bug. ***
Comment 10 User image Roland Mainz 2003-03-16 16:40:26 PST
roc+moz:
Any interest in this bug ?
Comment 11 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2003-03-17 05:10:40 PST
I don't understand what this bug is about. Can you attach a testcase?
Comment 12 User image Roland Mainz 2003-03-18 16:41:21 PST
Robert O'Callahan wrote:
> I don't understand what this bug is about. Can you attach a testcase?

Well, I am not sure how I can produce a testcase for a functionality which was
not implemented yet... ;-/

I can try to describe it...
... currently on platforms which do not support alpha channel we blend
transparent images to white (e.g. the color of a blank sheet of paper), however
this does not look good if we print with "backgrounds enabled" - think about a
"black" background where images with a alpha value of 0.5 are blended to "white"
(correct would be to blend to "black").

My idea was to add a (cheap) hook to peek the (background) color for a given
pixel from layout/content(!!). I know this turns things upside down but I don't
have a better idea unless gfx/src/ps gets rewritten from scratch to support
either an alpha channel or the ability to peek a color for a given pixel (this
is easier to implement than an alpha channel... :)
Comment 13 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2003-03-19 12:33:01 PST
Why don't you implement alpha on PS by making a dithered mask?
Comment 14 User image Roland Mainz 2003-03-19 13:24:47 PST
Robert O'Callahan wrote:
> Why don't you implement alpha on PS by making a dithered mask?

Three problems:
1. Mozilla's gfx API does not have methods for doing the alpha stuff in the gfx
modules itself (yet, AFAIK you are working on that ... but I can't remember the
bugid... ;-( )
2. I am not a Postscript guru - any idea who can help and is still working on
Mozilla ?
3. The emulation of an alpha channel using a dithered mask is tricky for older
printers (doing such kind of blending within restriced memory may not return the
expected results since the printer may try to scale the mask down until it fits
into memory... ;-/ ).
Comment 15 User image Boris Zbarsky [:bz] (still a bit busy) 2003-04-21 08:52:30 PDT
*** Bug 202795 has been marked as a duplicate of this bug. ***
Comment 16 User image John Keiser (jkeiser) 2003-04-25 15:36:10 PDT
This causes white images that look normal in the browser on top of a dark
background to be printed as white boxes.  Not cool at all, and definitely a bug
more than an enhancement.
Comment 17 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2003-04-25 19:57:17 PDT
This can't be fixed just with some "set the background color" hack. Consider the
case where the background isn't set as a color, but as some image. We need some
sort of direct support for image transparency in GFX printing.
Comment 18 User image Roland Mainz 2003-04-28 09:23:45 PDT
Robert O'Callahan wrote:
> This can't be fixed just with some "set the background color" hack. Consider 
> the case where the background isn't set as a color, but as some image. We need 
> some sort of direct support for image transparency in GFX printing.

Well, implement bug 193849 ("Move 'opacity' handling down into GFX") and we can
easily fix this bug... :)
Comment 19 User image Deron Meranda 2003-07-18 11:20:00 PDT
I'm seeing images blended against BLACK when printed rather than white.  Thus
for mostly transparent images I end up with an ugly big black rectangle on the
printed page. (Moz 1.4.0 and a Lexmark Optra T616 Postscript).

I even printed to a postscript file rather than a printer, and when viewed with
ggv it is also apparent that blending is being done against black.

This is standards-mode HTML with the <body> background explicitly set to white.
 Also the image (a color PNG with alpha channel) has it's background color set
to white in the bKGD chunk.  This is reproducable on a web page with nothing but
a single <img> inside the body.

I understand the difficulties of doring true blending against the background. 
But since PNG images may carry a bKGD chunk, wouldn't it be okay to at least
blend against the image's own recommended background color than black?  After
all, that's the whole purpose of the bKGD chunk, to provide a recommended
blending background when the real background is unavailable.  And from what I
can tell that's what IE does to.  That should require no or little gfx/layout
enhancements to do.
Comment 20 User image Jeremy Morton 2003-07-23 09:09:37 PDT
Created attachment 128335 [details]
Shows Mozilla's lack of transparency support when printed
Comment 21 User image Jeremy Morton 2003-07-23 09:14:43 PDT
I had this exact problem today :-)  I've created an attachment (shamelessly
ripped/modified from multimap.com) illustrating the problem.  The red circle is
imposed on top of the map graphic.  It displays fine on the screen, but print
it, and the red circle is no longer transparent, transparent pixels being
replaced by white pixels.

The poster(s) who said that a botch job making transparent pixels the same as
the background color was good enough were wrong; it's not good enough.

I have to say, I don't see the difficulty of supporting this; can't the
transparency be rendered in Mozilla first, then sent to the printer?  Then you
wouldn't need all this fancy 'printer alpha blending capability'.  Internet
Explorer seems to manage to print this transparency just fine.
Comment 22 User image Bob McElrath 2003-10-08 20:01:17 PDT
On mozilla 1.4 and 1.6a (today's nightly) in linux, my transparent png's print
solid black, not white at all (and obviously not alpha-channel rendered).

Another test case:
http://bob.mcelrath.org/equation.png
http://bob.mcelrath.org/equation.ps

Bug #137114 indicates black background printing but only for mac.  This clearly
isn't mac-specific.  Is 137114 a dup?
Comment 23 User image Tobias Reif 2003-10-14 13:56:37 PDT
Just in case additional test cases are of use:
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.
Comment 24 User image Bob Firth 2003-11-07 18:05:20 PST
*** Bug 224225 has been marked as a duplicate of this bug. ***
Comment 25 User image Oleg Sidletskiy 2004-04-21 18:14:09 PDT
*** Bug 240030 has been marked as a duplicate of this bug. ***
Comment 26 User image Oleg Sidletskiy 2004-04-21 18:16:30 PDT
OS -> All
Comment 27 User image Jean-Marc 2004-08-06 04:35:00 PDT
(In reply to comment #23)
> Just in case additional test cases are of use:
> 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.

I get the same BLACK (not white as the summary says !) rectangle using a recent
Mozilla Firefox 0.9.1+ on XP. I'm printing on a Canon i560 inkjet.
Note : the print preview itself seems correct given that it shows the
transparent pixels in white, i.e. the background colour.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040805
Firefox/0.9.1+
Comment 28 User image Jean-Marc 2004-08-06 05:14:32 PDT
More tests ...

Mozilla 1.8a3 (trunk) with forced and printed text and background colours
*as well as* Mozilla Firefox 0.9.1+ (aviary branch) with forced and printed text
and background colours :

Print preview
 transparent = correct background colour

Canon printer (XP printing)
 transparent = black with my Canon printer

Virtual ("file") Postscript printer (HP Color LaserJet PS, XP printing)
 transparent = correct background colour

Tests were done with a black on yellow combination. Generated PS files were
rendered with GSview.
Comment 29 User image Jean-Marc 2004-08-06 05:18:06 PDT
Sorry, a mistake :

Virtual ("file") Postscript printer (HP Color LaserJet PS, XP printing)
 transparent = white (incorrect)

(not "correct" as I just put it)
Comment 30 User image Dov Kruger 2005-01-26 17:24:44 PST
This is a horrible bug for anyone who wants to draw layered maps. See
http://davidson.dl.stevens-tech.edu/NYHOPS/maincontrol.html

You can view the page, but how can you possibly print it if Mozilla won't
support the actual look?

Comment 31 User image Ben Goodger (use ben at mozilla dot org for email) 2005-02-18 11:51:33 PST
fwiw this also impacts Google Maps.
Comment 32 User image Darin Fisher 2005-02-18 16:25:35 PST
-> default owner
Comment 33 User image Boris Zbarsky [:bz] (still a bit busy) 2005-07-26 21:13:04 PDT
*** Bug 294165 has been marked as a duplicate of this bug. ***
Comment 34 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-07-31 20:20:46 PDT
Bug 137114 is the Mac version of this bug, and I believe it's fixed on Windows,
so I'm morphing this to be Linux only. I have a patch that fixes this for
Postscript level 3 printers, and which falls back to the current behaviour on
level 2 printers. Currently it breaks level 1 printers completely. I'm not sure
whether we care about that, or if we do, how to fix it.
Comment 35 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-07-31 20:41:28 PDT
Created attachment 191160 [details] [diff] [review]
fix

This fixes the bug by drawing images using image dictionaries and, on level 3
printers, using "explicit mask". When a mask is present, we emit the mask data
interleaved with the image data, and on level 1/2 printers we extract and
discard the mask data as we consume the data stream.

I figured out how to not break level 1 printers. In theory this patch should
work on level 1 printers. I don't know how to test that, though.

I mainly fixed this to get SVG printing working...
Comment 36 User image Jungshik Shin 2005-07-31 21:11:35 PDT
(In reply to comment #35)

> I figured out how to not break level 1 printers. In theory this patch should
> work on level 1 printers. I don't know how to test that, though.

bug 234182 comment #11 would help you. 
Comment 37 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-07-31 22:18:16 PDT
Created attachment 191172 [details] [diff] [review]
fix #2

Okay, I tested this using that level 1 hack and it works now... we can't use <<
or >>!

I also made the transparent pixels turn white so that on level 1/2 printers
we'll at least print the image on a white background rather than a black
background. It may not look better in all cases but at least it won't waste as
much ink :-)
Comment 38 User image Kenneth Herron 2005-08-06 17:01:40 PDT
Comment on attachment 191172 [details] [diff] [review]
fix #2

This looks fine. There is a way to print masked images with PS level 2 (and
level 1, I think), but it's more complex than I've ever had time to implement.
Comment 39 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-08-07 15:17:21 PDT
I tried an approach mentioned in the Adobe docs that works with level 2: create
a pattern with the image, and use it a source for the "image" command, but it
doesn't seem to work with large images. Basically the problem is that the
pattern subroutine can be executed an undefined number of times, so you need to
read all the image data into a buffer and store it, but that overflows
Ghostscript limits at least.
Comment 40 User image tor 2005-09-06 10:34:02 PDT
Comment on attachment 191172 [details] [diff] [review]
fix #2

>+        if (alphaDepth == 8) {
>+          alpha = alphaRow[x];
>+        } else {
>+          alpha = (alphaRow[x >> 3] & (0x80 >> (x & 7))) ? 255 : 0;
>+        }

nit - a macro here might help future readability.

>+        if (alpha >= 128) {
>+          v |= 0x80 >> (x & 7);

nit - likewise.

>+        } else {
>+          // Make the transparent pixel white. Then if we print to a PS
>+          // level 1 or 2 printer, we won't print transparently but we
>+          // won't print a nasty huge black area either
>+          PRUint8 *pixel = row + (x * 3);
>+          pixel[0] = pixel[1] = pixel[2] = 0xFF;
>+        }

I'm not an expert on PS (know just enough to be dangerous), so is this new PS
code only doing binary masking?  If not, this bit of code is going to give an
odd discontinuity to the output.
Comment 41 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-06 14:11:28 PDT
(In reply to comment #40)
> (From update of attachment 191172 [details] [diff] [review] [edit])
> >+        if (alphaDepth == 8) {
> >+          alpha = alphaRow[x];
> >+        } else {
> >+          alpha = (alphaRow[x >> 3] & (0x80 >> (x & 7))) ? 255 : 0;
> >+        }
> 
> nit - a macro here might help future readability.
> 
> >+        if (alpha >= 128) {
> >+          v |= 0x80 >> (x & 7);
> 
> nit - likewise.

How about I just add comments? A macro seems like an unnecessary level of
indirection.

> >+        } else {
> >+          // Make the transparent pixel white. Then if we print to a PS
> >+          // level 1 or 2 printer, we won't print transparently but we
> >+          // won't print a nasty huge black area either
> >+          PRUint8 *pixel = row + (x * 3);
> >+          pixel[0] = pixel[1] = pixel[2] = 0xFF;
> >+        }
> 
> I'm not an expert on PS (know just enough to be dangerous), so is this new PS
> code only doing binary masking?

Yep.

> If not, this bit of code is going to give an odd discontinuity to the output.

Images with 1-bit alpha normally just have black in those pixels so flipping it
to white isn't going to change the error on level 1/2 printers, on average. It's
 possible this loses information in the translucent pixels of 8-bit alpha images. 

We could only set the pixel to white if the alpha value is exactly zero; in that
case, the image probably doesn't have any useful color information there,
because programs seem to set those pixels to black (probably compresses better),
so choosing white isn't going to change the error on average. For A-values > 0
and < 0.5, on level 1/2 printers, we'll paint the color that's in the image.
This just means putting "if (alpha > 0)" inside the else branch. Should I do that?
Comment 42 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-06 14:25:49 PDT
Better still, we could test the pixel and set it to white if and only if the
alpha value is zero and the color is black.
Comment 43 User image Christian :Biesinger (don't email me, ping me on IRC) 2005-09-22 14:11:34 PDT
is this related to bug 191099?
Comment 44 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-26 20:45:58 PDT
Created attachment 197506 [details] [diff] [review]
fix #3

As above, with nits commented and a more conservative approach to setting black
pixels to white.
Comment 45 User image tor 2005-09-28 18:50:47 PDT
Comment on attachment 197506 [details] [diff] [review]
fix #3

Looks like you attached the wrong patch.
Comment 46 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-29 15:44:49 PDT
Created attachment 197922 [details] [diff] [review]
real fix #3
Comment 47 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-29 15:47:07 PDT
Comment on attachment 197922 [details] [diff] [review]
real fix #3

carrying forward kherron's r+
Comment 48 User image tor 2005-09-29 17:51:14 PDT
Comment on attachment 197922 [details] [diff] [review]
real fix #3

+	   // Many tools set fully transparent pixels to black (perhaps
+	   // because that compresses better). So for PS printers that
+	   // don't support transparency, we'll get the image on an ugly
+	   // black background which is especially bad on printers.

Here's hoping that's true.  sr=tor
Comment 49 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-29 18:39:52 PDT
Comment on attachment 197922 [details] [diff] [review]
real fix #3

Fixes printing of transparent images on Linux. This is important for printing
SVG on Linux, which goes through this path. Without this patch, printing SVG
will output the SVG with a black background.
Comment 50 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-30 11:12:05 PDT
I'm going to be offline for a few days. If this gets approved, someone please
check it in for me.
Comment 51 User image Asa Dotzler [:asa] 2005-09-30 12:31:07 PDT
We need this landed on the trunk and verified there, along with a clear picture
of the risk to the branch if we take this. Does this impact other platforms
besides linux? TOR, can you help us with this?
Comment 52 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-09-30 13:47:11 PDT
checked into trunk.

This only affects printing on Linux. Mac and Windows do not use this code.
Comment 53 User image Asa Dotzler [:asa] 2005-10-05 11:36:33 PDT
Comment on attachment 197922 [details] [diff] [review]
real fix #3

we're now locked down and in ship mode for 1.8b5. If you'd like to re-request
approval for this change, please set the approval1.8rc1? flag.
Comment 54 User image Deron Meranda 2005-10-07 08:46:59 PDT
Is there going to be any attempt to use the color value
specified in the PNG bKGD chunk, if present, rather than
white?  That's exactly what bKGD is intented for...to
provide a default background color to use when alpha
compositing is not possible.  Use white if there's no
bKGD, but otherwise obey the intent of the PNG file.
Comment 55 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-10-07 14:58:19 PDT
Nope. Too much work for branch, and on trunk we'll have some kind of solution
for transparent compositing via the cairo PS backend.
Comment 56 User image Hixie (not reading bugmail) 2005-10-10 10:35:05 PDT
Is there a bug # for real support of alpha when printing?
Comment 57 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2005-10-10 13:16:36 PDT
I don't know of one.
Comment 58 User image Asa Dotzler [:asa] 2005-10-10 15:38:20 PDT
Comment on attachment 197922 [details] [diff] [review]
real fix #3

too late for non-critical changes of this size.
Comment 59 User image Paul Cooper 2005-12-02 04:22:39 PST
(In reply to comment #11)
> I don't understand what this bug is about. Can you attach a testcase?
> 

You may find this page (which depends on overlaying images with transparency) useful: www.add.scar/org/WMSbrowser/

It may be slow loading, as the site is under development, but each category of topographic information is loaded as a separate image with a transparent background. Unused categories are replace with a transparent blank image. It works fine on screen, looks OK in print preview but just prints a blank image. 
Comment 60 User image aaron 2007-01-11 10:02:14 PST
I am also having this error when printing a web page from Firefox 2.0.0.1.  This issue is not resolved!  When printing all "transparent" pixels turn white instead of displaying the pixel color of the underlaying element.  Even when the print settings are set to remove background colors, if the image with a transparency overlays text, the text is hidden underneath the white of the supposedly transparent pixels.
Comment 61 User image Joseph Shraibman 2007-07-20 14:51:07 PDT
This is blocking bug 282434.  Someone please reopen and fix this bug.
Comment 62 User image Jeremy Morton 2007-07-21 02:16:32 PDT
Joseph,

This bug has been marked RESOLVED FIXED (not sure why)... the bug you're probably wanting is bug #191099, which is still open.  I'd love to see that fixed.
Comment 63 User image Jeremy Morton 2008-12-13 16:13:37 PST
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.

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