After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 300641 - Zooming in should be centered
Zooming in should be centered
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
0.2.x
Other Linux
: High normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks: 170458 303811 303884
 
 
Reported: 2005-04-14 17:11 UTC by Tommi Komulainen
Modified: 2005-05-18 03:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to CVS (4.54 KB, patch)
2005-04-26 12:17 UTC, Nickolay V. Shmyrev
needs-work Details | Review
Updated patch (12.91 KB, patch)
2005-05-12 14:20 UTC, Nickolay V. Shmyrev
needs-work Details | Review
Gzipped patch (15.43 KB, application/x-gzip)
2005-05-13 14:52 UTC, Nickolay V. Shmyrev
  Details
GZipped patch (18.31 KB, application/x-tar)
2005-05-15 21:54 UTC, Nickolay V. Shmyrev
  Details

Description Tommi Komulainen 2005-04-14 17:11:40 UTC
Zooming in should zoom towards the point at the center of the visible area; i.e.
that point should remain still.  Currently it seems it's the top left corner
that's anchored instead.
Comment 1 Christian Persch 2005-04-25 23:32:20 UTC
Currently, it doesn't seem to anchor at all. For example, I load a large PDF
(e.g. the PDF Reference), go to page 500, zoom out once -> now I'm on page 600
(and the toolbar isn't updated to that location).
Comment 2 Nickolay V. Shmyrev 2005-04-26 12:17:25 UTC
Created attachment 45689 [details] [review]
Patch to CVS
Comment 3 James Bowes 2005-04-28 22:41:03 UTC
When the zoom mode is set to either fit width or best fit, and the window size
is adjusted, the document resizing is very jittery with this patch.
Comment 4 Jonathan Blandford 2005-05-02 16:57:41 UTC
So, I think we need to take a step back and figure out the behaviors that we
want here:

 * In general, we want zooming to keep the same part of the top of the current
page visible.  So if we're 17% through the doc at the start of the zoom, we'll
be 17% through at the end, with the same words visible at the top.

 * This is true if we're zooming because we're resized, or zooming from the
toolbar.  We want to keep people visually aligned.

 * An exception to this is zooming due to scroll-wheel.  In that case, we want
to center the zoom around the mouse pointer.
Comment 5 Nickolay V. Shmyrev 2005-05-02 19:16:52 UTC
Actually, there is nothing bad to follow acrobat behavior here. And the 
required behaviour is:

1. On resizing && (fit width || fit page) we need to keep view top in the same 
place

2. On zooming with control or from menu we should zoom towards center of 
visible area

3. On zooming with mouse wheel we should keep mouse pointer visible.

Hope, I'll update patch next week.
Comment 6 Nickolay V. Shmyrev 2005-05-12 14:20:11 UTC
Created attachment 46368 [details] [review]
Updated patch

It also fix problems related to scrolling which are described in 170458 and bug
303884
Comment 7 Nickolay V. Shmyrev 2005-05-12 14:25:30 UTC
And bug 303811 too
Comment 8 Nickolay V. Shmyrev 2005-05-12 20:05:34 UTC
But it still far from perfect. Problems - not exact positioning (need
calculation based on pages size, not just adjustment values scaling) and view
trembling on Fit Width mode.
Comment 9 Nickolay V. Shmyrev 2005-05-13 14:52:50 UTC
Created attachment 46397 [details]
Gzipped patch

Large patch with cleanup of ev-view code. Just another test version.
Comment 10 Nickolay V. Shmyrev 2005-05-15 21:54:07 UTC
Created attachment 46465 [details]
GZipped patch

This is working (At least I think so) patch. Main changes in it:

1. Reorder and beautify code in ev-view, functions groups and declarations
2. Pending scroll to page and stay on the same place in zoom
3. Patch from bowes about command line page 

4. Removal of bin_window. To make things better, now EvView tries to use
another way - window is small, we only translate coordinates on drawing/user
input with values from adjustments.

The main problem with old way - you need draw on widget and then move it or
first move and then draw. This can not be done nicely since it's impossible to
join this two actions in atomic operation. So they both will be visible to
user.
Comment 11 Jonathan Blandford 2005-05-18 03:18:16 UTC
Awesome patch.  I committed it.  I'm sure we'll be shaking this out for a bit,
but it's good enough for now.