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

RESOLVED FIXED

Status

()

Core
Printing: Output
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: Oliver Schoett, Assigned: Ere Maijala (slow))

Tracking

(Blocks: 1 bug)

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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).
(Reporter)

Comment 1

14 years ago
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"
OS: Windows XP → All
Summary: Extra page break printed before huge table row, but not shown in preview → Page break before huge table row inconsistent in print, preview, XP, Linux
(Assignee)

Comment 2

13 years ago
Confirming. What I'm seeing is that depending on the paper size and margins the
problem appears or disappears in the print preview too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 3

13 years ago
Created attachment 163192 [details]
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.
(Assignee)

Comment 4

13 years ago
Confirmed with latest trunk build and Firefox 1.0 PR.
(Assignee)

Comment 5

13 years ago
*** Bug 260941 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Blocks: 217145
(Assignee)

Comment 6

13 years ago
*** Bug 257991 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Assignee: core.printing → emaijala
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 7

13 years ago
Created attachment 168013 [details] [diff] [review]
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.
(Assignee)

Comment 8

13 years ago
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?
Attachment #168013 - Flags: review?(roc)
(Assignee)

Updated

13 years ago
Attachment #168013 - Flags: review?(roc) → review?(dbaron)
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).
(Assignee)

Comment 10

13 years ago
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.
(Assignee)

Comment 11

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

Comment 12

13 years ago
David?
(Assignee)

Comment 13

13 years ago
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?
Attachment #168013 - Flags: review?(dbaron) → review?(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).
(Assignee)

Comment 15

13 years ago
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. 
(Assignee)

Comment 16

13 years ago
Created attachment 172270 [details] [diff] [review]
Patch v2

Corrected patch.
Attachment #168013 - Attachment is obsolete: true
Attachment #172270 - Flags: review?(bzbarsky)
Attachment #168013 - Flags: review?(bzbarsky) → review-
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).
Attachment #172270 - Flags: review?(bzbarsky) → review?(roc)
Comment on attachment 172270 [details] [diff] [review]
Patch v2

Nice.
Attachment #172270 - Flags: superreview+
Attachment #172270 - Flags: review?(roc)
Attachment #172270 - Flags: review+
(Assignee)

Comment 19

13 years ago
Thanks. Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.