Closed
Bug 212984
Opened 21 years ago
Closed 21 years ago
printing too many pages: 137 pages instead of correct 4 from preview or PDFWriter
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.7final
People
(Reporter: script, Unassigned)
References
()
Details
(Keywords: regression, top100)
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
What looks fine on print preview or printing to PDFWriter makes a big mess when
actually printing to paper: It prints 137 pages, most of them containing the
page headers only.
Reproducible: Always
Steps to Reproduce:
1. Goto quoted web site, sorry you need to create an account. I have been able
to reproduce the problem with other pages, but this is the most striking example.
2. select "print preview"
3. print to printer
Actual Results:
137 pages are printed instead of 4. Most pages just show the page header/footer.
Print preview shows 4 correctly formated pages, as does PDFWriter,
Expected Results:
Print only 4 pages as displayed in print preview.
This looks similar to bug 212719. Plse review my classification as major. For me
this is really a show stopper for printing web pages as I might end up with 100
pages instead of just a few and let the printer run hot in an unprecictable way.
Mozilla build 2003121808 under w2k, http://msnbc.msn.com/id/3679341/ is only 5
pages long but will print out as 319. Ask me how I know. (That'll teach me not
to use print preview, which also displays the 319 pages). Except for the first
and last few pages which actually have some content, each page in between
contains only the header, footer, and a single pixel-row of the images on the
page (i.e. if there's a 198x298 image on the page, you're going to get about 298
pages). The printer used doesn't seem to matter, but for the record I tried the
following drivers with the same bad results: HP LaserJet 5Si MX, Savin SLP38c
PS, HP DeskJet 950, and HP LaserJet 6P. Setting this to "critical" because
although the inadvertant printing of reams of paper at work isn't considered
"loss of data", it could result in "loss of employment".
Will try to come up with a test case...
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
I confirm the bug on FireBird: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.6b) Gecko/20031216 Firebird/0.7+. Firebird shows identical behaviour to
"Additional Comment #1 From rcummins@bcls.lib.nj.us 2003-12-19 11:04"
Now using Mozilla 1.6, the problem has changed somewhat - I'm consistently
seeing 157 or 158 pages printed instead of more than 300. This bug seems to
affect most of msnbc.com's articles, here are a few that exhibit this problem:
http://msnbc.msn.com/id/3969486/
http://msnbc.msn.com/id/3907137/
http://msnbc.msn.com/id/3841686/
http://msnbc.msn.com/id/3939956/
http://msnbc.msn.com/id/3832808/
http://msnbc.msn.com/id/3081197/
http://msnbc.msn.com/id/3979904/
http://msnbc.msn.com/id/3842005/
...also it seems that if in Print Preview you shrink the scale down to 20-25% it
will suddenly go from 150+ pages to just one page. (I'm also going to change
the original URL in this bug report,
http://www.nytimes.com/2003/07/14/obituaries/14CART.html?tntemail1=&pagewanted=all&position=,
to http://msnbc.msn.com/id/3679341/ because the latter doesn't require
registration, and the former's content seems to have changed so that the problem
doesn't manifest itself anymore.)
Flags: blocking1.7a?
Comment 4•21 years ago
|
||
dbaron, any thoughts on who can help with this one?
Flags: blocking1.7b?
Flags: blocking1.7a?
Flags: blocking1.7a-
Comment 5•21 years ago
|
||
I can reproduce the problem on solaris using the MSNBC URLs. Print preview and
printing both produce 285 pages, most of them blank or containing just a sliver
of content from the bar running down the left side of the page. The NYT URL
doesn't produce the problem as noted in comment #3, so I've changed the sample URL.
This looks like same as bug 228584 and bug 231823; both of these have reduced
test cases. It seems that the problem appears both in printing and print preview
on *nix, but (based on this report) only while printing on windows.
Updated•21 years ago
|
Updated•21 years ago
|
Flags: blocking1.7b?
Flags: blocking1.7b-
Flags: blocking1.7?
*** Bug 238548 has been marked as a duplicate of this bug. ***
This problem doesn't occur on Phoenix 0.2 (2002-10-01 trunk) or Mozilla 1.1 but
does on Phoenix 0.3 (2002-10-14 trunk) and Mozilla 1.2, I don't have any other
old builds lying around so that's as close as I can get.
I have two reduced testcases, one from the URL in this bug and one from bug
238548, I'll attach both since they are slightly different.
Keywords: regression
Comment 10•21 years ago
|
||
*** Bug 232593 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
*** Bug 238778 has been marked as a duplicate of this bug. ***
Comment 12•21 years ago
|
||
I can't reproduce this with a trunk 1.7 winxp build from yesterday. Both
attachments print fine as does the first dupe but not the second. The current
url is a 404 that prints fine, updating url to the url in the second dupe.
Comment 13•21 years ago
|
||
*** Bug 228970 has been marked as a duplicate of this bug. ***
Comment 14•21 years ago
|
||
*** Bug 231212 has been marked as a duplicate of this bug. ***
Comment 15•21 years ago
|
||
I've attached a patch that ought to fix this to bug 231823. (It had a
simplified testcase first, so I've been treating it as the primary bug, sort of...)
However, the mapping from pixels to inches seems to be different for me than for
all of the testcase authors, so I tend to need to modify all the testcases by
putting in larger pixel values to make them show the bug in the first place, so
testing that my patch fixes the testcases here may be time-consuming...
Comment 16•21 years ago
|
||
The patch in bug 231823 definitely improves things.
The testcases go from being 12 pages long to 3 pages however the print preview
still shows large areas of blank space (e.g. in the first MSNBC testcase, page
2 contains nothing but the word "Test").
The URL field in this bug goes from 220 pages to 4 pages in print preview with
the patch applied, though there are still seemingly unnecessarily large gaps
(page 1 contains nothing but the header and the left column, page 2 contains
nothing but the title, the image and its caption, pages 3 and 4 contain the
article). The print preview also shows part of the text going outside the page
(see the attached image, when printed the text from "for the Moon and Venus!"
until the horizontal rule is ommitted).
I have no idea if these issues are part of this bug or are covered in separate
bugs but I thought I'd add them here just in case, sorry if this comment is not
relevant.
Comment 17•21 years ago
|
||
They belong in separate bugs.
Comment 18•21 years ago
|
||
Fixed by checkin of fix for bug 231823 to trunk, 2004-04-13 13:47:52 -0700.
Fixed by checkin of fix for bug 231823 to MOZILLA_1_7_BRANCH, 2004-04-16
14:21:09 -0700.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.7final
Comment 19•21 years ago
|
||
*** Bug 216614 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.7?
Comment 20•21 years ago
|
||
*** Bug 238237 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
*** Bug 228584 has been marked as a duplicate of this bug. ***
Comment 22•21 years ago
|
||
*** Bug 243491 has been marked as a duplicate of this bug. ***
Comment 23•21 years ago
|
||
*** Bug 244187 has been marked as a duplicate of this bug. ***
Comment 24•20 years ago
|
||
*** Bug 198908 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•