Closed
Bug 75213
Opened 24 years ago
Closed 21 years ago
Printing Pagination is broken for a positioned <div>
Categories
(Core :: Printing: Output, defect, P1)
Core
Printing: Output
Tracking
()
RESOLVED
DUPLICATE
of bug 154892
Future
People
(Reporter: paul.gammans, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: css2, dataloss, testcase, Whiteboard: [awd:tbl])
Attachments
(1 file)
(deleted),
text/html
|
Details |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; 0.8.1) Gecko/20010326 BuildID: 2001032614 When printing a page table longer than a single page I loose any cell that don't fit on the first page. Reproducible: Always Steps to Reproduce: 1. Goto Example URL 2. Print page, my option were (all pages, A4) 3. Repeat 2 again using executive paper Actual Results: Using A4 Paper.. When I print this I get a single page containing the graphics and table on the page but the table only has some of the cells the rest seams to have been croped. Using executive paper... The row's length seam to be croped on right hand edge too. Expected Results: Mutiple Pages containg rest of table The page seams to use layers and an absolute tag as below for the layer containg the table. <div id="Layer5" style="position:absolute; width:611px; height:950px; z-index:11; left: 135px; top: 363px"> An example zipped Postscript file can be downloaded from http://www.brunel.ac.uk/~dtpgprg/mozilla/table-print-error1.ps.gz
Comment 1•24 years ago
|
||
definitely a dup.. Chris.. you what to dup this against.
Assignee: dcone → karnaze
Comment 2•24 years ago
|
||
*** This bug has been marked as a duplicate of 66804 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 4•23 years ago
|
||
Using build 2001101708 This bug seams to still be present and thus not dup of bug#66804 though unlike the nytime.com bug#105166 the remaining table isn't pushed on to the next page just crop and thus lost.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
fixed URL.
confirming...only the first page is printed out...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 7•23 years ago
|
||
Hi folks. I've verified that also in "Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011" Chris told me to add this comment. So please change platform field to "all" or something else. I tried that but I'm not allowed.
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
Marc, the postioned div does not split across the page causing dataloss (I turned on the display reflow output and the div does not return an incomplete status which would cause it to split). Changing the summary from "Printing Pagenation is broken for long tables" to "Printing Pagenation is broken for a positioned <div>".
Updated•23 years ago
|
Keywords: mozilla1.0
Target Milestone: --- → mozilla1.0
Comment 11•23 years ago
|
||
Additional example illustrating this bug found at: http://www.mckinseyquarterly.com/article_abstract.asp?ar=1184 and then select the 'Read Full Text" link (requires login at McKinsey site) Useful for verifying when the bug is fixed?
Comment 12•22 years ago
|
||
Chris reassigning this to you because I know you are working on breaking up divs
Assignee: attinasi → karnaze
![]() |
||
Updated•22 years ago
|
Summary: Printing Pagenation is broken for a positioned <div> → Printing Pagination is broken for a positioned <div>
Comment 14•22 years ago
|
||
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
Comment 15•22 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
Component: Printing → Layout: Tables
QA Contact: sujay → madhur
Target Milestone: mozilla1.1alpha → ---
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 16•22 years ago
|
||
not a table bug
Assignee: table → printing
Component: Layout: Tables → Printing
QA Contact: madhur → sujay
Comment 17•22 years ago
|
||
I found a MOZILLA WorkAround!!!! (for #166836, most likely this one too) (now line-spacing is a bit jacked in IE6 - Use a browser detect & write) link a stylesheet for printing only. <link href="/common/NoPrint.css" rel="stylesheet" type="text/css" media="print" /> In the stylesheet, redefine the <BODY> tag with: body{ white-space: pre; line-height: .5em; } Long Single Divs that wouldn't print all parts before should print all parts, and also, divs that were split and printed on multiple pages, will now all print Inline.
Comment 19•22 years ago
|
||
I found this same bug on a page with out a positioned DIV. The first page prints but the rest of the pages are lost except for a footer that prints last. This bug is visible if you use the Print Preview menu item. I tried to circumvent this by selecting all of the text on the page and using the Print Selection option in the print dialog. Unfortunatly, this caused lines of text to truncate mid line (i.e. the top or bottom of the text would be cut off). Here is the page for reference: http://www.sitepoint.com/print/728
Updated•21 years ago
|
Flags: blocking1.6b?
Comment 21•21 years ago
|
||
dbaron, what are your thoughts on this. How widespread do you think is content affected by this and how difficult to fix?
Comment 22•21 years ago
|
||
*** This bug has been marked as a duplicate of 154892 ***
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → DUPLICATE
Comment 23•21 years ago
|
||
There's no way a patch for this could land in anything other than an alpha.
Flags: blocking1.6b? → blocking1.6b-
You need to log in
before you can comment on or make changes to this bug.
Description
•