From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS 5.7 sun4u; en-US; m16) Gecko/20000621 BuildID: 2000062115 When a floating image or other box is printed and reaches the end of the page, it is chopped and does not continue on the next page. Reproducible: Always Steps to Reproduce: 1. Fetch http://www.uio.no/~hbf/mbug2.html . 2. Print it - to file if you have ghostview. 3. Look at the results: 2nd circle and 2nd box are both too big for their page. (If they are not, adjust the margins so that they _are_ too big and try again.) Actual Results: Page 1 contains text + 1st circle + start of 2nd circle. Page 2 contains text + 1st DIV + start of 2nd DIV. (Each DIV has "DIV #n..." at the top and "...DIV #n" near the bottom.) Page 3 contains just the text "(eof.)" Expected Results: Either: 2nd circle is not printed on 1st page, but all of it is printed on 2nd page. If so, maybe the text it floats "around" is pushed down to 2nd page too, or maybe only the floating image is pushed down (if so it'll look like it's not floating). In any case, text from the next <br clear=all> will have to come after the image. or: 2nd circle starts on page 1 as before, and page 2 starts with the rest of 2nd circle. And so on for the rest. (the same URL also illustrates another (reported) bug.)

2000072420win32talkback. Printed to Postscript file using windows 2000 `HP Color LaserJet PS` driver. ran ps2pdf to view with acrobat. [confirming]

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.

I think potentially silent loss of information is fairly high-profile bug. Also, the number of print bugs are still annoying to the point where I have to keep another browser around in order to print things. I don't think that's the advice you want sysadmins to give their users. I suggest you temporarily insert a pref setting which removes printing features that work as poorly as this. E.g. it'd do the equivalent of this (which doesn't work but I trust you get the idea): <STYLE media=print><!-- * {float: none !important;} /* avoid this bug */ *[text-align=justify] {text-align: left (or auto) !important;} /* bug 40130 */ --></STYLE> For stuff like Bug 37685 (<pre> spacing doesn't work), maybe gross hacks like printing _everything_ in a fixed font would be easy enough to throw into this pref setting(s)? Just a loose thought.

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

I want this bug fixed. Also cc'ing attinasi, cause he says it might be his bug.

Reassigning to Marc.

I see this bug as a major drawback in using mozilla. I have to walk three floors to use a computer which prints theese kind of pages correctly. In my opinion it should be a high priority bug. For instance: http://www.stud.ifi.uio.no/~haavardw/mozillatest/cutoff.xml

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

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

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

So what're the odds we have someone around who knows a) why this is happening and b) how to fix it?

This bug appears to be FIXED, at least on Gecko 1.9.0 on x86, in Camino 2.1a1pre (1.9.0.15pre 2009100200). I.e., I get the "expected results" (option 2; "2nd circle starts on page 1 as before, and page 2 starts with the rest of 2nd circle") when printing this page on Mac OS X 10.5. cl

Works for: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009090900 SUSE/3.0.14-0.1 Firefox/3.0.14

fantasai: any idea why this might have suddenly started working in the last 18 months?

No idea, but it works in the 3.0 release. We can mark this bug as WORKSFORME, I guess.

WORKSFORME in Gecko 1.9.0-based (and later) browsers. Too bad we don't know what fixed this, though :-p