Closed
Bug 141656
Opened 22 years ago
Closed 19 years ago
Transparent image pixels print white instead of background color of parent element
Categories
(Core Graveyard :: GFX, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: roland.mainz, Assigned: roc)
References
Details
Attachments
(2 files, 3 obsolete files)
29.72 KB,
application/zip
|
Details | |
10.55 KB,
patch
|
roc
:
review+
tor
:
superreview+
asa
:
approval1.8b5-
asa
:
approval1.8rc1-
|
Details | Diff | Splinter Review |
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•22 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•22 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... :)
Reporter | ||
Comment 4•22 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•22 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•22 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Comment 6•22 years ago
|
||
*** Bug 164222 has been marked as a duplicate of this bug. ***
Comment 7•22 years ago
|
||
*** Bug 184430 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
*** Bug 164289 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
*** Bug 191765 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 10•21 years ago
|
||
roc+moz: Any interest in this bug ?
Assignee | ||
Comment 11•21 years ago
|
||
I don't understand what this bug is about. Can you attach a testcase?
Reporter | ||
Comment 12•21 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... :)
Assignee | ||
Comment 13•21 years ago
|
||
Why don't you implement alpha on PS by making a dithered mask?
Reporter | ||
Comment 14•21 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•21 years ago
|
||
*** Bug 202795 has been marked as a duplicate of this bug. ***
Comment 16•21 years ago
|
||
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
Assignee | ||
Comment 17•21 years ago
|
||
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•21 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•21 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•21 years ago
|
||
Comment 21•21 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•21 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•21 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•21 years ago
|
||
*** Bug 224225 has been marked as a duplicate of this bug. ***
Comment 25•20 years ago
|
||
*** Bug 240030 has been marked as a duplicate of this bug. ***
Comment 27•20 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•20 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•20 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•20 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?
Comment 31•20 years ago
|
||
fwiw this also impacts Google Maps.
Comment 33•19 years ago
|
||
*** Bug 294165 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 34•19 years ago
|
||
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
Assignee | ||
Comment 35•19 years ago
|
||
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)
Comment 36•19 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.
Assignee | ||
Comment 37•19 years ago
|
||
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)
Assignee | ||
Updated•19 years ago
|
Attachment #191160 -
Flags: superreview?(caillon)
Attachment #191160 -
Flags: review?(kherron+mozilla)
Comment 38•19 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+
Assignee | ||
Comment 39•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Attachment #191172 -
Flags: superreview?(caillon) → superreview?(tor)
Comment 40•19 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.
Assignee | ||
Comment 41•19 years ago
|
||
(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?
Assignee | ||
Comment 42•19 years ago
|
||
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•19 years ago
|
||
is this related to bug 191099?
Assignee | ||
Comment 44•19 years ago
|
||
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•19 years ago
|
||
Comment on attachment 197506 [details] [diff] [review] fix #3 Looks like you attached the wrong patch.
Assignee | ||
Comment 46•19 years ago
|
||
Attachment #197506 -
Attachment is obsolete: true
Attachment #197922 -
Flags: superreview?(tor)
Attachment #197922 -
Flags: review?(tor)
Assignee | ||
Updated•19 years ago
|
Attachment #197506 -
Flags: superreview?(tor)
Assignee | ||
Comment 47•19 years ago
|
||
Comment on attachment 197922 [details] [diff] [review] real fix #3 carrying forward kherron's r+
Attachment #197922 -
Flags: review?(tor) → review+
Comment 48•19 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+
Assignee | ||
Comment 49•19 years ago
|
||
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?
Assignee | ||
Updated•19 years ago
|
Attachment #191172 -
Flags: superreview?(tor)
Assignee | ||
Comment 50•19 years ago
|
||
I'm going to be offline for a few days. If this gets approved, someone please check it in for me.
Comment 51•19 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?
Assignee | ||
Comment 52•19 years ago
|
||
checked into trunk. This only affects printing on Linux. Mac and Windows do not use this code.
Updated•19 years ago
|
Attachment #197922 -
Flags: approval1.8b5? → approval1.8b5+
Comment 53•19 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-
Assignee | ||
Updated•19 years ago
|
Attachment #197922 -
Flags: approval1.8rc1?
Comment 54•19 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.
Assignee | ||
Comment 55•19 years ago
|
||
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•19 years ago
|
||
Is there a bug # for real support of alpha when printing?
Assignee | ||
Comment 57•19 years ago
|
||
I don't know of one.
Comment 58•19 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•19 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.
Assignee | ||
Updated•19 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 60•18 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•17 years ago
|
||
This is blocking bug 282434. Someone please reopen and fix this bug.
Comment 62•17 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•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.
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•