Closed Bug 325093 Opened 14 years ago Closed 14 years ago

Bottom and right side of Print preview and Printed pages are chopped off (ongoing issue)

Categories

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

x86
All
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: edwardp, Assigned: roc)

References

Details

(Keywords: regression, testcase)

Attachments

(6 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9a1) Gecko/20060127 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9a1) Gecko/20060127 SeaMonkey/1.5a

Beginning with the 1/27/2006 SeaMonkey nightly, printed pages are chopped off on the right side, changing Page Setup and Print/Preferences does not resolve the issue.



Reproducible: Always

Steps to Reproduce:
1.Load in web page.
2.Print page, page is chopped off.  
3.Print Preview displays the same (chopped off).

Actual Results:  
Print Preview and printed page is chopped off on right side.

Expected Results:  
Print Preview and printed page should have correctly printed.

The last build I used that did not exhibit this behavior was 1/24/2006.

Please see attachments of Print Preview screens from the 1/24, 1/27 and 1/28 builds.  The filenames contain the Build ID of each.  

The 1/25 and 1/26 builds were not used due to issues with Mail and News.
Attachment #210009 - Attachment description: Print-screens of Print Preview → Print-screen of Print Preview 1/24/2006 build.
Attachment #210010 - Attachment description: Print-screen of Print Preview → Print-screen of Print Preview 1/27/2006 build.
Attachment #210011 - Attachment description: Print-screen of Print Preview → Print-screen of Print Preview 1/28/2006 build.
regression between 2006-01-25-04 and 2006-01-26-03
Assignee: general → roc
Blocks: 317375
Status: UNCONFIRMED → NEW
Component: General → Printing
Ever confirmed: true
Keywords: regression, testcase
Product: Mozilla Application Suite → Core
QA Contact: general → printing
Version: unspecified → Trunk
Attached file testcase
margin is cropped on the right with linux seamonkey trunk build 2006012801
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060128 SeaMonkey/1.5a

This bug also affects the Windows build.
OS: Linux → All
Windows build used (should be in Comment 6):  2006012809
Printing from http://users.pandora.be/satcp/eac-qs-en.htm, the page is chopped off at the bottom as well as on the right-hand side, and (as stated by the reporter) Page Setup has no effect. (eMac G4, OS X 10.3.9, Classic theme; Epson SP830 printer.)
I suspect you will find the build from 26th has the problem too.
*** Bug 325276 has been marked as a duplicate of this bug. ***
Updating topic to catch more dupes - old topic was "Printed pages are chopped off (ongoing issue)"
Summary: Printed pages are chopped off (ongoing issue) → Bottom and right side of Print preview and Printed pages are chopped off (ongoing issue)
*** Bug 325783 has been marked as a duplicate of this bug. ***
*** Bug 325552 has been marked as a duplicate of this bug. ***
Attached image Altered print output
It looks like the clipping region around the page content frame isn't being adjusted for the printing left and top margins. The postscript output for the pandora.be website starts by drawing three rectangles. The first isn't important. The next two are:

    1 1 1 setrgbcolor
     newpath
    720 15091 10742 -14371 Mrect  fill
     gsave
     newpath
    0 15811 10742 -14371 Mrect  clip

Here the "x y width height Mrect" sequence is drawing a rectangle. The coordinate origin is at the bottom left corner of the page and units are twips. Note both rectangles have the same size but different origins. The first rectangle is drawing the frame background; its origin is 1/2 inch right and down from the top left corner of the page, which corresponds to the margin in File->Page Setup->Margins & Header/Footer. The second rectangle is the clipping region and it's missing this offset.

For the attached image, I altered the PS a bit. The first rectangle is drawn as a blue line and the second is drawn as a red line.
I'm also seeing chopped off text in 1.7.11(Win32) on Windows 2000.
I don't find this issue in http://www.mozilla.org/releases/mozilla1.7.11/known-issues.html, so I'm reporting it here, hoping this bug is the correct one to add to.

When trying to print e.g. http://en.wikipedia.org/wiki/Software_patents_under_TRIPs_Agreement on a HP LaserJet 4MV (PS), some text is cut off at the right.

*Sometimes* it helps to adjust the scale manually because word wraps are then placed differently.

It seems the run length of <b> and <i> text is not calculated correctly, as I also see some bold stuff (e.g. some links) exceed their run length and extend into the normal text following them.

MOW
By the way, is this somehow a duplicate of bug 84223 or is this completely new and just produces similar results?

MOW
Attached patch easy fixSplinter Review
Very simple fix ... the clip rects are in frame-relative coordinates, they need to be converted to absolute coordinates.
Attachment #210821 - Flags: superreview?(dbaron)
Attachment #210821 - Flags: review?(dbaron)
Attachment #210821 - Flags: superreview?(dbaron)
Attachment #210821 - Flags: superreview+
Attachment #210821 - Flags: review?(dbaron)
Attachment #210821 - Flags: review+
You might want to check if that patch fix the clipping issues related to printing selections; it looks like it doesn't, although I could be wrong.  It's not as simple as the coordinates being relative to the frame, I think because of the oddities of the view manipulation.  It also might be worth noting that the old code used nsClipCombine_kReplace, although I'm not sure how much that matters.

I actually was looking at this, and started into a patch to just zap all this clipping stuff, since as far as I can tell it doesn't do anything useful that clipping the nsPageContent frame to its boundaries doesn't do; I'm not finished with that, though; I'll probably put it in another bug.

I'm worried I'm missing something, though, because it's all horribly documented and doesn't really make sense to me.
Now that you mention it, yes, the frame display lists patch completely busted the selection-printing stuff in nsSimplePageSequenceFrame::PrintNextPage, and this patch doesn't fix it. But I'll check this patch in anyway. Let's have another bug about selection printing.
checked in
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.