141656 - Transparent image pixels print white instead of background color of parent element

Status: RESOLVED FIXED

(Core Graveyard :: GFX, defect, P2)

Description

[Roland Mainz]

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

[Boris Zbarsky [:bzbarsky]]

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

[Roland Mainz]

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

[dcone (gone)]

this is my area

Comment 4

[Roland Mainz]

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

[dcone (gone)]

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

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Roland Mainz]

roc+moz:
Any interest in this bug ?

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't understand what this bug is about. Can you attach a testcase?

Comment 12

[Roland Mainz]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why don't you implement alpha on PS by making a dithered mask?

Comment 14

[Roland Mainz]

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

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[John Keiser (jkeiser)]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Roland Mainz]

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

[Deron Meranda]

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

[Jez]

Attachment: Shows Mozilla's lack of transparency support when printed

Comment 21

[Jez]

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

[Bob McElrath]

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

[Tobias Reif]

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

[Bob Firth]

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

Comment 25

[Oleg Sidletskiy]

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

Comment 26

[Oleg Sidletskiy]

OS -> All

Comment 27

[Jean-Marc]

(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

[Jean-Marc]

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

[Jean-Marc]

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

[Dov Kruger]

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

[Ben Goodger (use ben at mozilla dot org for email)]

fwiw this also impacts Google Maps.

Comment 32

[Darin Fisher]

-> default owner

Comment 33

[Boris Zbarsky [:bzbarsky]]

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

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Jungshik Shin]

(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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Kenneth Herron]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[tor]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

is this related to bug 191099?

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix #3

As above, with nits commented and a more conservative approach to setting black
pixels to white.

Comment 45

[tor]

Comment on attachment 197506 [details] [diff] [review]
fix #3

Looks like you attached the wrong patch.

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: real fix #3

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 197922 [details] [diff] [review]
real fix #3

carrying forward kherron's r+

Comment 48

[tor]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm going to be offline for a few days. If this gets approved, someone please
check it in for me.

Comment 51

[Asa Dotzler [:asa]]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked into trunk.

This only affects printing on Linux. Mac and Windows do not use this code.

Comment 53

[Asa Dotzler [:asa]]

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

[Deron Meranda]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Hixie (not reading bugmail)]

Is there a bug # for real support of alpha when printing?

Comment 57

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't know of one.

Comment 58

[Asa Dotzler [:asa]]

Comment on attachment 197922 [details] [diff] [review]
real fix #3

too late for non-critical changes of this size.

Comment 59

[Paul Cooper]

(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

[aaron]

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

[Joseph Shraibman]

This is blocking bug 282434.  Someone please reopen and fix this bug.

Comment 62

[Jez]

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

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