View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012195 | Scribus | User Interface | public | 2014-04-04 20:50 | 2024-01-02 19:22 |
| Reporter | JLuc | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Product Version | 1.5.0svn | ||||
| Target Version | 1.6 milestone | ||||
| 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 | ||||
| Tags | HOST-Oman, zoom | ||||
| Patch | Yes | ||||
|
|
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 |
|
|
Hello, I solved the problem as JLuc proposed , please attach the patch. |
|
|
ibrahim, awesome! Will test and report feedback soon. |
|
|
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% |
|
|
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)
{
|
|
|
Sorry for that, I fixed the issue and tested. You can check it now. |
|
|
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. |
|
|
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. |
|
|
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! |
|
|
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). |
|
|
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? |
| 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 | |
| 2015-10-30 21:26 | JLuc | Note Edited: 0037128 | |
| 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 | |
| 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 | |
| 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 | |
| 2024-01-02 19:22 | cbradney | Sticky Issue | Yes => No |
