Closed Bug 280753 Opened 19 years ago Closed 19 years ago

Web Page Printed incorrectly (only one page, should have 3-4 pages).

Categories

(SeaMonkey :: General, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 154892

People

(Reporter: rickstockton, Unassigned)

References

()

Details

Attachments

(1 file)

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

The layout on the screen is good, showing about 200 lines of text. But, printed
to either a physical printer or looking at 'Print Preview', Mozilla present only
one page. In portrait mode, there should be 3 or 4 pages. In landscape mode,
there should be least 5 pages. Print Preview shows an additional line or 2 of
text "falling off the bottom" of the page in both modes.

I have no idea why Mozilla doesn't see that multiple pages are needed. Even when
I set the scale to 175% or 200%, which should result in a printout of MANY
pages, Mozilla continues to show that only 1 page is necessary.

Mozilla appears to assume that I want to print on USA Letter paper (8" by 11.5")
and this is a reasonable assumption for my USA locale. But even if so, Mozilla
should easily conclude that this web page will need multiple physical pages
under the scale and orientation choices which I make. It's badly broken.

Note that this University of Nevada Page will be available until the end of May,
2005.  

Reproducible: Always

Steps to Reproduce:
1. Go to the specified web page.
2. Select "Print" or "Print Preview" from the File Menu.
3. See Mozilla print or show an inadequate number of physical pages (USA
"Letter", using either Portrait or Landscape with reasonable Scale).

Actual Results:  
Always get just one page, with content truncated.

Expected Results:  
Generated multiple pages of printout.

I am using an Xprint/CUPS environment under Linux. My default screen is
1024x768, 65 dpi (I have a very large monitor, about 19.7" diagonal).

MandrakeLinux (X.Org X11 6.7.0, patch level 4.2.101mdk)
Default Printer: HP OfficeJet 4110 multifunction device on USB

Note that my Linux device uses HP-LIDIL, not HP-PCL. My customer's device is an
HP PSC All-In-One (probably LIDIL), under Windows XP. I can get the model number
if you need it.
I described as OS=ALL, although I have seen the problem only with Windows XP and
Mandrake Linux 10.1.

Please advise if a test with nightly 1.7, 1.8, or FF on Linux would be of great
value to you. (I'll make a tar of my current profile, restore it after each
browser migration test.) I can only test with the OfficeJet 4110. My Windows XP
customer with the PSC is a Mozilla newby, I can't make her do the profile backup
thing over the phone. Besides, its just another LIDIL device. I can check a
patched Mozilla or FF on Windows 98 (*NOT* SE), with my Officejet, if/when we
have a patch to verify.

I don't trust myself to CORRECTLY save the page as a Bug Attachment, I'll ask
for advice if we haven't got a fix by early May. Is a .tgz of "Save as Web Page,
Complete" likely to be OK?
Version: unspecified → 1.7 Branch
Yes, a tar.gz of a save as, complete should be fine.  Please attach that?
Failing attachment shows a syllabus page for a class at UNR. It should take
about 4 pages to print out with "normal" scaling. As in the original
description, both the printed page and "print preview" end at the bottom of the
first page. Print preview shows a couple more lines of content, falling through
and below the bottom of the paper image.

Thanks Asa, for confirming that this would be an OK format. On the Bug URL, I
erroniously left in some Session ID stuff which has to be chopped off in order
to see the page. Use the attachment, works great. (That is, works NOT ;-)
Attachment #173816 - Attachment mime type: text/html → application/x-tar
The content is in an absolutely positioned div....

*** This bug has been marked as a duplicate of 154892 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I will add a note (on 154892) that "WebObjects 5.2" was used to create this
page. I don't know if WebObjects has a lot of Market Share, but I think it's
especially bad to fail on valid pages created by such tools.
Please don't add more comments to that bug... We know it's a problem; adding
more comments won't affect that.  What would help is having engineering
resources to address the problem.
Version: 1.7 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: