User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916 This page displays correctly, but Print Preview puts almost every paragraph or list item on a new page. Mozilla's Print Preview works correctly with other pages (e.g. MSNBC or CNN home pages). This could be a badly coded page; however, the Print Preview of Opera 7.20 and Internet Explorer 6.1 work correctly with this particular page. Reproducible: Always Steps to Reproduce: 1. Just use Print Preview. 2. 3. Expected Results: Print Preview output should be 8 pages long instead of 57 pages long. I'm using the printer driver for the Epson Stylus Colour 440. I had a friend who also uses Mozilla reproduce the problem with the 1.5b beta version (I'm using 1.5rc1).

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916 Confirmed.

Per last comment.

Over to printing. This could also be a table reflow issue; the site uses lots of icky colspans and explicit row heights.... A minimal testcase would be very useful here (and bugs should really not be confirmed without such).

This test case reproduces the bug on: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031028 The print preview spreads the content out over 4 pages. IE 6.0 print preview renders it correctly.

Dupe of <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=212984">212984</a>

Dupe of <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=212984">212984</a>

This still exists on trunk using testcase (cited url not found). so bug 212984 is not a dup - that's fixed using rowspan as search criteria, possible dups are bug 290453, bug 320054

When viewed in print preview this page will appear as expected.

The only change from ET:1 is that the rowspan cell has only one row of text instead of two.

This bug is being triggered when a cell is traversing a page break with a rowspan value greater than one. However that alone will not trigger the bug. It appears the content of the cell also plays a role in whether the bug will trigger or not. For example, attachment 300719 [details] does not break in print preview, but attachment 300717 [details] does. The only difference here is that the content in the rowspanning cel in attachment 300719 [details] contains an extra line of text (2 lines instead of 1). Furthermore, if you increase the font size of the table from 2.5em to 3em, attachment 300717 [details] will then break in print preview. The rowspanning cel content in attachment 300719 [details] is vertically aligned and would be cut in half across the page break if the table were placed on the first page as you'd expect. Since attachment 300717 [details] has two lines of content instead of one, the vertical center of the content is between the two lines of text and thus no text is being rendered over the page break and that's why it works. That's my theory anyways.

@Wayne Mery It seems that the described bug here may be triggered by similar conditions as the bug mentioned by you (bug 290453) but the results are different. Here we find maybe unneeded additional pages. At bug 290453 there are entire rows missing. I would not call them dubs.

Works for me, Firefox 3.0.1 on Linux.

Test case in comment 9 is WFM. Test case in comment 4 print 3 pages but I'm not sure it is a bug since IE7 and Google Chrome 5 give the same result. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

-> WORKSFORME