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

RESOLVED FIXED in Future

Status

Core Graveyard
GFX
P2
normal
RESOLVED FIXED
15 years ago
8 years ago

People

(Reporter: Roland Mainz, Assigned: roc)

Tracking

Trunk
Future
All
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

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

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

Comment 2

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

15 years ago
this is my area
Assignee: rods → dcone
(Reporter)

Comment 4

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

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

Updated

15 years ago
Priority: -- → P3
Target Milestone: --- → Future

Comment 6

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

Comment 7

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

Comment 8

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

Comment 9

15 years ago
*** Bug 191765 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 10

15 years ago
roc+moz:
Any interest in this bug ?
I don't understand what this bug is about. Can you attach a testcase?
(Reporter)

Comment 12

15 years ago
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... :)
Why don't you implement alpha on PS by making a dithered mask?
(Reporter)

Comment 14

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

15 years ago
*** Bug 202795 has been marked as a duplicate of this bug. ***
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.
Severity: enhancement → normal
Priority: P3 → P2
Summary: RFE: Blend transparent pixels to background color instead of "white" → Transparent image pixels print white instead of background color of parent element
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.
(Reporter)

Comment 18

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

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

14 years ago
Created attachment 128335 [details]
Shows Mozilla's lack of transparency support when printed

Comment 21

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

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

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

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

Comment 25

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

Comment 26

13 years ago
OS -> All
OS: Linux → All

Comment 27

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

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

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

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

fwiw this also impacts Google Maps.

Comment 32

13 years ago
-> default owner
Assignee: dcone → printing
QA Contact: sujay

Comment 33

12 years ago
*** Bug 294165 has been marked as a duplicate of this bug. ***
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.
Component: Printing → GFX
OS: All → Linux
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...
Assignee: printing → roc
Status: NEW → ASSIGNED
Attachment #191160 - Flags: superreview?(caillon)
Attachment #191160 - Flags: review?(kherron+mozilla)
Blocks: 297977

Comment 36

12 years ago
(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. 
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 :-)
Attachment #191160 - Attachment is obsolete: true
Attachment #191172 - Flags: superreview?(caillon)
Attachment #191172 - Flags: review?(kherron+mozilla)
Attachment #191160 - Flags: superreview?(caillon)
Attachment #191160 - Flags: review?(kherron+mozilla)

Comment 38

12 years ago
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.
Attachment #191172 - Flags: review?(kherron+mozilla) → review+
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.
Attachment #191172 - Flags: superreview?(caillon) → superreview?(tor)

Comment 40

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

Updated

12 years ago
Blocks: 282434
is this related to bug 191099?
Created attachment 197506 [details] [diff] [review]
fix #3

As above, with nits commented and a more conservative approach to setting black
pixels to white.
Attachment #191172 - Attachment is obsolete: true
Attachment #197506 - Flags: superreview?(tor)
Attachment #197506 - Flags: review+

Comment 45

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

Looks like you attached the wrong patch.
Created attachment 197922 [details] [diff] [review]
real fix #3
Attachment #197506 - Attachment is obsolete: true
Attachment #197922 - Flags: superreview?(tor)
Attachment #197922 - Flags: review?(tor)
Attachment #197506 - Flags: superreview?(tor)
Comment on attachment 197922 [details] [diff] [review]
real fix #3

carrying forward kherron's r+
Attachment #197922 - Flags: review?(tor) → review+

Comment 48

12 years ago
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
Attachment #197922 - Flags: superreview?(tor) → superreview+
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.
Attachment #197922 - Flags: approval1.8b5?
Attachment #191172 - Flags: superreview?(tor)
I'm going to be offline for a few days. If this gets approved, someone please
check it in for me.

Comment 51

12 years ago
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?
checked into trunk.

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

Updated

12 years ago
Attachment #197922 - Flags: approval1.8b5? → approval1.8b5+

Comment 53

12 years ago
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.
Attachment #197922 - Flags: approval1.8b5+ → approval1.8b5-
Attachment #197922 - Flags: approval1.8rc1?

Comment 54

12 years ago
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.
Nope. Too much work for branch, and on trunk we'll have some kind of solution
for transparent compositing via the cairo PS backend.
Is there a bug # for real support of alpha when printing?
I don't know of one.

Comment 58

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

too late for non-critical changes of this size.
Attachment #197922 - Flags: approval1.8rc1? → approval1.8rc1-

Comment 59

12 years ago
(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. 
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 60

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

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

Comment 62

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

9 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.
Product: Core → Core Graveyard

Updated

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