If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Print Preview shows each paragraph as a new page.

RESOLVED WORKSFORME

Status

()

Core
Printing: Output
RESOLVED WORKSFORME
14 years ago
8 years ago

People

(Reporter: Edgar Kerstan, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916

This page displays correctly, but Print Preview puts almost every paragraph or
list item on a new page.  Mozilla's Print Preview works correctly with other
pages (e.g. MSNBC or CNN home pages). This could be a badly coded page; however,
the Print Preview of Opera 7.20 and Internet Explorer 6.1 work correctly with
this particular page.

Reproducible: Always

Steps to Reproduce:
1. Just use Print Preview.
2.
3.


Expected Results:  
Print Preview output should be 8 pages long instead of 57 pages long.

I'm using the printer driver for the Epson Stylus Colour 440.  I had a friend
who also uses Mozilla reproduce the problem with the 1.5b beta version (I'm
using 1.5rc1).

Comment 1

14 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916

Confirmed.

Comment 2

14 years ago
Per last comment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Over to printing.  This could also be a table reflow issue; the site uses lots
of icky colspans and explicit row heights....

A minimal testcase would be very useful here (and bugs should really not be
confirmed without such).
Component: Print Preview → Printing
Keywords: qawanted

Comment 4

14 years ago
Created attachment 134594 [details]
Minimal test case

This test case reproduces the bug on:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031028

The print preview spreads the content out over 4 pages.  IE 6.0 print preview
renders it correctly.

Updated

14 years ago
Keywords: qawanted → testcase

Comment 5

14 years ago
Dupe of <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=212984">212984</a>

Comment 6

14 years ago
Dupe of <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=212984">212984</a>

Comment 7

12 years ago
This still exists on trunk using testcase (cited url not found).
so bug 212984 is not a dup - that's fixed

using rowspan as search criteria, possible dups are bug 290453, bug 320054

Comment 8

10 years ago
Created attachment 300717 [details]
Test Case ET:1 - Not Broken In Print Preview

When viewed in print preview this page will appear as expected.

Comment 9

10 years ago
Created attachment 300719 [details]
Test Case ET:2 - Broken In Print Preview

The only change from ET:1 is that the rowspan cell has only one row of text instead of two.

Comment 10

10 years ago
This bug is being triggered when a cell is traversing a page break with a rowspan value greater than one. However that alone will not trigger the bug. It appears the content of the cell also plays a role in whether the bug will trigger or not.

For example, attachment 300719 [details] does not break in print preview, but attachment 300717 [details] does. The only difference here is that the content in the rowspanning cel in attachment 300719 [details] contains an extra line of text (2 lines instead of 1).

Furthermore, if you increase the font size of the table from 2.5em to 3em, attachment 300717 [details] will then break in print preview. 

The rowspanning cel content in attachment 300719 [details] is vertically aligned and would be cut in half across the page break if the table were placed on the first page as you'd expect. Since attachment 300717 [details] has two lines of content instead of one, the vertical center of the content is between the two lines of text and thus no text is being rendered over the page break and that's why it works.

That's my theory anyways.


Comment 11

9 years ago
@Wayne Mery
It seems that the described bug here may be triggered by similar conditions as the bug mentioned by you (bug 290453) but the results are different. Here we find maybe unneeded additional pages. At bug 290453 there are entire rows missing.

I would not call them dubs.
Works for me, Firefox 3.0.1 on Linux.
Assignee: printing → nobody
QA Contact: printing

Comment 13

8 years ago
Test case in comment 9 is WFM.

Test case in comment 4 print 3 pages but I'm not sure it is a bug since IE7 and Google Chrome 5 give the same result.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
-> WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.