View Issue Details

IDProjectCategoryView StatusLast Update
0012195ScribusUser Interfacepublic2019-02-13 13:29
ReporterJLuc Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version1.5.0svn 
Target Version1.6 milestoneFixed in Version 
Summary0012195: [PATCH] more progressive unzoom when < 100%
DescriptionPreference'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

TagsHOST-Oman, zoom
PatchYes

Relationships

related to 0010824 new there is odd terminology in setting the Zoom Stepping 
related to 0004235 new More options for the page viewing and zooming 
related to 0010171 confirmed Default zoom stepping to big 
child of 0013502 new fixed zoom steps between 5 and 400%, proportional steps outside of it 

Activities

JLuc

2014-04-06 09:50

developer   ~0031631

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.

JLuc

2014-04-07 15:19

developer   ~0031640

see also 0010171

ibrahim

2015-10-25 04:49

reporter   ~0036902

Hello,
I solved the problem as JLuc proposed , please attach the patch.

Kunda

2015-10-25 12:59

manager   ~0036910

ibrahim, awesome! Will test and report feedback soon.

JLuc

2015-10-30 21:22

developer   ~0037128

Last edited: 2015-10-30 21:26

View 3 revisions

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%

ibrahim

2015-11-02 10:26

reporter  

fixed_zoom.diff (1,390 bytes)
Index: scribus/scribusview.cpp
===================================================================
--- scribus/scribusview.cpp	(revision 20493)
+++ scribus/scribusview.cpp	(working copy)
@@ -2344,9 +2344,7 @@
 	}
 	else
 		rememberOldZoomLocation(mx,my);
-	double newScale = m_canvas->scale() * (1 + static_cast<double>(Doc->opToolPrefs().magStep)/100.0);
-	if(static_cast<int>(newScale*100)>static_cast<int>(100 * static_cast<double>(Doc->opToolPrefs().magStep)*Prefs->displayPrefs.displayScale/100))
-		newScale = m_canvas->scale() + static_cast<double>(Doc->opToolPrefs().magStep)*Prefs->displayPrefs.displayScale/100;
+	double newScale = m_canvas->scale() * (1 + static_cast<double>(Doc->opToolPrefs().magStep)/400.0);
 	if (Doc->m_Selection->count() != 0)
 	{
 		PageItem *currItem = Doc->m_Selection->itemAt(0);
@@ -2372,10 +2370,8 @@
 	}
 	else
 		rememberOldZoomLocation(mx,my);
-	double newScale = m_canvas->scale() - static_cast<double>(Doc->opToolPrefs().magStep)*Prefs->displayPrefs.displayScale/100;
+	double newScale = m_canvas->scale() / (1+  static_cast<double>(Doc->opToolPrefs().magStep)/400.0);
 	if(newScale<=Prefs->displayPrefs.displayScale/100)
-		newScale = m_canvas->scale() / (1 + static_cast<double>(Doc->opToolPrefs().magStep)/100.0);
-	if(newScale<=Prefs->displayPrefs.displayScale/100)
 		newScale = m_canvas->scale();
 	if (Doc->m_Selection->count() != 0)
 	{
fixed_zoom.diff (1,390 bytes)

ibrahim

2015-11-02 10:28

reporter   ~0037150

Sorry for that,

I fixed the issue and tested. You can check it now.

ale

2015-11-02 14:05

manager   ~0037152

hi ibrahim,

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.

cbradney

2015-11-02 16:25

administrator   ~0037153

Ale, set the prefs stepping to 25% and it goes 50,75,100,125,150,175,200,225,250,275,300 already

ale

2015-11-03 22:03

manager   ~0037203

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

JLuc

2015-11-03 23:04

developer   ~0037207

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 ?

JLuc

2015-11-03 23:13

developer   ~0037208

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.

ale

2015-11-04 08:54

manager   ~0037211

Last edited: 2015-11-04 08:54

View 2 revisions

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.

JLuc

2015-11-04 15:12

developer   ~0037219

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.

ale

2015-11-05 10:41

manager   ~0037252

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!

JLuc

2015-11-05 12:45

developer   ~0037259

Last edited: 2015-11-05 13:10

View 2 revisions

I did create that report and i keep agreeing with it.

ibrahim

2015-11-14 18:55

reporter   ~0037487

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

PeterBenedek

2019-02-13 11:00

developer   ~0045896

Last edited: 2019-02-13 13:29

View 2 revisions

Only an idea

The xnview does it:
Zoom values (these fix value): 1%, 2%, 3%, 4%, 5%, 7%, 9%, 13%, 18%, 26%, 36%, 51%, 71%, 100%, 142%, 200%, 283%, 400%, 566%, 800%, 1132%, 1600%
The user can type the value in zoom box 1% between 1600% (min.-max. value)
If the user write a value in zoom box and he click after the up or down button, the Xnview to the next value.

1. example:
Zoom start value: 26%
The user write in the zoom box: 32%
The user clicks the down button: the following zoom value 26%

2. example:
Zoom start value: 26%
The user write in the zoom box: 32%
The user clicks the up button: the following zoom value 36%

If the user clicking in the zoom box and press up or down key button, the zoom box value grow or decrease one value.

This one simple and beautifull solution.
Is it hard to do this?

Issue History

Date Modified Username Field Change
2014-04-04 20:50 JLuc New Issue
2014-04-06 09:50 JLuc Note Added: 0031631
2014-04-07 15:19 JLuc Note Added: 0031640
2014-07-02 01:54 Kunda Relationship added related to 0010171
2014-07-02 01:55 Kunda Target Version => 1.6 milestone
2014-09-18 22:16 Kunda Relationship added related to 0010824
2014-09-18 22:17 Kunda Relationship added related to 0004235
2015-10-25 04:46 ibrahim File Added: updated_zoom.diff
2015-10-25 04:49 ibrahim Note Added: 0036902
2015-10-25 12:59 Kunda Patch => Yes
2015-10-25 12:59 Kunda Summary more progressive unzoom when < 100% => [PATCH] more progressive unzoom when < 100%
2015-10-25 12:59 Kunda Note Added: 0036910
2015-10-26 07:49 ibrahim Tag Attached: HOST-Oman
2015-10-30 21:22 JLuc Note Added: 0037128
2015-10-30 21:25 JLuc Note Edited: 0037128 View Revisions
2015-10-30 21:26 JLuc Note Edited: 0037128 View Revisions
2015-11-02 10:23 ibrahim File Deleted: updated_zoom.diff
2015-11-02 10:26 ibrahim File Added: fixed_zoom.diff
2015-11-02 10:28 ibrahim Note Added: 0037150
2015-11-02 14:05 ale Note Added: 0037152
2015-11-02 16:25 cbradney Note Added: 0037153
2015-11-03 22:03 ale Note Added: 0037203
2015-11-03 23:04 JLuc Note Added: 0037207
2015-11-03 23:13 JLuc Note Added: 0037208
2015-11-04 08:54 ale Note Added: 0037211
2015-11-04 08:54 ale Note Edited: 0037211 View Revisions
2015-11-04 15:12 JLuc Note Added: 0037219
2015-11-05 10:41 ale Note Added: 0037252
2015-11-05 12:23 Kunda Sticky Issue No => Yes
2015-11-05 12:45 JLuc Note Added: 0037259
2015-11-05 13:10 JLuc Note Edited: 0037259 View Revisions
2015-11-05 14:58 ale Relationship added child of 0013502
2015-11-14 18:55 ibrahim Note Added: 0037487
2016-05-26 13:38 Kunda Tag Attached: zoom
2019-02-13 11:00 PeterBenedek Note Added: 0045896
2019-02-13 13:29 PeterBenedek Note Edited: 0045896 View Revisions