Date: prev next · Thread: first prev next last
January 2012 Archives by date, by thread · List index


Hi Cor,

thanks for your input. 1.1  is Ok but the scrolling effort needed would be doubled. Since the mouse 
wheel is pretty fast it should be still fine though.

The problem is that if you start from a manual set zooming level or the full page zoom like for 
example 66% the values are different then the one you calculated.

So I have created some stimple functions which round against a multiple.
I thought that below 50 isn't rounded because the steps should be small. After 50 it is rounded 
against the multiple of 5. After 100 against 10, 500 against 50 and 1000 against 100. This creates 
nice values and still bases on a geometric progression.
To have one fix point I have added a check to make sure that when going above or below 100, it is 
always used as one step, independent of the prior distance. This should normalize all steps 
afterwards.

The multiple values might be adjusted a little bit if we use 1.1 but it would be still fine I 
suppose. Starting with 50 it would be 55, 60, 65, 70, 75, 85, 95, (100) and so on.

So what do you think?

Regards
Tim


On Monday 16 January 2012 12:35:06 Cor Nouws wrote:
Hi Tim,

Tim Hardeck wrote (14-01-12 18:21)

I have created a patch to address fdo#44173.

Zooming does now base on a geometric progression instead of an
arithmetic one. Since the zoom factor is not only used in Draw but
for all other applications 1.2 seems like a good choice but the value
could be easily changed in one place.

Thanks - useful idea :-)

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%)

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 change does not only influence mouse zooming but also the plus
minus slider buttons.

The patch should be already committed so you can test it with a
current git version.

(I did not test it yet, just imagined how it would behave)

Cheers,



-- 
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
T: +49 (0) 911 74053-0  F: +49 (0) 911 74053-483
http://www.suse.de/

Attachment: signature.asc
Description: This is a digitally signed message part.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.