12037 - [PRINTING TRANS GIF] Transparent backgrounds are printed as black.

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P3)

Description

[Chris Petersen]

Build: Apprunner
Version: 1999081608
Platform: All
Expected results: The directory that contains color icon should be printed as
greyscale.

What I got: The document icons are print as black/white on Windows. The Mac
prints no icons at all.

Steps to reproduce:

1) Type in the url:http://slip/projects/marvin/simple/
2) The directory should be displayed in the window. Notice that the document
icons of the files are in color.
3) Print the document.
4) Under Windows, The printout contains black/white icons instead of greyscale
icons. The mac version prints no icons on the page.

Comment 1

[Paul MacQuiddy]

Sorry for the spam, changing QA contact on printing bugs to our new printing
tester, Shrirang!

Comment 2

[dcone (gone)]

It seems that my test actually has inverted icons printed.

Comment 3

[rickg]

Moving to m13 -- have a nice day.

Comment 4

[dcone (gone)]

This is because the transparent GIF's print differently on differnt printers.

*** This bug has been marked as a duplicate of 21380 ***

Comment 5

[dcone (gone)]

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

Comment 6

[Asa Dotzler [:asa]]

Running in circles here.  This needs to be re-opened and 21380 need to be 
verified duplicate of this. I'm going with first reported inertia on this one.

Comment 7

[dcone (gone)]

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

Comment 8

[pnunn]

D:
Are we just printing the mask, ie the wrong buffer?
-p

Comment 9

[leger]

Putting on PDT- radar for beta1.  Will relnote for beta1.

Comment 10

[shrirang khanzode]

cc: sfraser

Comment 11

[Simon Fraser [no longer active]]

I checked in changes (to the trunk) so that transparent images print properly, on 
Mac. The changes are in nsImageMac.cpp

Comment 12

[shrirang khanzode]

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

Comment 13

[dcone (gone)]

This should be fixed. I put in a fix, and printing works much better.  I had to 
update printer drivers also for the Network printers, since tranparency does 
depend on the Printer Drivers supporting this.

Comment 14

[shrirang khanzode]

I still see images print with a black background with build (2000042109). zach ?

Comment 15

[R.K.Aa.]

Gif's printing in black also reported in bug 40821
url: http://www.ecst.csuchico.edu/~beej/guide/net/

Comment 16

[shrirang khanzode]

reopening...per comment from R.K.Aa.

Comment 17

[shrirang khanzode]

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

Comment 18

[dcone (gone)]

This bug has been marked future because we have determined that it is not 
critical for netscape 6.0.  If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.

Comment 19

[Simon Fraser [no longer active]]

I should have fixed transparent GIFs on Mac to print with a white background 
instead of random pixels. Shrir, can you test? I can't remember if there is 
another bug on that.

Comment 20

[shrirang khanzode]

yes, trans gif's are now printing with a white background on mac(2000091509m18). 
Windows and linux are still printing as originally reported in this bug. Simon 
do you want me to log a seperate one for mac ?

Comment 21

[Shawn Neumann]

This is a glaring bug.  On older sites where transparent images are used to for
spacing, the results look really bad.  Any chance of getting a fix in for this
for NS6?  I would be uncomfortable with this being the final release printing
performance.

Comment 22

[shrirang khanzode]

keyword: rtm

Comment 23

[Kevin McCluskey (gone)]

Marking rtm-. Not enough time to solve this problem. Will have to look at this
post RTM.

Comment 24

[Gervase Markham [:gerv]]

It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note. If anyone feels it does, can they please draft one and then 
nominate with the relnote-user or relnote-rtm strings in the Status Whiteboard.

Thanks :-)

Gerv

Comment 25

[Jack Dignan]

This bug is extremely critical to our products. Equations are usually created 
as transparent GIFs for display in web pages. Putting a white background in the 
equation is not an option, as we want to pick up any background color in the 
user's document. Here is a page on our website that contains 2 transparent 
GIFs, (albeit low-resolution):

http://www.mathtype.com/support/TSN/TSN50.stm

Please make this a high-priority item for the final release of Netscape 6.

Jack Dignan
Design Science, Inc.

Comment 26

[shrirang khanzode]

keyword:relnote-RTM

Comment 27

[R.K.Aa.]

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

Comment 28

[R.K.Aa.]

reporters comment in bug 61659:

Note this graphic prints okay with the Non postscript driver

Comment 29

[shrirang khanzode]

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

Comment 30

[R.K.Aa.]

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

Comment 31

[Chao Yu]

Attachment: Proposed tranparent image support for Postscript print sessions

Comment 32

[rusty.lynch]

Adding myself to the CC list

Comment 33

[shrirang khanzode]

spam : changing qa to sujay (new qa contact for Printing)

Comment 34

[R.K.Aa.]

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

Comment 35

[Tobias Burnus]

I dislike the 'Summery'. If I understand the newer comments correctly (and as I
have observed with my bug 68147) the problem is that the transparent background
is printed as black. The colours are ok and all images seem to print.
I therefore would suggest to change to summery. (And changing platform to all)

I think this is a must fix for mozilla1.0.

Since usually white is regarded as colour of the paper, it would be ok to  print
the transparent parts as white (instead of not printing those pixels which is
probably better?).

Comment 36

[rusty.lynch]

Yea, the description is not accurate anymore, but I'm not so sure that this is 
a bug on all platforms.  I know that any platform using PostScript will have 
this problem, but I didn't think that Windows and Mac had a problem with 
transparent GIFs.  

Can anywone confirm?

Comment 37

[Dawn Endico]

this is broken for me on linux using both postscript and the native 
hp4 drivers on redhat 6.2. Asa's mac printed the background as white
(better than black, but suboptimal because the actual background was gray)
and his windows machine printed the background as black (but its set up
as postscript). I think OS should stay at "all".

updated the subject.

Comment 38

[rusty.lynch]

Before I had made a bad assumption that the postscript object was only used on 
OS's that do not provide a direct printing context type of device. I see now 
that this is not the case and have further confirmation from Dennis Lundberg 
[[e-mail]] (who is having some problems with his bugzilla 
account) that Windows 2000 on build 2001021508 exibits this bug when printing 
to a PostScript printer driver, but not to a PCL printer driver.

Comment 39

[P. Damian Cugley]

This problem is not restricted to GIF images: I have this problem with printing 
a document with transparent PNGs on our HP LaserJet (PostScript driver) but not 
the HP DeskJet (which doesn't say it's PostScript, so I assume is PCL).  Since 
my diagrams are black lines on transparent ground, the result is large squares 
of solid black...

Windows NT 4 SP6a, Mozilla 0.8 build 2001021508

Comment 40

[Jack Dignan]

transparent GIFs are still printing as black boxes on Mozilla 0.8.1 

Windows NT4SP6

Comment 41

[R.K.Aa.]

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

Comment 42

[R.K.Aa.]

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

Comment 43

[Kevin McCluskey (gone)]

Don, I think the problem is that for printing we need to invert the mask before
ANDING it with the destination. In addition we would need to OR the source
bitmap with the inverse of the destination.

The current sequence is:

1. Create a mask with 0xFFFFFF pixels mapping to the non-transparent pixels in
the source image and x000000 pixels mapping to transparent.
2. AND the mask with the destination.
3. OR the source image into the hole created by step 2.

The problem with this is that if the printer does not support the AND raster
operation then we are rendering the mask's transparent pixels as black pixels.
If we have it render the inverse of the mask then the transparent pixels will be
rendered as white pixels if the AND operation is NOT supported. 

1. Invert the mask
2. AND the mask with the destination 
3. OR the source image with the INVERTED destination. (I think the operation
DSTINVERT on WIN32 does this.)

Comment 44

[Kevin McCluskey (gone)]

Disregard my last comment. On WIN32, I think all we need to do is use
GetDeviceCaps(RC_NONE) to determine if the device supports raster operations. If
it doesn't support them then we should either:

Use the mask to composite the source image into an offscreen buffer then blit
the offscreen to the destination.

or

Copy the source image to the destination with any transparent pixels filled with
white.

Comment 45

[Jacek Piskozub]

10 dup bugs according to http://bugzilla.mozilla.org/duplicates.cgi. Marking
mostfreq.

Comment 46

[Boris Zbarsky [:bzbarsky]]

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

Comment 47

[sujay]

www.aol.com is chocked full of transparent GIFS, this printing
this page yields so many black GIFS..

we should get this fix in ASAP.

Comment 48

[Oliver Jones]

I too also have this problem.  It seems to be something so fundamental to 
printing that it should be fixed ASAP.

Platform: Moz 0.9.2, RedHat Linux 6.2

Comment 49

[Dainis Jonitis]

Just my 2cents from printer driver developer viewpoint:

As it was said before that depends whether printer supports generic ROP's or not.
For example PostScript printers do not have concept of drawing surface at all so
they cant combine output with already drawn content (only overpaint). Thus it
will never work on any PostScript printer.

PCL printers set required ROP with PCL Logical Operation (*l#O) command. The
problem is that this command is not defined in base PCL5 specification but only
in PCL5C (additions for color printing). It is supported not only with color
printers but with recent b/w printers, too.

These HP printers does not support this command: HP LaserJet III, IIID, IIISi,
IIIP, 4, 4M, 4Si, 4SiMx, 4L
Printers that correctly handle Logical Operation: HP LaserJet 4ML, 4P, 4MP, 4PJ,
4 Plus, 4M Plus, 4V, 4MV, all Hewlett-Packard color laser printers and ink
printers. 


The problem is even larger with 8bit alpha blended PNG images. For blending
Mozilla wants to know what was already drawn (bitblt from device to memory
bitmap). Printer drivers do not support this kind of bitblt and return error (at
least Win32 and OS/2 drivers do this way). 

I think that for printer output during page rendering all drawing primitives
must be sent to the printer DC (RenderingContext) AND some memory drawing
surface (kinda carbon copy). If there are transparent PNG images or printer does
not support ROP's then output is sent to printer in one pass as large bitmap.
BTW this one pass approach significantly reduces size of transfered image. 

Comment 50

[Chris Lyon]

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

Comment 51

[R.K.Aa.]

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

Comment 52

[Matthias Versen [:Matti]]

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

Comment 53

[siemsen]

I just encountered this bug, found this entry and read the thread.
I'd just like to ask the poster who suggested that this'll never work
to PostScript printers:  It works fine in Netscape 4.76.  Can't the
developers emulate what is done in 4.76?

Comment 54

[dcone (gone)]

I am working on this bug currently,first on the windows platform.  The 
postscript platform might be more of a challenge because I am not sure if 
postscript supports transparency.  This problem 6.x is having.. we dont 
composite our page.. so we rely on the device to support all the raster 
operations.  I am not sure what 4.x did, but I am guessing the composited there 
output.  If anyone knows what 4.x did, please post it in this bug.

Comment 55

[Simon Fraser [no longer active]]

The 4.x (or "Mozilla Classic") code is available in the tree, so you can go and 
look for it.

Comment 56

[dcone (gone)]

I just did tests with W2k and my 4500 HP laserprinter, the transperancy works 
just fine.  This problem is bad because it is dependent on the 
printer/driver/platform.. as to if it will work.  Some platforms work, some 
print an ugly black mask.  One solution would have been to make the black mask 
white so it would look better, but then that would break the systems that have a 
printer that does support these raster operations.  Another solution would be to 
always composite this area when we print.. I think thats the only solution to 
get this to work all the time.

Comment 57

[Roland Mainz]

dcone:
Is there a way to query the required info (e.g. whether (alpha) mask support is
present or not) from PPDs ?

Comment 58

[Stuart Parmenter]

Making the empty image bits white will look silly on pages with dark backgrounds 
where its dark on white...  I don't think this is a good solution.

Perhaps we should composite, however that kinda sucks too.

Comment 59

[dcone (gone)]

I checked with what explorer does, they do not support tranparency with there 
printouts.. looks like they punted, but they do use white where the transparency 
is.  I think compositing will be really bad because of the resolution isssue.. 
size, etc.  I think what should happen.. I will do the white background, but 
will put in an option (at a later date) that will allow the user to do these 
raster operations if the printer supports it.  Also.. windows printers do not 
tell if these raster operations are supported for the printer.. only if the 
printer is a raster type so the user will have to make that decision.  Seems 
Netscape also does this white background thing.  

Comment 60

[Dainis Jonitis]

  Probably you misunderstood about that PostScript problem. I did not meant that
there are problems in nsPostScriptObj.cpp which manually generates stream in
PostScript language. 
  What I meant is that if you print from Windows (or OS/2 or Mac) on the
PostScript printer by using nsRenderingContextWin.cpp functions which map to the
GDI function calls then PostScript driver is unable to interpret the ROP3
SRC_AND for image mask and it tries it's best and replaces ROP with simple copy
(ROP3 = 0xCC = Source only). That's how these black areas appear.

  I agree that replacing transparent areas with white color is BAD idea! Of
course you can do it as temporary solution. In that case you must provide that
printed page does not have background images or fill color.


  Why you are against compositing page in memory? All necessary GFX functions
are there to do that. There are no any issues with resolution you mentioned. The
only problem is that it takes a lot of memory. For example A4 (aprox. 11 x 8
inches) page at 1200 DPI printer will take 11*8*1200*1200*3 = 380 Mb. This is
amount of memory Mozilla needs to print one page in worst situation (large
resoulution, entire page, truecolor). Printer driver compresses that chunk to
much smaller one and only then sends it to the printer.
  Compositing is necessary only for documents that contain transparent or
alpha-blended images. You can't apply it to the separate page or even part of
page, because then problems with fonts could arise - printer device fonts could
look slightly different than system fonts.

The other bonuses of compositing are that it must be done only once in platform
independent layer. And most importantly it will work:
 1. on all printers
 2. with alpha-blended images. (I would love that feature)

It's just a question of time when it should be implemented.

Comment 61

[dcone (gone)]

yes all the GDI functions are there to do that, but that IS the resolution 
problem.  Creation of a large offscreen to support the resolution of the 
printer your going to.  So for a 300dpi.. not to bad, 4x, but for 600dpi or 
2000dpi that is a huge offscreen.. which is a resolution problem.  You could 
band and you could.. and could...  but these are pricy solutions.. we would 
basically be writing our own printer drivers and just copy'ing the bitmap out.  
Currently I think the solution would be to do what 4.x and IE do, use white.  
The second phase would be to have the option in that the mask would be used like 
it is currently for printers that support it. As the product stands now, the 
raster operations work great on my 4500 laserwriter and 1 out of the two 
Laserwriters at work,   no bugs there. Leave those raster operations to the 
printers that support it which should be more and more. Microsoft has a new GDI 
transparent bitmap bitblit so I am sure more printers will have to support these 
operations.  I dont think us doing our own composition is ever a good idea 
because its alot of memory and code to support a feature used maybee 5% of the 
time.. if that.  

Comment 62

[dcone (gone)]

Attachment: Fix to draw white background for transparency.

Comment 63

[Peter Lubczynski]

r=peterl

Comment 64

[Marc Attinasi]

sr=attinasi

Comment 65

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is it true that canRaster == DT_RASPRINTER only for some printers, and never for
a screen?  Should Compostite be Composite, or something else?

Comment 66

[mgueury]

Attachment: Simplifed testcase

Comment 67

[mgueury]

Ignore my last update. I wished to post in another bug.

Comment 68

[dcone (gone)]

That is exactly how the documentation said to use this constant.. it will never 
happen for a screen.  I used the online documentation as well as programming 
windows, Charles Petzold for reference.

Comment 69

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

OK, a=dbaron on behalf of drivers if you fix the spelling of Compostite to
whatever it should have been (Composite?).

Comment 70

[sujay]

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

Comment 71

[dcone (gone)]

Windows fix checked into the trunk and 9.2 branch.

Comment 72

[dcone (gone)]

I checked in the windows fix for this.. so I am taking off the topembed tag.  
This is just a Mac issue now.. and I will fix that next.

Comment 73

[MichaelWright9]

Why remove the topembed tag? This is still an issue for the GTK embed. The
attached patch only fixes windows.

Comment 74

[Kevin McCluskey (gone)]

Set milestone to mozilla0.9.5 added nsbranch keyword

Comment 75

[Asa Dotzler [:asa]]

0.9.5 is out the door. bumping TM up by one.

Comment 76

[sujay]

Also on Linux this is still not fixed...

I see a long vertical strip on the left side when printing
http://www.netscape.com

That strip is supposed to be a white trans image/gif(see the HTML) and
when you print that page using Win, you don't get a black
strip. So it is inly fixed on windows.

So that leads me to believe that this bug is not fixed
for linux. 

Setting platform/OS to ALL.

Comment 77

[Nick Pietraniec]

I also just encountered this problem at www.asciitable.com trying to print the
ascii table on that page.  It's a transparent GIF, and the background prints as
black.  I right-clicked the image and went to "view image" and then tried to
print via file -> print.

OS:  Mandrake Linux 8.0
Moz. Ver: 20011012 
Printing to a Samba shared HP 812c
Driver:  HP DeskJet 812C, Foomatic + DJ8xx (HP-developed driver)

Comment 78

[Dainis Jonitis]

Attachment: Changes to nsViewManager::Display ()

Comment 79

[Dainis Jonitis]

Posted changes to nsViewManager::Display () to do compositing. This is just an
example how code could work in cross-platform way to fix black background
problem and printing of alpha blended images.

There should be some logic which determines whether page could be printed
directly to printer or it should be prepared in memory and then sent to printer
as one large bitmap. It should check whether there are transparent images in
document and what are user preferences for compositing if they are.

The other field for improvement to decrease memory usage is rendering the page in
limited resolution - 300 DPI should be enough. Then offscreen drawing surface
could be scaled to print on the entire page.

I made necessary changes (win32 and OS/2) to
nsIRenderingContext::CopyOffscreenBits () to accept both source and destination
as nsRect rectangles and thus support scaling.
The largest problem is to force nsViewManager::RenderViews to render page with
specified scaling factor. There is instrument to do that by adding scale factor
to transformation matrix in RenderingContext, but it is not always correctly
used. For example images and text dimensons do not scale right. The
nsFontMetrics read the scaling factor (twips to pixels) directly from
nsDeviceContext and thus ignores the scale factor which is specified in
nsRenderingContext.
I see at least two ways how to force rendering to be done at resolution which
differs from real device resolution:

1. Fix all places in nsRenderingContext to take into account the scaling factor.
Somehow change nsFontMetrics to use the scaling factor fromnsRenderingContext.

2. Make changes to nsDeviceContext to be able to specify desired resolution of
device. We will report smaller dimensions for caller for drawing surface. All
functions which get scale (AppUnitsToDevUnits etc.) will take this DPI
diffeerence into account, too.

I can try to implement this functionality. BTW this should automagically give
possibility to implement print preview!!!
I need to know which approach is better from your point of view. If someone in
Netscape / Mozilla is already working on or at least was pondering how to make
it I would like to hear back from them.

Comment 80

[Christopher Blizzard (:blizzard)]

OK, can someone let drivers know what's going on with this bug?

I'm sick of paying for print cartridges.  This bug is honestly costing me real
money.

Comment 81

[Nick Pietraniec]

lol...  Don't print 1024x768 gifs.

here...

http://www.engin.umd.umich.edu/~npietran/images/place.gif

1x1 transparent gif

Comment 82

[Diego Biurrun]

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

Comment 83

[chris hofmann]

dcone is on sabatical.  rod/kevin, can you take a look at this?

Comment 84

[Christopher Blizzard (:blizzard)]

This is listed as a 0.9.6 bug so it would be nice to see a go/no-go on whether
this is even going to be possible.  It might be a simple fix, it might not.

Comment 85

[dcone (gone)]

I am back from sabatical. 
I dont think will are going to composite for a cross platform solution, this 
would require to much memory since you would need an offscreen buffer 4 times 
the size of the printer resolution at least.  The fix for windows needs to be 
implemented on Mac and Linux.. then this will be closed.

Comment 86

[Dainis Jonitis]

IMHO 24 Mb or 32 Mb (depending whether system uses 3 or 4 bytes per RGB pixel)
is NOT such a terrible amount of memory per Letter page (11x8 inches) in 300
DPI. The idea is not to use larger resolutions than 300 DPI even if the printer
reports that it can do 600 or 2000 DPI. Isn't the mAltDC (for print preview)
from nsDeviceContext.cpp the right instrument to do the rendering in any
resolution which we ask for?

Comment 87

[Hervé]

this bug worries me a lot. i would like to use Gecko under Linux to automate
printing web pages for customers (don't ask me why...), so printing transparent
GIF backgrounds in white is not a solution, because most of the sites have
backgrounds images or colors. in this case Gecko is out for my project.

thus, Dainis Jonitis, i'm interested in your solution and i have a few questions :
does your patch compile with current Mozilla sources ?
do you know if it's compatible with printing Framesets and background images ?

i can mail Dainis privately if other bug contributors consider it's not
appropriate to have such a discussion on this report. anyway, i just wanted to
warn that printing backgrounds in white is not always a solution...

Comment 88

[dcone (gone)]

I agree that white backgrounds is a not an optimum solution, but it does take 
care of most the cases.  Using 32 meg.. to render offscreen is probably not a 
big deal for some.. but there are alot of users who can not afford to use or 
have that much extra memory.  Also.. using a maxumum resolution of 300 dpi is 
not practical with all the Inkjet printers.. or 600 dpi 1200 dpi and 2400 dpi 
laser writers.  I payed alot for my laserwriter, I would not like that 300 DPI 
solution just so I could print out some.. if any transparencies.  Also companies  
like FedEx, UPS could no longer print there BarCodes at that resolution.  They 
use very large images which are sent to the printers to scale for them and give 
them very high resolutions. Maybee a solution might be.. a preference to use an 
offscreen.. warning of the DPI shortfall, this is only needed for 
transparencies, or extreme memory that might be used.. something like that.  But 
I really have a problem doing our own printer rasterization just so a small 
number of transparent things can be rendered.  Its better to solve a problem for 
95% cases.. than to solve for the 5% case.  My point.. I believe there is a big 
cost for doing offscreen rasterization.  

Comment 89

[Roland Mainz]

I agree with dcone.

The best thing to do is to get a printer which supports alpha-masking or
transparency (via PostScript Level 3 or PCL5) ...

Comment 90

[t.schnier]

For many linux users, the important thing will be that ghostscript does it
correctly, because printing to inkjet printers relies on it.

I've tested the recent versions of ghostscript in Debian unstable, both
gs 6.51 and gs-aladding 6.50; for my test case (see bug 85628) both of them
still show problems with the transparent gifs. 

I am not entirely sure about GS's behaviour: on the release documentation,
ghostscript is claimed to support level-3 features, but gs -h shows only
postscript level 1 and level 2. This might depend on how it is compiled. 

The best option seems to be to have a configuratio option to chose between
'force to white workaround' and 'rely on postscript level 3 features'


 

Comment 91

[Eric Vaandering (no email)]

I don't know if this is helpful, but when printing from acroread under linux
there is the option to use Level 1, Level 2, or Level 3 postscript. So, its not
completely without precedent to have such a work-around option.

Eric

Comment 92

[Eric George]

FWIW, Konqueror prints these pages correctly.  You might look at how they do it.
My test case is: http://www.engr.sjsu.edu/~knapp/HCIRODPR/PR_Mahal/M_metric.htm

Comment 93

[tor]

Force-to-white print transparency has been checked in as part of bug 127430.

Comment 94

[Kevin McCluskey (gone)]

Marking topembed-. The issue has been resolved for WIN32. Remaining problem is
on Linux, Mac.

Comment 95

[Michael Baffoni]

I'm still seeing this bug in Build 2002030403, Win2k.  Is the patch not in the
standard nightlies yet?

Comment 96

[sujay]

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

Comment 97

[Asa Dotzler [:asa]]

nominating for embedding and nsbeta. The comments suggest that this is fixed on
windows but it isn't. I'm still seeing large black areas for transparent gifs.
Print the image at
http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif and see for
yourself. This bug actually makes Mozilla/Netscape considerably more expensive
to use than the alternatives and will affect enterprise and home users where it
matters, in their pocketbooks.

Comment 98

[Kevin McCluskey (gone)]

WFM: When I print
http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif using
2002032203 build on WinXP on a HP LaserJet4. It prints the transparent area as
white, no black areas to be found.

Comment 99

[Asa Dotzler [:asa]]

032503 mozilla win32 build on win2K printing to LaserJet 4 prints black for the
transparet background for me. 

Comment 100

[Kevin McCluskey (gone)]

Interesting... 3/25 cvs build on WinXP printing to LaserJet 4 prints white for
the transparent background for me.  Must be a printer driver specific issue on
WIN32.

Comment 101

[bobj]

Running the 3/25 build on W2K:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020325
Netscape6/6.2.1+ 

When I print http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif,
I get black background on 2 printers:
  HP LaserJet 5Si/5Si MX PS (lungfish on FLOTSAM)
  Lexmark Optra T614 PS3(sanma on FLOTSAM)

Comment 102

[Eugene Savitsky]

HP 1200, last drivers, Win XP, moz 2002032003. All looks fine.

Comment 103

[saari (gone)]

WFM on 0.9.9 macOS 9

Comment 104

[Shawn Neumann]

Using Win2k with Build 2002032603 printing on a HP5000N... Still printing all
transparent gifs with black background.

Comment 105

[Tim]

Works for me, build 2002031808 (a nightly--not a packaged version),
Debian/GNU/Linux, woody, CUPS version 1.1.14-3, HP DeskJet 842C.  (Sorry for the
spam.)

Comment 106

[Kevin McCluskey (gone)]

On WIN32 we no longer go into the CompositeBitsInMemory routine which creates an
offscreen with a white background because the transparent gif is always
optimized. Instead, we fall through and call PrintDDB which leaves the user at
the mercy of their printer driver in regards to supporting the mask raster
operation needed to do transparency. This regression was probably caused by the
check in which removed the duplicate copy of the image bits by optimizing the
images. (bug 104999)

nsImageWin.cpp
------------------
if (!IsOptimized() || nsnull==mHBitmap){ <==  The image is optimized so it  
                                              never goes to 
                                              CompositeBitsInMemory below
      PRBool  didComposite = PR_FALSE;
      rop = SRCCOPY;
      if (nsnull != mAlphaBits){
        if (1==mAlphaDepth){
          if(canRaster == DT_RASPRINTER){
            MONOBITMAPINFO  bmi(mAlphaWidth, mAlphaHeight);
                 CompositeBitsInMemory(TheHDC,aDX,aDY,
                       aDWidth,aDHeight,aSX,aSY,aSWidth,aSHeight,srcy,
                       mAlphaBits,&bmi,mImageBits,mBHead,mNumPaletteColors);

Comment 107

[Kevin McCluskey (gone)]

Attachment: Fix printing of transparent gif on WIN32 by compositing with white background when image is optimized

Comment 108

[Kevin McCluskey (gone)]

nsbeta1+ for WIN32 fix (Fixes recent regression which was preventing WIN32 from
printing transparent gifs correctly.)

Comment 109

[Kevin McCluskey (gone)]

Taking bug.

Comment 110

[Kevin McCluskey (gone)]

Attachment: Same as patch 77142 with additional code to cleanup the mImageBits after compositing offscreen to reduce memory usage

Comment 111

[Marc Attinasi]

Comment on attachment 77266 [details] [diff] [review]
Same as patch 77142 with additional code to cleanup the mImageBits after compositing offscreen to reduce memory usage 

sr=attinasi

Comment 112

[dcone (gone)]

Comment on attachment 77266 [details] [diff] [review]
Same as patch 77142 with additional code to cleanup the mImageBits after compositing offscreen to reduce memory usage 

r=dcone

Comment 113

[Kevin McCluskey (gone)]

adt: This patch is for WIN32 only. The symptom is that on a high percentage of
printers we will print black for transparent areas instead of white. top100
sites such as www.yahoo.com have transparent gif's which print with black
backgrounds on these printers. This regression was probably caused by the check
in which removed the duplicate copy of the image bits by optimizing the images.
(bug 104999). The patch is in WIN32 specific code, so it has only been tested on
WIN32. I have tested WINNT and WINXP printing several top100 sites.

Comment 114

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for checkin into 1.0.

Comment 115

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 77266 [details] [diff] [review]
Same as patch 77142 with additional code to cleanup the mImageBits after compositing offscreen to reduce memory usage 

a=[e-mail] for drivers

Comment 116

[Kevin McCluskey (gone)]

Attachment: small change to patch 77266

Same as patch 77266 except I removed the assert that mImageBits is not null and
I destroy the mImageBits only if mImageBits was created during printing. (This
is a little safer since we should not be deleting mImageBits unless it was
created for the purpose of printing)

Comment 117

[dcone (gone)]

Comment on attachment 78072 [details] [diff] [review]
small change to patch 77266

r=dcone

Comment 118

[Marc Attinasi]

Comment on attachment 78072 [details] [diff] [review]
small change to patch 77266

sr=attinasi

Comment 119

[Kevin McCluskey (gone)]

Fix for WIN32 checked in - attachment 78072 [details] [diff] [review]

Comment 120

[Kevin McCluskey (gone)]

Reassigning to dcone, marking nsbeta1-.

Comment 121

[Andrew Hagen]

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

Comment 122

[sujay]

verify bug 101618 when this bug is fixed.

Comment 123

[bobj]

> Fix for WIN32 checked in - attachment 78072 [details] [diff] [review]

Verified for me now:
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020409
Netscape6/6.2.1+ 

Successfully printed:
  http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif

on 2 printers:
  HP LaserJet 5Si/5Si MX PS (lungfish on FLOTSAM)
  Lexmark Optra T614 PS3(sanma on FLOTSAM)

Comment 124

[wazow]

AS for comment #123 given url (rose) also prints correcctly under Linux 
nighgtly build (2002040410) on HP 2100 (without the path i suppose:)

Comment 125

[dcone (gone)]

This is fixed for Windows.  I will create new bugs for Mac and Linux concerning
this issue.

Comment 126

[sujay]

verified in 4/15 trunk build.

Comment 127

[sujay]

sorry for the spam, forgot to mention here are the two new bugs
created for Mac and Linux if anyone wants to cc: themselves on those
bugs:

Mac = http://bugzilla.mozilla.org/show_bug.cgi?id=137114
Linux = http://bugzilla.mozilla.org/show_bug.cgi?id=137115

Comment 128

[Dawn Endico]

removing item for this bug from the release notes since the bug is marked
fixed. If this is in error, please make a note in the release notes bug for
the current milestone.

Comment 129

[rnorberg]

Transparent images are not printing correctly.
Can anyone please verify?

problem : transparent image covers background image.
    On webpage http://www.mozillazine.org/poll_results.html?id=660
    the background cloud and grass image (tile_gif.gif) does not show 
    through "mozillazine" (title.gif) or (blimp.gif).  

    On the www.microsoft.com page the transparent images 
    are not filled in with the correct background color.

mozilla build : 2003010304
OS : windows 2000
printer : lexmark optra m412
driver : pcl5 2.640, PostScript 30.740
Fails pcl5, ps, windows

Comment 130

[Arthur]

rnorberg: Seeing similar things with 1.2.1 on Linux, printing to PS-File. Please
open a new bug report after looking for duplicates. This one is fixed. Thanks.