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).
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"
Confirming. What I'm seeing is that depending on the paper size and margins the problem appears or disappears in the print preview too.
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.
Confirmed with latest trunk build and Firefox 1.0 PR.
*** Bug 260941 has been marked as a duplicate of this bug. ***
*** Bug 257991 has been marked as a duplicate of this bug. ***
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.
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?
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).
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.
I can't find any problems. David, could we fix this particular problem anyway and file new bugs for any other problems?
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?
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).
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.
Created attachment 172270 [details] [diff] [review] Patch v2 Corrected patch.
13 years ago
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 on attachment 172270 [details] [diff] [review] Patch v2 Nice.
Thanks. Fix checked in to trunk.