using 8/24 build of netscape on windows 1) launch netscape 2) open attachment 3 [details] [diff] [review]) print the output is a dark rectangle with white lines. should look like what it appears in the browser.

what happens here is.. when text is printing out a color.. and its a light color, the code automatically darkens the color, this was to address the bug when a light color is printed out on a dark background.. and that background does not get printed. Those lines.. are the underline.. and are supposed to be white. So..even though this looks like a bug.. its doing what it supposed to do because the table does print that background, but the text is being lightened. The question then becomes how to handle this. I am gonna change the title of this bug to .. properly handle backgrounds when we print, and put all these issue in this bug.

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

I've added a nicer example of why it is important to print background images at this URL: http://www.cee.hw.ac.uk/~jbw/background-image-example/index.xml This is like my first example (a comment on bug 23146) which was at: http://www.cee.hw.ac.uk/~jbw/background-image-example/ Both examples show how to depict XML element trees. Both of them rely on background images to make sure the pieces that make up the lines of the tree are the right length. If the background images are not printed, then the printed version will lose a lot of the meaning.

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

There are some of the major site on the internet involved in this bug for example http://sportsillustrated.cnn.com

I think there are two issues here. The sportsillustrated.cnn.com page in particular prints on 4.x. And incidentally gets different behaviors based on using PCL or PS on Windows. The issue here has to do with what gets printed first. If you print white text and then put the background over it, you only get the background when you print. If you put the text over the background, usually the printer is smart enough to get things right.

Rod added an option to the PrintOptions object which allows the background to be printed with the default set to NOT print the background. However, there isn't any UI for yet. CC'ing Rod

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

> Rod added an option to the PrintOptions object which allows > the background to be printed with the default set to NOT ok but i read at http://lxr.mozilla.org/seamonkey/source/gfx/src/nsPrintOptionsImpl.cpp#76 76 // There are currently NOT supported ... 81 //const char kPrintBackgrounds[] = "print.print_backgrounds"; does it mean that for now we must recompile the lizard in order to test this background printing feature ?

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

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

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

Added keywords edt094 and topembed because edt094,topembed bug was marked as dup of this bug. Don: Please verify all dup's are fixed when you fix this bug.

Retested on 11_14_22_0.9.4ec. Remains a bug - using original testcase, output is a dark rectangle with white lines

Since backgrounds will be turned off for tables.. this is no longer a topembed. The bug for turning backgrounds off is 111953.. which will take care of this issue for the embedding project.

per comment above adding - to edt0.9.4 keyword

Patch to generate backgrounds for printing and print preview. This wont work right away because all backgrounds are currently turned off for printing, but this will work for print preview.

Comment on attachment 59578 [details] [diff] [review] patch so backgrounds will now work for the printing. Leak: GetStyleContext will addref the parentContext, so youhave to use a COMPtr or NS_RELEASE it. Nit: LoadBackGround is a bad name, as the backgroudn is not actually loaded, the background struct is simply fetched and cached. If you do choose to keep the name, please change the 'G' to 'g' :) Fix the leak and possibly the nit, and sr=attinasi

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

talked about a few changes, r=rods

Comment on attachment 59738 [details] [diff] [review] Patch with changes suggested by rods sr=attinasi - still

This patch is for the PresContext, and the nsCSSRender'er will use that boolean to see whether the background should be printed or not. The PrintContext and PrintPreview context will set this value to the settings in the nsIPrintSettings object. This is an easier way to communicate this setting that getting the print services each time the background is painted.

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

Comment on attachment 61131 [details] [diff] [review] Patch for finding out if the background should be printed. Can you use a PRPackedBool instead of a PRBool in the nsPResContext? Also, virtual functions cannot be inlined so there is no sense making GetBackgroundDraw and SetBackgroundDraw inline. sr=attinasi, assuming you check out my comments.

Comment on attachment 61131 [details] [diff] [review] Patch for finding out if the background should be printed. r=peterl

Backgrounds now us the nsPresContext to determine if the background is painted or not. The only thing left to do is get the printoptions to set the varible for printing the background. The color of the text needs to be update when that happens.

There is a routine in nsCSSRendering called TransformColor(), this routine needs to know if the background is being printed or not before it changes color. When that is finished.. this bug will be closed. Bug 79477 was the bug that changed font color for printing.

see http://bugzilla.mozilla.org/show_bug.cgi?id=113789#c4 this doesn't build for me either...same output

Build terminates like mentioned for andred and diego (from IRC) and myself Only common denominator i found is that we use optimize=O2 or higher. Compilers vary: gcc 2.96-85, gcc 2.95.4, gcc 2.95.4-pre

What exactly are you sayin.. I dont understand why you are posting that info here? The tinderbox builds fine for all platforms with this patch.

Which is exactly the reason why we think it is an optimization issue. There are several of us that see this compile failure, and all of use use -O2 or higher optimization level. As far as I know, tinderboxes doesn't.

I am seeing that failure also and bug 53486 (Default linux MOZ_OPTIMIZE_FLAG is -0 !!) has 0.9.8 as target milestone, so this is not a future issue, it will block a bug that is targetted for the next milestone. Please build optimized and see for yourself. I use --enable-optimize="-O4 -finline -fno-omit-frame-pointer -march=k6 -mcpu=k6". After backing out the changes as pointed out by rkaa my tree compiled without problems.

I just built a -O1 build and it still failed at the same spot. diego is now building a non-optimized build to see if that works.

My build failed using the following mozconfig # ac_add_options --enable-optimize="-O4 -finline -fno-omit-frame-pointer -march=k6 -mcpu=k6" ac_add_options --enable-crypto ac_add_options --disable-debug ac_add_options --disable-dtd-debug ac_add_options --disable-jsd ac_add_options --disable-ldap ac_add_options --disable-xprint ac_add_options --disable-logging ac_add_options --disable-mailnews ac_add_options --disable-tests ac_add_options --disable-bidi ac_add_options --disable-accessibility What do you other guys use? Maybe we can narrow it down.. My system is Debian testing, gcc 2.95.4, kernel 2.4.16 FWIW.

This ~/.mozconfig fails, but also if I change optimize to -O1 or leave it out altogether. Could the cause be some other common thing between diego, rkaa and my .mozconfig, like --disable-bidi or --disable-dtd-debug?

I have spun off bug 114957 on the build failures and assigned it to you, dcone, I hope you don't mind.

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

Marking nsbeta1+. Backgrounds need to be conditionally printed based on the page-setup dialog for both print-preview and printing.

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

Marking topembed+

Here are some sites i believe to be example of this bug: d-n-e.com www.puma.com www.undergear.com

This patch does a few things. 1.) Fixes the problem that the background for printing was not being captured. 2.) Adds background image and color booleans for printing. 3.) Fixes how the Paintbackground is called. Now has a boolean to use the printsetings or not. This keeps the elements that use backgrounds for special purposes from breaking. (radio buttons, scroll bars). 4.) Hooks up the options to the print settings dialog.

Change the items we talked about and r=rods

Comment on attachment 69306 [details] [diff] [review] Patch to implement background images and color for printing. tab probs: + PRPackedBool mDrawImageBackground; + PRPackedBool mDrawColorBackground; Please remove the comment part of this: + if ( (frameType == nsLayoutAtoms::pageContentFrame)/* || + (frameType == nsLayoutAtoms::pageFrame) */){ otherwise, looks good. sr=attinasi

This patch also adds in capablity to that if the backgrounds are being printed.. the text will not be darkened. If the backgrounds are not being printed.. then the text can be darkened if it is to light.

Comment on attachment 69528 [details] [diff] [review] new patch.. with cosmetic fixes. Please comment the part about canLightenColor, and make it an inline function since you call it three times. sr=attinasi

Marc's comments.. and I changed name to CanDarken()..

r=rods

fixed.

The patch for nsTextFrame.cpp does something weird with canDarkenColor. When isPaginated is false, an uninitialized PRBool will be passed to SetColor!

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

>Additional Comment #54 From Aleksey Nogin 2002-02-15 10:56 ------- > >The patch for nsTextFrame.cpp does something weird with canDarkenColor. When >isPaginated is false, an uninitialized PRBool will be passed to SetColor! That's right. I just spent time chasing a non-existing bug, until I traced to the fact that the color set in the rendering context wasn't the color in the style context, and discovered that it was due to this uninitialized variable -- and was not due to something in the style system. I made a fixup patch.

Left-over was checked-in.

I had a bug on this (122996).. complete with patch... thanks for the fix, but next time.. get and r and sr.. and I wont redo..that patch. Dont get me wrong.. I do appreciate it.. but imagine my surpise when I found that was already in there. Yes... I should have commented in here.. but I was tracking with that other bug. Anyway.. good work..next time can you request a review.. and sr before you do that. Thanks

125795 is the bug that tracked this.. not 122996.

I commented here for notification. Unfortunately, by that time, it had already eaten two days of my Mozilla hacking time, trying all sort voodoos in hunting an elusive bug elsewhere in the system following the simple left-over (ah, two days of hunting, it wasn't that simple...). I carried the earlier r/sr forward on the trivial fixup since there were no mention of the action that was going on in the other bug, and comment #54 from Aleksey Nogin 2002-02-15 with a REOPEN seemed to have been ignored. Next time I might not bother too.

ok verified on 2/20 trunk build on windows... everyone, if you can verify your DUPS to thsi bug and test it out. Make sure you go into File | Page Setup first and enable Background image first though. thanks. marking verified, if anyone finds a DUP that does not work, then REOPEN just that DUP....

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