Currently the zoom UI provides for only 2 steps zooming out and 3 zooming in. I think the maximum zoom out is probably about right, but we need more steps in between 1 and 0.5. The maximum zoom in is perhaps too far for my taste but I am less interested in that, but that also could do with more steps. I would suggest maybe 5 steps in each direction. I am using 0.5,0.6,0.7,0.8,0.9, 1 as the zoom out settings and that seems to give me all the zooms I need for my pages. I'm classing this as a regression since text zoom gave better control than page zoom does currently. Apparently this requires bug 381661 for the zooming in case.
Note that mouse wheel scrolling makes 0.1 steps right now.
(In reply to comment #1) > Note that mouse wheel scrolling makes 0.1 steps right now. There is no mouse scrolling on mac
Also, the scroll wheel of a Wacom Graphire4 tablet sucks and cannot compare to a mouse wheel. Having a mouse just for the sake of a wheel is not worth it.
I'm also somewhat dubious on the idea of providing more control over an assistive technology only to those able to use a mouse ;)
(In reply to comment #2) > (In reply to comment #1) > > Note that mouse wheel scrolling makes 0.1 steps right now. > > There is no mouse scrolling on mac Ignore that, turns out it totally works if you disable the system preference that makes OSX take over the ctrl-scroll effect.
6 zoom steps would be about right.
-> beltzner to figure out appropriate values
6 zoom steps are __far__ too less. I use the following steps: two successive values have the ratio of 1.1, starting with .5: ".5, .55, .6, .67, .74, .82, .9, 1, 1.1, 1.21, 1.34, 1.48, 1.64, 1.81, 2, 2.2, 2.43" ok, if ratio 1.1 produces too many steps, increase it slightly. but i've tested it: it's not too many steps! it's very usable. but please! what should be the use of "human readable" zoom steps, like ".5, .75, 1, 1.25, 1.5" ??? check the ratios: "1.5 1.333 1.25 1.2" - wow! the usability is important, not that!
I have to apologize. In my last comment, I said that successive values have a ratio of 1.1, which is not exact. Instead, the correct algorithm for those values is the following python script: >>> for x in range(-7,10): ... print int((2.0**(x/7.0))*100)/100.0, 0.5 0.55 0.6 0.67 0.74 0.82 0.9 1.0 1.1 1.21 1.34 1.48 1.64 1.81 2.0 2.2 2.43 or, one might want to increase the step size slightly: >>> for x in range(-5,8): ... print int((2.0**(x/5.0))*100)/100.0, 0.5 0.57 0.65 0.75 0.87 1.0 1.14 1.31 1.51 1.74 2.0 2.29 2.63 Note: the not-so-clear formula results from the fact, that the range function in python doesn't accept floating-point steps
I suggest that the algorithm and pref setting be changed so that an increment/decrement step can be specified instead of a sequence of possible zoom values. And this setting should be accessible to normal people (those who don't use about:config). But if the current algorithm and pref settings remain, then I'd like to see the step to be no larger than 0.1. The step that was used for text zoom in FF 2 was too large. I've often struggled between too big and too small characters.
Created attachment 305563 [details] [diff] [review] patch: 0.5, 0.66, 0.8, 0.9, 1, 1.1, 1.2, 1.33, 1.5, 1.7, 2, 2.4, 3
(In reply to comment #0) > I think the maximum zoom out is probably about right... I disagree. And the case I'll point to is the tinderbox page. Zooming out on that is great on branch. I can fit all of the columns with four or so zooms out (depending on my window size). With Minefield, two gets me about half way there. Is there a technical reason why we wouldn't want to allow users to zoom out further? (i.e., we know there are serious performance issues with doing so.)
ditto comment 15. I may not be able to _read_ tinderbox after hitting Ctrl+- five times on the branch, but at least I can keep an eye on the tree state without horizontal scrolling.
Well, the tinderbox page is an extreme example, and not an important one, given that Mozilla devs know about hidden prefs :) Are there more examples that you could think of?
Another vote for finer increments for zoom. The current jump from 1 to 1.2 is too much - we need 1.1. Dão Gottwald's patch is perfect. Make it so, number one.
Comment on attachment 305563 [details] [diff] [review] patch: 0.5, 0.66, 0.8, 0.9, 1, 1.1, 1.2, 1.33, 1.5, 1.7, 2, 2.4, 3 r+ui-r=beltzner I'm assuming .5 is as low as we can go? If not, I think we might want to step it down another notch to .33 as well.
0.3 is the next logical step, but zoom.minPercent needs to be modified for that.
Created attachment 308975 [details] [diff] [review] for checkin
Sure. When I tried that on my computer I got this strange "fight" happening between mouse scrolling and the +/- buttons, where when I used mouse scrolling it would get smaller and then spring back larger again. Is that a known issue?
That's happening if you change the pref without restarting the browser. See bug 418468.
Checking in modules/libpref/src/init/all.js; /cvsroot/mozilla/modules/libpref/src/init/all.js,v <-- all.js new revision: 3.735; previous revision: 3.734 done