Zoom Suggestion

Previous topic - Next topic


Ive only started with Scribus and it has been a pleasure learning.

Here is an idea which may not have been considered yet.   8)  In addition to the standard 50% , 75% , 100% zoom, could their be a 'zoom to selected' option?  Let us say I selected a text or image box, the window would expand to that selected object.

My drawing app (coreldraw) has this feature and I use it often.

My first 'puter was a 286,
My first dtp was Aldus Pagemaker,
My first printer was a Little Squirt,
My first car was a motorbike.


hi ged

on the one side i can only support that idea. zooming to (the width of / the height of) the selected item is something really useful.
even if personally, a strong need for it... why?
could it be, that the feature is more useful for vector graphics than it is for layouting?
does it really need to be a new feature by itself?

you probably guess that i will be getting to the "on the other side"...

on the other side, i fear a bit that the feature will be hard to discover, will be placed somewhere deep in the menus, and will probably get a shortcut that is hard to remember.

scribus, like most other programs, has a rather powerful way to fast zoom in and out: pressing the ctrl key and turning the mouse wheel.
this is is a standard behavior somebody can use in most programs, from office to web browsers.
even if many people don't know about it it's there. and behaves mostly the same.

personally, i'd prefer focusing on improving that feature (like adding extra steps for fitting width and height of the selected object when zooming in and out; but also improving the center of the zooming), rather than adding a new feature and a new shortcut.

ged, could such a change improve your scribus experience?

what do other people think about it?
does it break too much the zooming effect?
is it worth?

for the coding, i think that it should be a feature that is rather easy to implement...
i could do it in a couple of hours. a team member can probably do it in less than an hour...

if there is an agreement on it, how should it exactly work?



I agree that a "zoom to selected" option would be a nice thing to have but I'm not sure I'd use it very often. I generally don't need to zoom in on only one thing. I usually need to zoom in to the area between two or more objects to adjust the spacing etc.

For me the basic thing to do would be to allow the user to set the zoom "step" in Preferences. E.g. Zoom in/out by 10%, or whatever. Only having "half" and "double" as they are at the moment is a bit limiting.

Also, it would be nice if the pages didn't shoot off to the left-hand side when zooming out. It's annoying.

I'm not sure what I'd prefer for centring during zoom. For the most part, centring the zoom about what's in the centre of the window is fine for me. Centring about the mouse pointer might cause me problems as I usually move the pointer out of the way when I'm scrutinising a document.

P.S. If anyone is wondering, Ctrl+Wheel for zoom is Cmd+Wheel on Macs. Ctrl+Wheel is the system zoom.


if i'm not mistaking, in 1.5svn there is a way to set the zoom steps (thanks to chelen).

the placement of the page might also have been fixed (basically, for me the zoom works ok in 1.5svn (but only with a mouse!), and i don't use 1.4.x enough to feel a difference).

(and i think that the ctrl-mouse wheel zoom should really center on the pointer! if you're scrolling the wheel, most of the time the pointer is at the right place :-)


hi garry

Quote from: GarryP on March 30, 2015, 01:56:24 PMI usually need to zoom in to the area between two or more objects...

it's the same for me – no need for a 'zoom to selection' function.

Quote...the basic thing to do would be to allow...

...Zoom in/out by 10%...

that's what the up and down arrows in the status bar do.

QuoteI'm not sure what I'd prefer for centring during zoom.

imho the best would be to center at the position of the pointer.



I didn't know there was a zoom on the mouse wheel until a.l.e mentioned it. I've just had a bit of a play around with it.

You're right that using the pointer position is best for that sort of thing. However, because the zoom steps aren't fine enough and the page moves around it's not quite right yet. Having to move my eyes up and down the screen for zooming - from page to the little arrows and back - makes my eyes tired because of all the refocussing. The same for when the page shifts around.

If the two things are fixed - as a.l.e says they probably will be in 1.5.0 - then I'll have to start using the wheel zoom more. It might help my old eyes.

Having said all of that, zooming from the toolbar can't use the mouse position (as it's on the toolbar) so there's probably an argument for adding some kind of "zoom to selected object's position if an object is selected" option. That would probably suit Ged's needs a bit too.


so, the status bar and keyboard (and eventually the toolbar) zooms should use the center of the selected item as a reference when zooming? (if any selected)

otherwise the center of the window?

personally, i don't like the fact that scribus has five ways to zoom. most of them rather poorly implemented...
probably, i'd like to see the zoom tool removed from the toolbar, the same for the two zoom icons in the status bar.
a zoom icon added to the status bar to allow the definition of a selection as the area to be defined as the zoomed one.

the we would have
- the +/- keys
- the mousewheel
- the spinbox where you can type a value and press on up and down buttons
- a tool to select a new visible area

do you see use cases that are not covered?

to me, the zooming is rather an important part of my interaction with the scribus UI and i would love it to see it implemented a bit more correctly.

ps.: for garry... since you seem not to know the powers of the mouse wheel: if you press on it you can pan the document, that is move around without scrolling. and shift-scroll moves horizontally... :-)


Thanks a.l.e, I didn't know about those shortcuts either. Fingers crossed that I remember them.

I've just tried the push-wheel pan thing and the page jitters around quite horribly on Linux Mint 17 with Scribus 1.4.2/3svn (1.4.2 on the splash screen, 1.4.3svn on the window title). I'll have to give it a go on my Mac and see what happens. It could just be my Linux installation (or my laptop).

The horizontal scroll thing isn't too much use to me as my mouse has four-way movement on the wheel but it's nice to know there's an alternative.

Anyway, back to the zooming, how about this...?

I think the zoom controls - whatever we end up having - should all be in the same place, and that place should be the status bar with the other display stuff.

I agree that the entry field should remain as it's convenient when you want a specific value, however I'd prefer it to be combined with a drop-down menu with some useful defaults for a quick choice:
* 25%, 50%, 100%, 200% (and whatever)
* Page Height
* Page Width
* Area (drag-draw a box to zoom to that area)
* Previous (whatever the last zoom level was)
* Selection Height (if anything selected)
* Selection Width (if anything selected)

(The value in the entry box should always show the actual zoom value rather than the thing that was selected, e.g. should show "67%" rather than "Page Height".)

The current middle status bar zoom button (for 100%) could then be removed as its function would be within the drop-down menu.

The current -/+ status bar zoom buttons could be replaced by a spin-button right next to the entry-drop-down field to make it look like a combined "entry-menu-spin" box.

As the Area Zoom function would be part of the zoom drop-down menu we wouldn't need the toolbar zoom icon (you can currently only do this from here).

Thus we lose four zoom buttons and gain one tiny extension to the entry field.

Obviously the View menu would have to change but that can be linked to the same functionality as the combined "entry-menu-spin" box. Not much extra work there.

This way you'd have four ways of zooming:
* View Menu
* Status Bar
* Scroll wheel
* Cntl -/+/0

(Cntl+minus works for me to zoom out but I've got to use Cntl+Shift+plus to zoom in, but that could just be my installation/set-up.)

All of the zooming of a specific percentage - entry field or drop-down - or via the spin buttons, should centre on the selection if there is one and on the centre of the window if nothing is selected. The other zoom options are dependent on other things and so can't be selection-specific (or they're already specific to a selection so that's a moot point).

I've probably not thought of all use cases but this isn't a comprehensive design document!


Quote from: GarryP
... because the zoom steps aren't fine enough and the page moves around it's not quite right yet ...

This describes my experience too.  Added to that, Im using Scribus on a notebook, so I need to zoom to the best use of my fairly small screen.  (It would not be so bad on a PC.)

I agree in principle with a.l.e. that there should only be one system to perform the task.  The mouse wheel could be made to achieve the same result, provided it expanded to the desired point.

I like Garry's last post suggesting 'Area' (drag-draw a box to zoom to that area)  Alternative to that would be how I do it in corelDraw - where I select 2 items and it zooms to both items plus the space in-between.
My first 'puter was a 286,
My first dtp was Aldus Pagemaker,
My first printer was a Little Squirt,
My first car was a motorbike.


hi ged

Quote from: Ged on March 30, 2015, 11:57:01 PMI like Garry's last post suggesting 'Area' (drag-draw a box to zoom to that area)

did you ever try the zoom tool? (magnifying glass, shortcut: 'z')



It might be worth mentioning that most of the "defaults" ("presets"?) I gave for the drop-down list are already available as existing functionality, except for "Previous" and "Selection Width/Height".

Adding functionality for "Previous" would probably be no more than maintaining an extra variable.

The "Selection Height/Width" values are already available within Scribus as it maintains a box around the selected items so I can't see that being too much of a job either. There's obviously a routine - or whatever - for calculating the zoom level and canvas offsets from the "page size" - and "dragged box size" - so would it be too much extra hassle to calculate from the "selection size" instead? (Although - as previously mentioned - I can't really see a need for them but they may come in handy.)

I haven't looked at the code but it would make sense to me to have one function that calculated a zoom level and page offsets from any given box, be that page, dragged, selection or anything else. It would make it easier to maintain if anything.

It's probably way more difficult than that though, so I'll stop writing now!


I think the Previous alternative may be confusing to users, I think a better solution would be some kind of "temporary zoom". Like a magnifying glass, when you close it you get back to how it was before (or underneath).

Though it may be confusing that the magnifying glass can zoom out as well as zoom in... :)


What I was trying to go for with "Previous" was a way of quickly swapping between two user-specified zoom levels.

The workflow would be something like: Working at, for example, 150% zoom to check for details; then quickly zoom out to, for example, 90% for an overview to see what it looks like overall; then quickly swap back to 150% to continue working on the detail. The user would first zoom to 150%, then to 90% (both via the input field), then use the drop-down menu choice to swap between the two. I've seen this in other software and it works okay but maybe there's a better way of doing it.

Maybe it's the word "Previous" that's wrong. I think we're talking about the same thing, just with different ways of looking at it.

Either way I don't think it would be a difficult thing to implement - coding-wise (like I said above it's probably just maintenance of a variable containing the last zoom level) - but the UI aspect of it may cause differences of opinion.

One other way to do it would be to let the user set any zoom level as one of many "user specified" defaults and let them choose between these set defaults, but that seems a bit messy to me.

If anyone reading this has experience of some other software that does this sort of thing nicely then it would be great if they could get in touch. Like a.l.e wrote much earlier in this thread, zooming is a major part of working with Scribus and it would be nice to get it working as well as possible if there's a chance for a bit of an overhaul.


Yes, we are talking about the same thing, I was just trying to figure out a more "intuitive" way to present it to the user than "Previous" (because sooner or later you will be in the situation where you are not sure whether the zoom level you want is "previous" or "next").


Yeah, it's a bit of a tricky one.

"Previous", "Next", "Last", "Other", "Alternative", "Different": nothing really works.

If I looked for long enough I could probably find an English word that nicely conveyed the meaning of the concept but I doubt it could be properly translated into every language, so it wouldn't work for everyone.

Discussion about the exact wording could go on for months without agreement.

For me, even if it was given a nonsense name such as "foobar", as soon as I realise/learn what "foobar" does then I'd be happy with it. That wouldn't be ideal for beginners but there's no rule that beginners shouldn't have to learn new stuff. (And it's a very minor thing to learn considering contour lines, hyphenation, paragraph styles, etc.)

As long as it's made un-selectable - greyed out, or missing - until the user selects a new zoom level then that's fine by me.