i received a large jpg file as an attachment in email. I double-clicked the attachment to open it in a new browser window. When I tried to print the image which was about 2x2 pages large, Netscape6 only printed the first page. It didn't try to scale the image to fit on one page NOR did it print the other pages that make up the total image. RFE: The "fit to 1 page" option is missing (compared to Netscape 4.x) BUG: When an image (or html page) is larger than one piece of paper, the browser needs to print everything instead of cropping.

Kevin, was this one of the PRD items? It seems familar?

I think this could be part of the PRD item to force output to specified number of pages.

Which bug is 'the PRD item to force output to specified number of pages'? bug 84223 has been looking for a home for a while, and might be a DUP. Or this bug is a DUP of bug 84223 (albeit with a better summary).

*** Bug 113398 has been marked as a duplicate of this bug. ***

The bug part of this is fixed by bug 110529 - don't have perms to change the Summary.

Moving to Moz1.0. Rod will analyze how difficult it will be to implement this.

*** Bug 116553 has been marked as a duplicate of this bug. ***

This would be nice to have on all platforms not only Windows2000

Marking nsbeta1+

1) In DocumentViewer: I did rearrange some of the data members for PrintData and PrintObject and their initialization order 2) In DocumentViewer: Implemented the shrink to fit feature by calc'ing the ratios in the first reflow and then reflowing a second time to shrink them 3) In nsPageFrame: This is somewhat unrelated to this bug, but I found where continuing frame content was being parented to the PageFrame instead of the PageContentFrame. 4) Although at this time I am not using DumpFrames for debugging I may want to switch back to it while debugging at anytime.

Comment on attachment 69664 [details] [diff] [review] patch I would prefer something besides XMost.. I dont know what that means. r=dcone.

Comment on attachment 69664 [details] [diff] [review] patch Why did you reimplement RootFrameList? Can't you just call the static on on nsIFrameDebug? In the code where you are doing he shrinking, you are assuming that there will be an HTML frame (asserted) - what about XML? Did you test this with XML (looks like it will work, but the assertion/comment is wrong)? When looking for the XMost frame, don't you need to check for whether or not it is visible? If you had a hidden frame that was way off to the right it would skew the scaling factor I think. What is FindXMostPO() and why is it needed?

Good catch on the visibility, I created a new testcase, and you were right, so I added the vis code and now it prints correctly. I couldn't use nsIFrameDebug::RootFrameList because DocViewer is in content and it fails on link, so only layout classes can use it. It does print XML so I changed the comment. The meaning of FindXMostPO() is briefly explained where it is defined, it finds the widest or XMost PrintObject that contains the XMost or widest layout frame.

Comment on attachment 69698 [details] [diff] [review] new patch (checks for visibility) I would prefer MaxXWidth of XMost but not a big deal. r=dcone

Comment on attachment 69698 [details] [diff] [review] new patch (checks for visibility) sr=attinasi - thanks Rod

fixed

there is a new "Shrink to fit page width" option in Page Setup. Thus this bug has been addressed. REOPEN if you disagree..