Re: [Libreoffice-ux-advise] [PATCH] use a geometric progression for zooming

Hi Tim, Cor,

On 16 January 2012 12:35, Cor Nouws <oolst@nouenoff.nl> wrote:
> I am looking at the factor 1.2
> That means that when zoom is 100, the next will be 120.
> The sequence (if round in Calc does the same as in C++) would look like:
> 13>17>21>26>33>41>51>64>80>100>120>144>173>207>249>299>358>430>516>619>743>892
>
> IMO that leaps are too large, so I would advise 1.1 at most
> ( at the slider currently + / -  is 5%)
I don't really have a strong preference here.


> Factor 1.1 will give the sequence
> 39>43>48>53>59>66>73>81>90>100>110>121>133>146>161>177>195>214>236>259>285>314
>
> However, it results in numbers that might look weird to users ?
> Maybe a different algorithm / simply table giving steps is better for that?
> Hmm, how would that show for CTL languages?
The weird numbers do seem like a bit of a problem to me. With the
current implementation, it is hard to e.g. get to 50% zoom.
I think the calculation should be (heavily) biased towards certain
zoom levels that users will want more than others:
* fit width
* fit page (optimal)
* 10 %
* 25 %
* 50 %
* 75 %
* 100 %
* 150 %
* 200 %
* 250 %
* 400 %
* 500 %
* 1000 %
* 2000 %
* 3000 %

Additionally, it would be great, if we could always get to ...0% or
...5%, so here's an example for how the row could look (with 1.2):
5, 10, 25, 50, 75, 100, 120, 150, 175, 200, 210, 250, 300, 360, 400,
430, 500, 515... (fit width/fit page would be inserted depending on
the document)

with 1.1, it would be:
5, 10, 25, 50, 75, 100, 110, 120, 135, 150, 160, 180, 200, 250, 285, 315 ...

(I believe the value of 1.1 is better on the "magic"-numbers-insertion front)

Just two cents...
Astron.