|· Hosting provided by Anduin.net / Øverby Consulting ·|
|Anonymous | Login | Signup for a new account||2015-11-30 14:22 CET|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012195||Scribus||User Interface||public||2014-04-04 22:50||2015-11-14 19:55|
|Target Version||1.6 milestone||Fixed in Version|
|Summary||0012195: [PATCH] more progressive unzoom when < 100%|
|Description||Preference's dialog enable to set the zoom step that is used when increasing the soom level. When zoom is > 100%, the zoom step is added to the zoom value each time a zoom action is requested (mouse wheel or status bar action).|
This zoom step is also used when zoom < 100%, but not so directly. The effect is very sudden, it makes layout shrinkens too violently.
when step is 100%, zoom becomes 50%
when step is 200%, zoom becomes 33%
when step is 300%, zoom becomes 25%
when step is 400%, zoom becomes 20%
it seems to follow a rule like
"<=100% zoom becomes previousvalue x 100/(step+100)"
that is confirmed with following trial :
when step is 110%, zoom becomes 47.6%
For zoom <100%, it would be more smoother to have something like :
"<=100% zoom becomes previousvalue x 100/(step + 25)"
We would then have :
when step is 100%, zoom becomes 80%
when step is 200% zoom becomes 44.4%
when step is 300% zoom becomes 30,8%
when step is 400% zoom becomes 23,5%
that is smoother but still efficient
|Attached Files||fixed_zoom.diff [^] (1,390 bytes) 2015-11-02 11:26 [Show Content]|
AMOF the issue is more global.
Adding 100% when zoom is 10000% has much less visible effect then adding 100% when zoom is 100%
Insted of "additive step", the zoom step could be a multiplying factor or ratio.
User would state a step=150% and zoom would go from 100% to 150% to 225% etc, and from 10000% to 15000% which is sound. Sbd wanting quicker zoom change would choose 150% or 200%.
And going down would have the same softness and progressivity ; same formula would do for both >100% and < 100% zooms.
Very usefull too (even more ?), would be to listen to any modifier key being pressed while requesting some zoom change. SHIFT would make the step much smaller. CTRL would make the step much bigger.
|see also 0010171|
I solved the problem as JLuc proposed , please attach the patch.
|ibrahim, awesome! Will test and report feedback soon.|
edited on: 2015-10-30 22:26
I tested the patch.
In "Files > Document's settings > Operator's tools" i've set a zoom step of 20%.
Zooming down off 100% is ok : 80% 60% 40% but then it gets a bit crazy for smaller zoom values (maybe between 0 and 25%, because zoom becomes negative sometime ? that's just a guess ): zooming IN or OUT become mixed. Sometime zooming in does zoom out and sometimes zooming out does zoom in. Plz test and correct these issues.
Besides, for the 40% to 10000% where it works, i see you have kept an additive way of changing the zoom. I strongly suggest you choose a multiplicative way of zooming or unzooming, as explained in comment http://bugs.scribus.net/view.php?id=12195#c31631 [^]
When step is 20%, zooming from 123% would means changing to 123x1.20=148%,
and unzooming from 123 would mean changing to 123/1.2=102.5%
Sorry for that,
I fixed the issue and tested. You can check it now.
the related ticket 0010171 that you already had a look at, has some more ideas on how to improve the zoom.
personally, having read both this ticket and the other one, i would try to go for a list fixed step for the well known ones.
when you zoom in and out... i think that you want to land to 100% at some time... from whatever you started...
my proposal was to have "100 125 150 175 200 225 250 275 300 ..." on the one side and "100 75 50 25" on the other.
i think that we should try to match those steps and, outside of those values, use the algorithm jluc is suggesting.
once this is in place it will be easy to define different fixed steps if somebody comes up with better ones!
this means that if you're at 99% and zoom out you will land at 100%, then 125% and so on.
i guess that -- if nobody has something against it -- we should then remove the setting in the preferences.
i would love to hear what vlada and manuel have to say about it.
|Ale, set the prefs stepping to 25% and it goes 50,75,100,125,150,175,200,225,250,275,300 already|
@cbradney: yes, 25% seems sensible to me.
but people seem not to like the fact that you have only one step for both the cases below 300 and above 300.
the other issue (at least for me) is that if for any reason you get to unusual values (fit to width, zoom to an area) you don't automatically get back to the nice steps you list above.
anyway, if everything else fails: can we haz 25% has a default instead of 100%?
but i really wonder if we should not have fixed "default" steps between the values mentioned above (and some % step ouside of those boundaries).
not sure if the fact of being able to set a custom value in the preferences is really helpful in this case.
Ibrahim : Your patch provides more friendly zooming.
However, why do you use 400 as a factor in your scaling computations ?
100 would be more simple and user understandable, isnt ?
Beside, why did you delete the maximum and minimum checks ?
It seems these controls are still enforced : they are controled in some other place ?
To MrB or jghali : scribus 1.5 zooming adds a fixed step to the current zoom. Lest suppose that step is 25%.
For close to 100% zooms, adding or substracting this step enables to zoom or unzoom correctly.
For very big zooms, adding this steps does allmost nothing : going from 5000 to 2025 is a very little change. And it takes loooots of zooming to get to 6000.
For small zoom values, it looks like scribus allready does some adapting.
The proposed patch proposes a way of zooming and unzooming proportionnaly. Each zoom makes scale biger or smaler with the same factor.
edited on: 2015-11-04 09:54
jluc are you really sure that you don't want some nice friendly steps in the "normal" zoom boundaries (~ 10% to 300%)? a 25% step seems to be much friendlier than some "random" calculated values...
please have a look at libre office, firefox and probably also the other DTP package and see how much smoother it is, if you get nicely rounded values...
it's mostly psychological, but IMO it's a tiny contribution to a more simple UI...
outside of those "sane" boundaries (which are useful in DTP but not in other software) a different algorithm might be appropriate.
but for the normal cases i'm really convinced that scribus should "enforce" those steps.
1) it seems scribus allready adapts its process when reaching very small values, because it became obvious that additive steps is not appropriate.
2) for sure, scribus additive zoom step makes it allmost not possible to reach big zoom values using the mouse.
3) additive zoom steps are inappropriate for both big and small values
Conclusion is :
4) scribus should also adapt its zooming steps for big zoom values
5) multiplying step zoom is ok for both big and small zoom values
6) Whatever the exact values, its not an issue. What matters is user experience. User *never has to* look to the exact value unless he wants to for some specific purpose where he can choose and force any value fine.
7) Hence, multiplying step zoom ok also for middle range zoom value
But i know ale we don't have the same approach of sanity.
users do not have to look at the exact value, but users *will* look at it and try to make it nice.
this is how users work.
and having values that they experience as random drives them crazy.
if we can easily avoid that, we should also do it!
sadly, 6) and 7) in your list seem to be wrong conclusions, since nobody does it that way and scribus had that behavior in the past but (iirc) moved away from it at the request of somebody who is mostly very right when UI/UX issues arise.
btw, the sane boundaries mentioned above, have nothing to do with me and you not having the same approach to sanity.
in normal life, you will never look at a document at 2000%. you range will probably vary from 25% to about 300%.
this is also valid for DTP.
but in DTP you (and i!) sometime want to look at the detail that is only visible on paper and at 2000% (but not normally on the monitor).
so, yes, scribus should give a good user experience when zooming at very high level! (while firefox or libre office do not need to do that).
but it's nice to see that you keep on disagreeing for the sake of disagreeing!
edited on: 2015-11-05 14:10
I did create that report and i keep agreeing with it.
|Indeed, I agree with ale that Scribus is a software not like adobe fotoshop that you need to reach zoom 2000 always. We can compare Scribus with liber Office that rarely we need to reach zoom 2000. However, In zooming out for the scale less than 100 it is good Idea to make the zoom more smoother( as JLuc suggest).|
|2014-04-04 22:50||JLuc||New Issue|
|2014-04-06 11:50||JLuc||Note Added: 0031631|
|2014-04-07 17:19||JLuc||Note Added: 0031640|
|2014-07-02 03:54||Kunda||Relationship added||related to 0010171|
|2014-07-02 03:55||Kunda||Target Version||=> 1.6 milestone|
|2014-09-19 00:16||Kunda||Relationship added||related to 0010824|
|2014-09-19 00:17||Kunda||Relationship added||related to 0004235|
|2015-10-25 05:46||ibrahim||File Added: updated_zoom.diff|
|2015-10-25 05:49||ibrahim||Note Added: 0036902|
|2015-10-25 13:59||Kunda||Patch||=> Yes|
|2015-10-25 13:59||Kunda||Summary||more progressive unzoom when < 100% => [PATCH] more progressive unzoom when < 100%|
|2015-10-25 13:59||Kunda||Note Added: 0036910|
|2015-10-26 08:49||ibrahim||Tag Attached: HOST-Oman|
|2015-10-30 22:22||JLuc||Note Added: 0037128|
|2015-10-30 22:25||JLuc||Note Edited: 0037128||View Revisions|
|2015-10-30 22:26||JLuc||Note Edited: 0037128||View Revisions|
|2015-11-02 11:23||ibrahim||File Deleted: updated_zoom.diff|
|2015-11-02 11:26||ibrahim||File Added: fixed_zoom.diff|
|2015-11-02 11:28||ibrahim||Note Added: 0037150|
|2015-11-02 15:05||ale||Note Added: 0037152|
|2015-11-02 17:25||cbradney||Note Added: 0037153|
|2015-11-03 23:03||ale||Note Added: 0037203|
|2015-11-04 00:04||JLuc||Note Added: 0037207|
|2015-11-04 00:13||JLuc||Note Added: 0037208|
|2015-11-04 09:54||ale||Note Added: 0037211|
|2015-11-04 09:54||ale||Note Edited: 0037211||View Revisions|
|2015-11-04 16:12||JLuc||Note Added: 0037219|
|2015-11-05 11:41||ale||Note Added: 0037252|
|2015-11-05 13:23||Kunda||Sticky Issue||No => Yes|
|2015-11-05 13:45||JLuc||Note Added: 0037259|
|2015-11-05 14:10||JLuc||Note Edited: 0037259||View Revisions|
|2015-11-05 15:58||ale||Relationship added||child of 0013502|
|2015-11-14 19:55||ibrahim||Note Added: 0037487|
|My View | View Issues | Change Log | Roadmap|
|Copyright © 2000 - 2015 MantisBT Team|