The default bug view has changed. See this FAQ.

Print & Print Preview truncate tables over 1 page long if there is a caption

RESOLVED FIXED

Status

()

Core
Layout: Tables
--
critical
RESOLVED FIXED
12 years ago
6 years ago

People

(Reporter: Jonathan Sachs, Unassigned)

Tracking

(Blocks: 1 bug, {dataloss, regression, testcase})

Trunk
x86
All
dataloss, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reflow-refactor] PLEASE READ COMMENT 3 AND COMMENT 16 BEFORE COMMENTING, URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+

Enter "606" in the "3-digit ZIP CODE prefix" box and click "Get Zone Chart."
Then select File / Print Preview, or print the page. Mozilla displays/prints
three pages. The first one contains material preceding the table, the second one
contains most but not all of the table, and the third one is empty. The part of
the table that does not fit on the second page is not printed at all.

Internet Explorer does essentially the same thing, but this is incorrect
behavior for any browser.

Reproducible: Always

Steps to Reproduce:
See "Details," above.
Actual Results:  
See "Details," above.

Expected Results:  
Anything that allows all the information to print. It seems most natural to let
the table flow onto the following page (and as many subsequent pages as necessary).

Updated

12 years ago
Assignee: nobody → printing
Component: General → Printing
Product: Firefox → Core
QA Contact: general
Version: unspecified → Trunk

Comment 1

12 years ago
Created attachment 184158 [details]
testcase

in print preview, the first page has the <input>, the second page has the
caption and some of the table.	the third page is blank (should have the rest
of the table)

tested with linux suite trunk 2005051905

Comment 2

12 years ago
this regressed between linux trunk 2005021505 and 2005021613, probably bug 274516

==> tables
Assignee: printing → nobody
Status: UNCONFIRMED → NEW
Component: Printing → Layout: Tables
Ever confirmed: true
Keywords: regression, testcase
OS: Windows XP → All
QA Contact: layout.tables
See http://lxr.mozilla.org/mozilla/source/layout/tables/nsTableOuterFrame.cpp#2002

The problem seems to be that we reflow the inner table, *then* we reflow and
place the caption, which moves the inner table down. The inner table no longer
fits on the page so bad things happen.

It looks like we want to reflow the table first to find the table width before
we reflow the caption, but we need to reflow the caption first so we know the
available height ... I'm not sure how to resolve this circularity. Any ideas Bernd?
Whiteboard: [reflow-refactor]

Comment 4

12 years ago
> The problem seems to be that we reflow the inner table, *then* we reflow and
> place the caption, which moves the inner table down.

It's not only about caption. Removing caption from the table often helps (as it does in the above test case) but is not a fool proof workaround. I had large tables without a caption truncated depending on the css line-height that affected the document content ahead of the table (e.g., printed fine at 140%, truncated with line-height set to 137%, in Fx1.5RC/WinXP).

This bug ruins technical papers with long tables. Too bad it will not be fixed for Fx1.5.

Comment 5

12 years ago
I am pretty sure this bug did not exist in 1.0.7, only the newer RCs.  Tables had printed normally, even repeating <thead> on each page as it should.  Is is possible to revert back to the old stable code?

Comment 6

12 years ago
Created attachment 204135 [details]
Contains <table> with <thead> and <tfoot>

The table should start on the first page and continue on the next page.  There are 50 rows in the tbody, but only 39 show.

Comment 7

12 years ago
This was interesting: if a table with <thead> and <tfoot> overflows the page, the table starts on a new page, clips at the end of the page, and prints the new page with only the <thead> and <tfoot>.  The overflowing content should have been shown between the <thead> and <tfoot>.  See "Contains <table> with <thead> and <tfoot>" attachment

Comment 8

11 years ago
*** Bug 312855 has been marked as a duplicate of this bug. ***

Comment 9

11 years ago
(In reply to comment #0)

From further tests, you can see that the bug happens when BOTH THE FOLLOWING
CONDITIONS are respected:

A) The page contains an <h1> title
B) The table in the page contains a <caption>

For full test case this bug, please refer to:

Page that generates the bug:

http://www.andreaverlicchi.com/bugs/mozillaprint_with_h1_and_caption.php

Pages that DON'T generate the bug:

http://www.andreaverlicchi.com/bugs/mozillaprint_with_h1.php
http://www.andreaverlicchi.com/bugs/mozillaprint_with_caption.php

I hope now it's easier to correct.

Comment 10

11 years ago
Not in Firefox 2.0 Beta 1 on Windows (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1).

I think this bug is fixed and someone with more permissions than me should mark it as FIXED (after verifying my claim, of course).  If you are annoyed with it, download the beta at http://www.mozilla.org/projects/bonecho/all-beta.html or wait until the final comes out hopefully August 8

Comment 11

11 years ago
Something similar happens to me (using Fx 1.5 on Linux, but also tested on 2.0RC2). On some circumstances, long tables are not printed starting in the right page, but they are moved one page down, which breaks formatting. (The same pages are rendered correctly on Opera 9.)

Comment 12

10 years ago
This bug still exists on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20060601 Firefox/2.0.0.2 (Ubuntu-edgy)

Updated

10 years ago
Duplicate of this bug: 378329

Updated

10 years ago
Duplicate of this bug: 372461

Comment 15

10 years ago
Going back to the duplicate Bug 378329, this bug has not gone away using Firefox 2.0.0.4. There is another anomaly/ clue, in that, if you shrink the page down to 30% you get more text onto the first page only, but the leftmost and rightmost columns do not have their fonts shrunk as much as the middle columns. The shrinking is not uniform and it still only puts truncated text on the first page and one tiny line on the 2nd page.

Comment 16

10 years ago
(In reply to comment #15)
> Going back to the duplicate Bug 378329, this bug has not gone away using
> Firefox 2.0.0.4.

No; the fact that this bug is still open is an acknowledgment that it is still not fixed.

The problem appears to be known, but a means of fixing it has not been determined. See comment 3.

Unless you are a developer actively involved in fixing this bug, commentary here is likely to be less than helpful. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before commenting.

cl
Whiteboard: [reflow-refactor] → [reflow-refactor] PLEASE READ COMMENT 3 AND COMMENT 16 BEFORE COMMENTING

Updated

10 years ago
Duplicate of this bug: 301711

Updated

10 years ago
Duplicate of this bug: 324532

Updated

10 years ago
Duplicate of this bug: 339854

Updated

10 years ago
Duplicate of this bug: 346656

Updated

10 years ago
Duplicate of this bug: 369602

Updated

10 years ago
Duplicate of this bug: 323688

Updated

10 years ago
Duplicate of this bug: 341907

Updated

10 years ago
Duplicate of this bug: 301378

Comment 25

10 years ago
It happens on many different pages effectively making it unable to print many pages with Mozilla. So the data on the page is lost, marking accordingly.

pi
Severity: normal → critical
Keywords: dataloss

Comment 26

10 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4

Another example is at <http://www.oakparkfoundation.org/grant_log.html>.  

Comment 27

10 years ago
I have big difficulties to see that the dupes (comment 17 till comment 24) are valid dupes. As the white board says read comment 3 before fiddling with this bug.
Take for instance bug 301378, the test case there has no caption at all. This bug has not been a trash bin for bad table printing and should not be converted into one. Boris could you please verify that your changes are valid and revert them if the only basis for your decision has been the fact that something is truncated.

Updated

10 years ago
Summary: Print & Print Preview truncate tables over 1 page long. → Print & Print Preview truncate tables over 1 page long if there is a caption

Comment 28

10 years ago
A good sample page is here : http://development.openoffice.org/releases/2.3.0.html
You cannot print it without reducing scale to 50% and put it into landscape.
Every testcase on this bug WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122605 Minefield/3.0b3pre.  The link in comment 3 is no longer valid; the file doesn't have anywhere near 2002 lines.  Was this fixed by the reflow branch?

Comment 30

9 years ago
It works for me too, with firefox 3 beta 2, on linux.
That's a really good news !

Comment 31

9 years ago
Why I try to print this web page with FireFox, only the first page is displayed
in Preview and only the first page is printed. On Internet Explorer after
selecting "print preview" it will print all 5 pages when 100% size is selected,
otherwise it compresses the 5 pages onto one page in IE with the default
"shrink to fit" option.
http://www2.parl.gc.ca/HousePublications/Publication.aspx?Language=E&Parl=39&Ses=1&Mode=1&Pub=Bill&Doc=C-427_1&File=24#1

Reproducible: Always

Steps to Reproduce:
It still does not work with 2.0.0.11
1.Select print icon
2.Print all selected as default
3.hit print
4. Only the first page of a 5 page document is printed
Actual Results:  
Only the first page of a 5 page document is printed. Whereas on IE 7.0.5730.11
all 5 pages are printed

Expected Results:  
I expect all 5 pages to be printed.
Above page also WFM, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122705 Minefield/3.0b3pre

Comment 33

8 years ago
This bug still exists in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4; also found that Internet Explorer 7.0.5730.11CO has a similar (same?) bug (in contrast to comment #31 above), which makes me wonder if the problem is in Windows components that Firefox calls for Print/Print Preview.  Example of a page that has this problem in both browsers, and additionally won't reliably display figures in Internet Explorer (at least Firefox does that right, but then also displays capital Delta in the table as D):  http://www.pnas.org/content/103/8/2857/suppl/DC1

Comment 34

8 years ago
Found that Safari 3.2.1 (525.27.1) on Windows XP prints the table correctly (except that it still messes up the Greek letters both in and out of the table).

Comment 35

8 years ago
Re comment #33:  Using my example (comment #26), I do not see this with IE 7 (7.0.5730.11).  

Unrelated to this problem (or is it?), however, the renderings of the table in my example between Gecko (1.8.1.18) and IE 7 differ.  Gecko shows only horizontal lines between table rows (the intended rendering) while IE also shows vertical lines on the edges of the table.  This difference is also seen in what is printed.

Updated

8 years ago
Depends on: 292124
Blocks: 369140
Blocks: 521204
Depends on: 452845

Comment 36

7 years ago
Someone else is now the Web master for the Community Foundation for Oak Park.  Contrary to the best practices for foundations, the Web site no longer contains a list of grants issued.  Thus, my comment #26 is no longer valid.

Comment 37

7 years ago
I retrieved the Web page cited in comment #26 from my archives and set it up as <http://rossde.com/test/large_tables.html>.

Comment 38

6 years ago
(In reply to comment #15)
> Going back to the duplicate Bug 378329, this bug has not gone away using
> Firefox 2.0.0.4. There is another anomaly/ clue, in that, if you shrink the
> page down to 30% you get more text onto the first page only, but the leftmost
> and rightmost columns do not have their fonts shrunk as much as the middle
> columns. The shrinking is not uniform and it still only puts truncated text on
> the first page and one tiny line on the 2nd page.

The problem described in comment #15 has disappeared with FireFox version 4.0. Although I can now print all 5 pages I still have to reduce the size to 90% to avoid truncating the notes in the margin on the right hand side.

Comment 39

6 years ago
The problem described in comment #31 has also disappeared with FireFox version 4.0. Although I can now print all 5 pages I still have to reduce the size to 90% to avoid truncating the notes in the margin on the right hand side.
Maybe this bug can be closed.

Comment 40

6 years ago
One more example for truncating after page 1.
http://www.norfolkline.com/EN/Blank/Terms/

It happens with Firefox 3.6 and 4.0.

Comment 41

6 years ago
Can confirm on Linux, also with FF 5.0a2 (aurora). However, that page does not use a table. It contains the whole page in a strange <span style="display: inline-block">.
Then that's bug 534182 rather than this bug.

Comment 43

6 years ago
Thank you, aceman/dbaron, I posted it there.

Comment 44

6 years ago
I believe this has been fixed by bug 642088 on trunk

Comment 45

6 years ago
Can confirm that on
Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110804 Firefox/8.0a1 ID:20110804030732
the table does no longer start always at page 2, but it starts to draw where there is space on page 1. I haven't noticed any truncated content. I think this was the problem description in comment 0 (URL no longer works) and comment 6.
I checked this on links in comment 33 and comment 37. Can't see any difference in comment 31. I have compared FF 5 to the build mentioned above. There are still other problems with table printing, but this one seems to have changed somewhat. The respective commenters should check their testcases.

Comment 46

6 years ago
The problem in comment #31 is fixed. I can print all the text only if the size is reduced to about 90% which results in 5 pages. If autofit to page width is selected the rightmost column gets truncated. So a new (?) problem still exits

Comment 47

6 years ago
comment #31 is not relevant to this bug as does not contain a caption. fixed by bug 642088
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 48

6 years ago
In which Gecko version is this fixed?

Comment 49

6 years ago
any build that contains http://hg.mozilla.org/mozilla-central/rev/2676a94cee76

Comment 50

6 years ago
(In reply to David E. Ross from comment #48)
> In which Gecko version is this fixed?

According to bug 642088, it is in Firefox 8, which is in Aurora now.

Comment 51

6 years ago
For the benefit of end-users who follow bug reports, it would be nice if such reports were NOT marked as Fixed until the release containing the fix were pending within only a day or two.  Perhaps a new Bugzilla status of Pending would be appropriate.

Comment 52

6 years ago
Can you please advocate you ideas not in a bug but in a news group (see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html point 1 "Constructive and helpful thoughts unrelated to the topic of the bug should go in the appropriate newsgroup.",  we have have done this this way as long as I am aware off (aka since 2000).
You need to log in before you can comment on or make changes to this bug.