RFE: It may be a good idea to enable the "Shrink to page width" by default - it looks we have many pages where content get's cut at the right border - and it is always a bad user experience when parts of the page content "disappears" on the printout...
Hmmmm, we have debated that.... It is more expensive and slows printing to have to always check to see if it "should" be shrunk. Of coarse, the most expensive part is reflowing the document a second time.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.0
Users can always turn the feature OFF when they want to print "faster"... :)
The average user (mom & pop) typically aren't technical to do this, or even understand this.
Mom and pop aren't going to understand why they're missing the right-hand part of their page either.
Question is: What's better ? a) Loosing parts of the data in the printout (e.g. at the right border) OR b) Slighly slower printing [a] is a quite bad user experience, I would prefer [b] for now...
It ain't just Mom & Pop; my focal review has the right edge cut off and neither me nor my manager can understand why. I would estimate that wanting the document to fit the page width is the 99.44% case, and should certainly be on by default, as long as there is no major detriment when the page doesn't actually need shrinking. cc marlon for UE input, nominating for nsbeta1.
I tend to agree with Peter, my guess is that the correctness gain exceeds the performance loss here. It seems like a large percentage of documents NEED to be shrunk. Rod, could you be more specific about the performance impact here - i.e. printing a 3 page doc now takes 5 minutes versus 1 minute?
i would say a safe determination could be made by printing the top 100 sites, and every one of them required it on to print correctly and still *comfortably* on 8x11 with standard margins. We want to be concerned about text size. Users still need to read their print-outs, which is why i was hopeful about having a print typeface size setting, which would allow you to keep text at the legible 11pt or 12pt setting, while reflowing and squishing everything else.
Slightly off-topic: > i would say a safe determination could be made by printing the top 100 sites This will never work - we usually crash in layout/, content/ or somewhere else while trying to print the "top 100" pages (I would say we can only print around 70 of the 200 URLs (normal+i18n) there (but I never did statistics about the crashes, I only restarted my bot of the remaining URLs)...) ... ;-(
I took this page http://www.w3.org/TR/REC-CSS2/ which normally prints out as 10-11 pages and added a pre tag line of text just wide enough to have it go into shrink to fit. Printing went from 6.32 to 7.39 (17%) www.cnn.com went from 2.82 to 4.31 www.msn.com went from 2.07 to 3.06 (wall clock timings)
Bulk moving all nsbeta1 nominations to future-P1. If they are approved (nsbeta1+) they will be moved to mozilla1.0
Target Milestone: mozilla1.0 → Future
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla1.0
Created attachment 75231 [details] [diff] [review] patch Just changing its initialization from PR_FALSE to PR_TRUE
Summary: RFE: Enable "Shrink to page width" by default → [FIX}RFE: Enable "Shrink to page width" by default
Comment on attachment 75231 [details] [diff] [review] patch firstname.lastname@example.org
Attachment #75231 - Flags: review+
Comment on attachment 75231 [details] [diff] [review] patch email@example.com
Attachment #75231 - Flags: superreview+
Summary: [FIX}RFE: Enable "Shrink to page width" by default → [FIX]RFE: Enable "Shrink to page width" by default
Just wondering (without testing): Does that make the checkbox widget in the page setup dialog "checked" by default, too ?
yes it does, it is all pretty seemless - fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
> yes it does, it is all pretty seemless - fixed. I hope you meant 'seamless'!
verified in 3/21 trunk build.... looks fixed to me.
Status: RESOLVED → VERIFIED
adt2 per adt triage (adding notation in case we need it)
Whiteboard: [adt2] per adt triage
You need to log in before you can comment on or make changes to this bug.