231823 - When attempting to print or print preview the map is separated into hundreds of pages

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P1)

Description

[Aaron Williams]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114

Whenever I attempt to print or print preview http://www.mount.com/direction.html
I get over 160 pages of output.  The map is converted into many pages of very
short strips.  I have a Postscript level 2 printer.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.mount.com/direction.html
2. Click print preview
3. Look at the bad output

Comment 1

[Max Alekseyev]

Confirmed on Linux build 2004012207

OS/2 build 2004012108 works fine

Comment 2

[Boris Zbarsky [:bzbarsky]]

Is this a problem with the interlaced image painting all wrong somehow?  Do
other interlaced images fails too?

Comment 3

[tor]

The problem happens on linux, win32, and os/2 (though oddly much less severe
on the latter).  Quite a few assertions of the form:

###!!! ASSERTION: aContent1 must not be null: 'aContent1', file
/home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 222
Break: at file /home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 222
###!!! ASSERTION: aContent2 must not be null: 'aContent2', file
/home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 223
Break: at file /home/tor/src/mozilla/layout/base/src/nsLayoutUtils.cpp, line 223

Layout issue?

Comment 4

[Kenneth Herron]

Attachment: Reduced testcase

I can reproduce the effect on solaris using a cvs build from 2004/01/14 and an
old nightly from 2003/09/14. I don't think this is specifically related to the
image; mozilla is just rendering the bottom half of the page in little strips
for some reason.

The original page contains several paragraphs of text following the image
(directions to the office). When printing the page, the last several pages of
the printout contain no content other than this text, at one line per page.

I saved the html for the page to a local file and loaded it into mozilla. All
of the images were broken, but printing this page still yielded a 160-page
print job with one line of text per page toward the end.

I've reduced this page to something just containing the directions; viewed in
print preview it still yields 20-odd pages with one line of text per page.

Comment 5

[Max Alekseyev]

OS/2 build has no problem with the testcase. Just 1 page as expected.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.. In the reduced testcase the problem is that the table cell should be 1087
pixels tall and that this is too big to fit on a page, and then something gets
confused in the mess that is the splitting code...

Comment 7

[Kenneth Herron]

Attachment: Variant testcase

In the original sample page, the <img> for the map is contained within the same
<td> block as the text, and the <td> is contained within a <tr> with a
height="3" attribute. When printing the sample page, the image slivers were
mostly 3 pixels high.

Here I've restored the <img> tag to the <td> section containing the text, and
added a height="10" attribute to the containing <tr>. Print preview yields a
63-page document; the first 47 pages contain 10-pixel slivers of the image; the
rest contain a line or so of text.

Changing the value of the height attribute in the first <tr> changes the height
of the slivers; if the height is tall enough, mozilla will also put more than
one line of text on the text pages. If the height attribute on the first <tr>
is removed, I get a 392-page print job where the image slivers are one pixel
high.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Oh, hmm... So we're putting the height of the image that fits in the first row
on the page, then the second row does not fit, so we page-break and try again on
the next page, huh?

Comment 9

[Kenneth Herron]

See bug 228584 for a more complex example.

Comment 10

[Kenneth Herron]

Bug 231212 looks like another duplicate.

Comment 11

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

I can't reproduce with Linux+PostScript with either testcase with either print
or print preview.  (I think I tried all 4 combinations, although I may have only
done 3.)

Comment 12

[Kenneth Herron]

Using CVS builds from 20040309, I can still reproduce the problem reliably with
either testcase. I've tried building mozilla on linux with gtk, gtk2, and xlib,
and without freetype and xft; all of them behave the same.

Each of the testcases contains an empty <tr> of height 1087. The bug apparently
depends on this <tr> being too large to fit on the same page with the content.
Making this height smaller, or selecting a larger paper size, makes the problem
disappear. If you're having trouble reproducing this, you could try selecting a
smaller paper size, or downloading a testcase and editing it to make the height
larger.

Comment 13

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

Yeah, I can reproduce by changing 1087 to 1587.

Comment 14

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

The problem is here:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp&rev=3.319&mark=1150#1147

Now I'll do CVS archaeology to figure out what this was supposed to do...

Comment 15

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

The problematic code was introduced in bug 165772 (although deCOMtaminated
later).  Setting availHeight to something like that is clearly wrong --
availHeight should (for printing) always be a distance from the current position
to the bottom of the page (for non-printing cases, it should always be
NS_UNCONSTRAINEDSIZE).

Comment 16

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

Attachment: patch

This patch makes sense to me, and fixes the bug.  I'm not sure how to
regression-test it...

Comment 17

[Bernd]

print regression tests did work with viewer -Prt 1  see
http://lxr.mozilla.org/seamonkey/source/layout/html/tests/table/printing/rtest.bat
on windows. They get however every now and then broken by somebody who doesnt
understand the sense of the file argument or some stupid dialog that pops up. I
can run them for you, and attach a hack that I used to get them running again.
In principle it would be cool to have these print regression tests attached to
the layout debugger. I remember that you told me that these tests never worked
on linux. I will need some time for the review, as I did avoid the printing code
up to now.

Comment 18

[Bernd]

Comment on attachment 145770 [details] [diff] [review]
patch

I runned the rtest.bat in table/printing and did not see a regression test
failure.

Comment 19

[Asa Dotzler [:asa]]

Comment on attachment 145770 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.7

Comment 20

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

Fix checked in to trunk, 2004-04-13 13:47:52 -0700.

Fix checked in to MOZILLA_1_7_BRANCH 2004-04-16 14:21:09 -0700.

Comment 21

[Tracy Walker [:tracy]]

verified