360598 - Print Preview and print results in blank / incomplete pages when printing to File output drivers on certain rowspan / colspan table layouts when spanning multiple pages. Result vary on scale.

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Luc Mousseau]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

I found that for the following type of table layout containing, rowspans and colspans, in combination with various file output print drivers (such as Microsoft Office Document Image Writer, CutePDF Writer and PaperPort Black & White Image and PaperPort Color Image drivers) the resulting output is missing large chunks of the table and outputs blank pages.

Changing the scale changes the affect. If the scale is small enough to fit the majority of the content on a single page it outputs correctly. 

Also, just discovered, removing the first row also resolves the problem.

My regular default printer driver correctly shows the print preview and the printed output is correct.

Reproducible: Always

Steps to Reproduce:
1. Create a normal document with the following layout:

<table>

<tr><td colspan="2">row1 column spanning row</td></tr>
<tr><td>row2 col 1</td><td rowspan="2">col 2 row spanning</td></tr>
<tr><td>row3</td></tr>

<tr><td colspan="2">row1 column spanning row</td></tr>
<tr><td>row2 col 1</td><td rowspan="2">col 2 row spanning</td></tr>
<tr><td>row3</td></tr>
..
.. repeat the group of 3 rows 20 or so times so it spans two pages
..
</table>

2. Go to Print make sure one of the mentioned print drivers is selected (to do so you must print at least once using that driver, you can cancel).

3. Print the page or go to Print Preview to see the results.
Actual Results:  
With scale set to Shrink to fit, 100% or certain other %, the first row appears on the the first page, and the rest of the first page is blank. The second page shows an arbitrary number of rows from the bottom of the table. Rows between the first row and the last few rows are nowhere to be seen.

Expected Results:  
All rows should be printed correctly.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase based on comment 0

I also see the problem in comment 0, using current trunk build. This seems related to bug 301378.

Comment 2

[Luc Mousseau]

Attachment: Modified testcase - added row numbers

Was going to create this originally but ran out of time. I modified the first testcase and added row numbers, which helps to show what's missing.

Just to amend my original comment, this testcase doesn't only affect the file output print drivers I mentioned, it's also affecting my regular print driver (although differently). I suspect this might have something to do with the print boundaries reported by the driver, just a guess though. With my regular print driver selected, in my case, changing the scale from 100% to 90% reproduces what I see at 100% with the file output drivers. In fact changing the scale to anything also results in differing outputs (all wrong of course).

Yes, this does seem like it may be related to bug 301378, this also demonstrates  however that it doesn't seem to be the size of the rowspan that's the issue, but  rowspans in general when the table printout spans more than one page...

Comment 3

[Luc Mousseau]

Attachment: testcase removed colspan rows shows missing rows and messed up valign

Modified 2nd testcase. Removed colspan rows. Print preview looks better, however I still see it missing rows between pages.

Additional observation, the vertical alignment of the bottom most rows between pages appears to be affected. Obviously for the last row's rowspan you wouldn't want it to split the text in half (would you?), so it has to decide to either put it at the bottom of the current page or the top of the next page, but why would it affect the vertical alignment of the rowspanning cell above it, which is fully on the page? (is this deserving of an additional bug report?)

Comment 4

[-fullmetaljacket-]

i cant reproduce this on trunk on any of the three testcase.

could it be fixed on trunk by the reflow-refactor?

Comment 5

[Martijn Wargers (dead)]

(In reply to comment #4)
> could it be fixed on trunk by the reflow-refactor?

The way to test that is to use a build prior to the reflow branch landing and to use a build after the reflow branch landing.
I can see the bug, using a 2006-12-07 build (prior to the reflow branch landing), but not anymore with a 2006-12-08 build (although it suffers from bug 362708), which is after the reflow branch landing.
Looking at:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-12-07+05&maxdate=2006-12-08+08&cvsroot=%2Fcvsroot
It tells me that is the only real check-in that could have fixed this bug.
So I'm marking this bug fixed by the reflow branch landing bug.

Comment 6

[Aaron Johnson]

Found out about this bug the hard way at work. Can't wait for the fix!

Comment 7

[Martijn Wargers (dead)]

Aaron, please test a trunk build so that you'll be sure it is fixed in your case (it might vary slightly with this bug):
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 8

[Aaron Johnson]

Ich tried it, but the print out did not work too well for me to tell whether it was fixed (using 3.0a3pre). It only did 14 pages and the text could not be read. Ich will have to wait for a later build.

Comment 9

[Luc Mousseau]

Attachment: Screenshot - Print preview with current trunk build - ouch

Don't know about every one else, but if anything the trunk build is even worse than Fx 2.0. See attached screenshot.

Comment 10

[Luc Mousseau]

The print preview results I posted in comment #9 are the same for all testcases and any other web page. The screenshot is of the 3rd attachment. The 2nd attachment shows results similar to Fx2.0, where there's some content (with the huge font size) at the very top of each page, but the rest of the page is blank. The bug should probably be reopened if it's not just me.

Note, I used today's trunk build: Gecko/20070312 Minefield/3.0a3pre

Comment 11

[Aaron Johnson]

Attachment: Anoþer test case demonstrating þe blank pages

Here is þe document (wording modified) þæt wæs giving me trouble. It is large, so Ich zipped it.

Comment 12

[-fullmetaljacket-]

(In reply to comment #8, #9 and #10)

what you are seeing is bug 372838 which is a regression of bug 370588