212034 - Page break before huge table row inconsistent in print, preview, XP, Linux

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Oliver Schoett]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Preview shows 2 pages, printout has 3 pages, apparently caused by an extra page
break before the huge table row that contains the double-column main content of
the document.

Reproducible: Always

Steps to Reproduce:
1. Preview the page
2. Print the page


Actual Results:  
The preview has two pages, with the main content beginning right after the
headlines on the first page.

The printout has three pages, with an extra page break after the headlines,
before the main content.

Expected Results:  
First priority: Printout and preview should be consistent.

Second priority: Printout should look like the preview, rather than vice versa.

Comment: While in general it is a good idea to break between table rows rather
than within, no page break is needed before a huge table row that does not fit
on a page anyway.  So I think that the layout of the preview is better than that
of the printout.  The problem could become annoying on many pages that use
tables to layout their content.

A4 paper, HP Laserjet 5si @ 600dpi

The bug looks similar to bug 186749 (but there the preview correctly shows the
unwanted extra page breaks).

Comment 1

[Oliver Schoett]

On gentoo Linux, the behaviour is exactly the opposite:
 - print preview show three pages with the extra page break,
 - the printout has two pages wothout the extra page break.

Thus, we have
 - preview/print inconsistency on both XP and Linux, and
 - XP/Linux inconsistency in preview, and
 - XP/Linux inconsistency in print

I tend to view this bug as major, because unwanted extra page breaks have
plagued me for years when printing the ubiquitous tabular layouts with Mozilla.


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030711

A4 paper, HP Laserjet 5L @ 600dpi economy
Drivers: cups, gimp-print-cups, hpijs (http://hpinkjet.sourceforge.net)

System and compilation info:

Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4)
=================================================================
System uname: 2.4.21 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz
GENTOO_MIRRORS=" http://ftp.easynet.nl/mirror/gentoo/
ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ http://gentoo.linux.no/
ftp://sunsite.cnlab-switch.ch/mirror/gentoo/"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config
/usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config
/usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR_OVERLAY="/usr/local/portage"
USE="3dnow crypt gif gpm libg++ mad mikmod mmx ncurses nls pdflib quicktime
spell xml2 gdbm berkdb slang readline svga java guile X sdl pam libwww ssl perl
python imlib qt motif -aalib acpi alsa -apm -arts avi cdr cups dvdemacs encode
esd gnome gphoto2 gtk gtk2java jpeg -kde -leim mbox mozilla mpeg -mule-nls
oggvorbis opengl -oss png readlinesamba sse tcpd tetex tiff truetype usbX xmms
xv x86 zlib"
COMPILER="gcc3"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -mcpu=pentium4 -O3 -pipe"
CXXFLAGS="-march=pentium3 -mcpu=pentium4 -O3 -pipe"
ACCEPT_KEYWORDS="x86"
MAKEOPTS="-j2"
AUTOCLEAN="yes"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage/"
FEATURES="ccache fixpackages notitles sandbox userpriv"

Comment 2

[Ere Maijala (slow)]

Confirming. What I'm seeing is that depending on the paper size and margins the
problem appears or disappears in the print preview too.

Comment 3

[Ere Maijala (slow)]

Attachment: Reduced test case

This is a very simple test case. With paper size set to Letter and all margins
at 0.5 inches there's only the first row on the first page and the second row
starts from the second page. If I change the bottom margin to 1 inch, the
second row starts from the first page as expected.

Comment 4

[Ere Maijala (slow)]

Confirmed with latest trunk build and Firefox 1.0 PR.

Comment 5

[Ere Maijala (slow)]

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

Comment 6

[Ere Maijala (slow)]

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

Comment 7

[Ere Maijala (slow)]

Attachment: Patch v1: Truncate bottom margin of a block frame if necessary

This is my first stab at fixing the problem. The rows shift to the second page
because the bottom margin of the last block is added to the height of the row
group causing the row group to overflow the space. This patch makes it so that
the margin is truncated if it doesn't fit to the available space.

Comment 8

[Ere Maijala (slow)]

Comment on attachment 168013 [details] [diff] [review]
Patch v1: Truncate bottom margin of a block frame if necessary

Robert, what do you think, is my approach correct?

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This doesn't really seem right.  I could understand letting part of a margin
disappear at a page break, but it seems like the padding and border ought to end
up on the next page, not the same one.  Furthermore, it seems like this patch
wouldn't fix the bug if the block had bottom padding or border (maybe margin too).

Comment 10

[Ere Maijala (slow)]

I thought padding and border are taken into account when evaluating how many
blocks fit into the given space. Anyway, I'll check those issues.

Comment 11

[Ere Maijala (slow)]

I can't find any problems. David, could we fix this particular problem anyway
and file new bugs for any other problems?

Comment 12

[Ere Maijala (slow)]

David?

Comment 13

[Ere Maijala (slow)]

Comment on attachment 168013 [details] [diff] [review]
Patch v1: Truncate bottom margin of a block frame if necessary

bz, what do you think about this?

Comment 14

[Boris Zbarsky [:bzbarsky]]

I think the same thing as comment 9... If this is working right, I'd like to
know why (and it should be documented in the code).

Comment 15

[Ere Maijala (slow)]

Oops, the first patch is actually wrong, I understand it might have caused
confusion. I'll add a better one that actually does what the old XXX comment
there now suggests. Anyway, here's the explanation:

Table rows are walked in nsTableRowGroupFrame.cpp line 1008 until a row that
doesn't fit is found. In the problem case the rows that fit don't leave any
space available. In the end, when everything is supposed to be well, the bottom
margin of the last block (which wasn't included in the space calculation) is
added and the rows overflow the available space. Then the test at
nsTableRowGroupFrame.cpp line 1039 indicates that the table wasn't able to
include anything in the available space and a page break will be added. 

Comment 16

[Ere Maijala (slow)]

Attachment: Patch v2

Corrected patch.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 172270 [details] [diff] [review]
Patch v2

I suspect roc is a lot more qualified than I to review this (esp. because this
affects columns, not just printing).

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 172270 [details] [diff] [review]
Patch v2

Nice.

Comment 19

[Ere Maijala (slow)]

Thanks. Fix checked in to trunk.