128008 - [FIX]RFE: Enable "Shrink to page width" by default

Status: VERIFIED FIXED

(Core :: Printing: Output, enhancement, P1)

Description

[Roland Mainz]

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...

Comment 1

[rods (gone)]

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.

Comment 2

[Roland Mainz]

Users can always turn the feature OFF when they want to print "faster"... :)

Comment 3

[rods (gone)]

The average user (mom & pop) typically aren't technical to do this, or even
understand this.

Comment 4

[Alex Bishop]

Mom and pop aren't going to understand why they're missing the right-hand part
of their page either.

Comment 5

[Roland Mainz]

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...

Comment 6

[Peter Trudelle]

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. 

Comment 7

[Todd Pringle]

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?  

Comment 8

[marlon bishop]

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.  

Comment 9

[Roland Mainz]

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)...) ... ;-(

Comment 10

[rods (gone)]

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)

Comment 11

[Kevin McCluskey (gone)]

Bulk moving all nsbeta1 nominations to future-P1. If they are approved
(nsbeta1+) they will be moved to mozilla1.0

Comment 12

[Kevin McCluskey (gone)]

nsbeta1+

Comment 13

[rods (gone)]

Attachment: patch

Just changing its initialization from PR_FALSE to PR_TRUE

Comment 14

[Kevin McCluskey (gone)]

Comment on attachment 75231 [details] [diff] [review]
patch

r=[e-mail]

Comment 15

[kinmoz]

Comment on attachment 75231 [details] [diff] [review]
patch

sr=[e-mail]

Comment 16

[Roland Mainz]

Just wondering (without testing):
Does that make the checkbox widget in the page setup dialog "checked" by
default, too ?

Comment 17

[rods (gone)]

yes it does, it is all pretty seemless - fixed.

Comment 18

[Alex Bishop]

> yes it does, it is all pretty seemless - fixed.

I hope you meant 'seamless'!

Comment 19

[sujay]

verified in 3/21 trunk build....

looks fixed to me.

Comment 20

[Syd Logan]

adt2 per adt triage (adding notation in case we need it)