Closed
Bug 238591
Opened 20 years ago
Closed 19 years ago
Extreme scaling pages gives improper printouts
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
EXPIRED
People
(Reporter: sgupta, Unassigned)
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 When a page is printed with extreme scaled values the printout is not as expected (clipped or missing data). (refer attachment) Also the scale input fields in 'Print Preview' and 'Page Setup' are not synchronized. (refer attachment) Reproducible: Always Steps to Reproduce: 1.On the print preview page, select the custom scaling option on the top center of the menu bar. Select the custom option and enter any value above 500. Now visit the page setup option on the top left corner of the menu bar and check for the scale input field.(make sure that shrink to fit page is unchecked) *You will notice that the two values are different. 2. Set the scale size to 500% from the page setup option and send the page(s) to print. *The resulting printout will be incomplete. 3. Set then scale size to 10% from the page setup option and sent the page(s) to print. *The resulting printout will miss out certain content. This misbehavior can be observed even if the ‘Print background’ option is checked or unchecked. Actual Results: 1. The scale values from the custom option on print preview is different from the one that is stored in the page setup option. However if the scale value is changed from the page setup option then the value in the custom option in the print preview is the same. (refer attachment) 2. The resulting printout misses a lot of content, rather only left most area of the web page that can fit on a single page is printed page by page. The remaining is just simply left out. 3. The resulting printout misses a lot of detail and data. Expected Results: 1. The two scale input fields should have the same value irrespective from where they are set. 2. The scaled page should be printed as expected (presumably spanned across a few pages). 3. The scaled page should be printed with the content in the right location (presumably very small), but not missing. Follow up tests: ---------------- 1. Replicated the same bug for small pages and pages with lesser content, however the problem persisted. 2. Replicating the same steps on I.E. did not reproduce the bug. I.E. allows the print preview to range from 10% to 500% but the resulting printout is well within and as per the margins specified. (In a way I.E. imposes constraints on the way a page can be printed to avoid such issues). Importance of the bug ---------------------- 1. Since Firefox is not an image editor, one would not expect it to fulfill the requirements and expectations that an image editor would have. However being able to manipulate printouts (scaling factor) by changing the scale and then receiving unexpected output by being able to print the change (no constraints like I.E.) leaves Firefox in the middle of providing an additional feature but not being able to fulfill the expectation from that feature.
Reporter | ||
Comment 1•20 years ago
|
||
This is an example of the synchronization of values between the two scale input fields that is discussed in the bug report.
Reporter | ||
Comment 2•20 years ago
|
||
This snapshot shows that the scaled (500%) page prints out exactly what is shown on the print preview and just forgets (leaves off) the rest of the page.
Reporter | ||
Comment 3•20 years ago
|
||
This snapshot shows that the webpage that gets printed has missing data (exactly as shown in the print preview).
Updated•20 years ago
|
Severity: normal → minor
Component: General → Printing
Product: Firefox → Browser
Version: unspecified → Trunk
Updated•20 years ago
|
Assignee: firefox → core.printing
Comment 4•19 years ago
|
||
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 5•19 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•