Closed Bug 208070 Opened 21 years ago Closed 16 years ago

first page is blank when printing table document

Categories

(Core :: Printing: Output, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jwz, Unassigned)

References

()

Details

Attachments

(3 files)

Any time I print (or print preview) one of the DNA Lounge calendar pages (e.g.,
http://www.dnalounge.com/calendar/2003/06.html), it prints fine except that page
1 is blank: the first content begins on page 2.

I've narrowed this down to the following test case.  Print-preview this
document, and you should see the first page blank.  I can't see how to narrow it
any more, so I'm not sure what exactly triggers it.  In particular, it is
sensitive to changes in ROWSPAN, CELLPADDING, and CELLSPACING.  The BR before
the TABLE is also necessary for the problem to exhibit itself.

Mozilla 1.3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314
Red Hat Linux release 7.2 (Enigma)
Linux 2.4.9-13smp #1 SMP Tue Oct 30 19:06:50 EST 2001 i686 unknown

----------------------------- cut here ----------------------------- 

    <BR>

    <TABLE CELLPADDING=40 CELLSPACING=0>

     <TR>
      <TD ROWSPAN=2>
       1.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> 
      </TD>
     </TR>

     <TR></TR>

     <TR>
      <TD ROWSPAN=2>
       2.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> 
      </TD>
     </TR>

     <TR></TR>

     <TR>
      <TD ROWSPAN=2>
       3.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> 
      </TD>
     </TR>

     <TR></TR>

     <TR>
      <TD ROWSPAN=2>
       4.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> 
      </TD>
     </TR>

     <TR></TR>

     <TR>
      <TD ROWSPAN=2>
       5.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> Foo.<BR> 
      </TD>
     </TR>

     <TR></TR>

    </TABLE>
This is a more general bug. 

When you print a page with a table, if the table does not fit on the bottom of
the current page, it is moved onto the next page. If it does not fit entirely on
the next page, it is then split over multiple pages. 

When a table is split over multiple pages like this, it really ought to fill the
remaining space on the page the table started on, rather than leaving a partly
blank page and starting at the top of the next page. (In the example above, it
is really bad becuase the only content on the first page is a <br>, so the page
appears empty.)

I am seeing this with http://www.britgo.org/rating/list.html.

I think that a better summary would be "A table that splits across multiple
pages when printed should start immediately, and not leave a partly blank
page.", but it is a bit long. Anyway, I am not empowered to change it.

Tim.
This bug is bad.
*** Bug 295507 has been marked as a duplicate of this bug. ***
both URL WFM - first page is not blank.
FF 1.5 - XP
QA Contact: sujay
This works for me too, although someone on Linux should confirm that because this bug is PC/Linux (I doubt there's a problem, but I'll be conservative).
This problem is still there in firefox 2.0.0.1. For example, when printing http://faculty.csuci.edu/maria.nogin/math145fall03/schedule.html, the table get split right after its first row for no good reason (will attach the HTML and the resulting PS shortly).
Screenshot of the first 3 pages of the print preview of the attachment 255595 [details] in Firefox 2.0.0.1 running under Red Hat Enterprise Linux 4.4 with an empty fresh profile. First page only has a few lines, second page only has the very first line of the table and only the third page is properly filled.
Printout of the attachment 255595 [details] in Firefox 2.0.0.1 running under Red Hat Enterprise Linux 4.4 with an empty fresh profile. First page only has a few lines, but this time (contrary to what the print previe showed), the second page is properly filled.

With the exact same HTML file, but somewhat different pmargins I was seing other crazy page breaks as well... Older versions of Firefox and Mozilla also behave very similarly.
Aleksey. DO you still see the original URL and comment 1 fail?

(note, the reports here are all over the map - the reporter doesn't respond)

Your table testcase also fails on windows, so it is an OS=ALL bug.  You'll have to reduce the testcase to see which bug fits - but can't see it being a good match to this bug.
(In reply to comment #10)
> Aleksey. DO you still see the original URL and comment 1 fail?

That URL shows OK in my "print preview". Note, however, that this page is currently being served with "Last-Modified: Sun, 17 Sep 2006 01:56:47 GMT", so there is no way to tell whether it still has the same contents as it used to when the bug was originally reported. Also, this bug appears to be sensitive to things like margins, possibly also to letter papper vs a4, etc.
true - but I compared it to what's at archive.org and i believe they are the same
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121405 Minefield/3.0b3pre

WFM - none of the testcases are missing page 1.  Does anyone else see this? 


URL from comment 1 has what may be a table layout problem.

all suffer from pagination problem of clicking the "forward one page" icon to go to page two doesn't go to page 2, it goes to last page or some intermediate spot like page 6.  don't have bug #.
works for me - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080901033305 Minefield/3.1b1pre and Linux 3.0.1
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: