So, I look at p. 82-84 of a 152 page document, Print Layout, 68% so I can see and read these three full pages, and I see the upper third of the next three pages below them. I click on a location in the document, the cursor goes there, I can edit, all perfect. Then I press CTRL and scroll up 1 step (mouse wheel) to magnify, and the fking display jumps to p. 56. And I have scroll back 1 step, and then out 2 steps, it jumps to 109-112. Yes, the cursor is still at the position it was before and I can get to it by pressing LEFT or RIGHT or seemthing but I cant be asking to much when I want the thing to also SHOW me the same pages.
Oh, and add to that: the same things happens with making comments visible. I am somewhere in a document and edit, fine. Then I say, "Make comments visible", and the display jumps just somewhere, very annoying.
still present in 3.3.4, and I have to say, with OOO one at least got a reply ...
*** Bug 41511 has been marked as a duplicate of this bug. ***
This is still the case in 3.4.3. What happens is that the number of pages lines until the displayed part remains the same: zoom level 1 page -> page displayed: X (Xth pages row) zoom level 2 pages -> page displayed: 2X (Xth pages row) zoom level 3 pages -> page displayed: 3X (Xth pages row) etc. This bug is particularly annoying with big documents (I use F5 -> Navigator to change pages to cope with that).
problem also present with LibO 3.4.4 and Windows
Same on 3.4.4 on Ubuntu. Took me a while to get the three page example.. Here the description for 2, for dummies like me ;) If you're on print view, viewing 2 pages next to each other, And are on page, e.g. 50, and zoom in with CTRL+Mouse wheel, you end up about on page 25 with the display. Hugely annoying.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
bug still present on master (3.6.0alpha+, openSUSE 12.1)
This bug is present in 3.5.0 RC2 on Fedora Linux x86_64. In my document, if I'm at page 103, zoom out so I see a 2x2 display of pages 101, 102, 103 (no 104 in the document. There's a blank space left for that page.) Zoom back in, it now shows page 51. Zoom out, and I see the 2x2 pages with 101-103/4. Zoom out to a 4x2 display, I get the last 8 pages of the document. Zoom out to a single page, and I get page 24! Zoom out, and I get a 2x2 of pages 47-50! If I move the cursor with the arrow keys, I get back to page 103.
Bug is still present in 3.6.0 RC2 32 bit (2012-07-20) and in 3.5.4.2 64 bit (current version from Debian Testing repo). This thing drives me crazy but at least the arrow keys reset the view to the correct page.
Reset the version to 3.3.4. Note that the version picker should point to the oldest version where the bug is reproducible. It helps to locate the problematic code. See also http://wiki.documentfoundation.org/BugReport_Details#Version
Hmm, I agree that this is annoying but when I compare it with other MABs (crashers, data loss), I do not think that it deserves to be in the top list. The bugs has been there for years it has only three users that are interested (in CC). A workaround is "easy". If you enter a letter and remove it , it displays the right page => removing from MABs and adding Writer developers into CC. BTW: I wonder if it might be an easy hack after all.
(In reply to comment #12) > BTW: I wonder if it might be an easy hack after all. If anyone (someone? I never know) could give me a code pointer and perhaps a little background information on moving the cursor location, I am willing to try to patch this.
(In reply to comment #13) > (In reply to comment #12) > > BTW: I wonder if it might be an easy hack after all. > > If anyone (someone? I never know) could give me a code pointer and perhaps a > little background information on moving the cursor location, I am willing to > try to patch this. You may want to start having a look at the patches from bug 36681 as this was a similar problem. Not sure if it really helps though.
I think I have a fix, but I want to test it a bit further and I was to see whether the fix can be made more efficient. Basically, I perform a cursor left followed by cursor right after each zoom.
(In reply to comment #15) correction: I think I have a fix, but I want to test it a bit further and I _want_ to see whether the fix can be made more efficient. Basically, I perform a cursor left followed by cursor right after each zoom.
I wonder if UpdateCrsr(SwCrsrShell::SCROLLWIN) is of any use here.
(In reply to comment #17) > I wonder if UpdateCrsr(SwCrsrShell::SCROLLWIN) is of any use here. No, calling UpdateCrsr(...) does not work as it is a private member of Class swCrsrShell. I tried before I submitted the patch as that would have been neater.
Please don't implement zoom based on the cursor position. The zoom should be based on the current view. If the cursor happens to be in the current view, then zoom based on the cursor seems okay, but if the cursor isn't in the current view, don't change the cursor and don't change the view other than the zoom. It's really common that I scroll to another page and then zoom AND LEAVE THE CURSOR WHERE I WANT TO CONTINUE WORKING. It's really annoying to scroll (sometimes many pages away) to another page and then need to zoom in to see details. If the zoom is based on where the cursor is, then the view jumps back, many pages away. Then I have to scroll back to the details I want to refer to.
Please don't change the Undo chain to get zoom to work.
(In reply to comment #19 and comment #20) The submitted patch makes that the current cursor position stays in focus during zoom. It is no problem to scroll through the text as long as you don't move the cursor, e.g. by using the scrollbars. Changing the zoom only changes the scale/size of the document in your view, the view/screen does not change. You can edit with zoom at 5% or at 500%, it's the same view. It may well be that I misunderstand you, but in the submitted patch I see no introduced problems with respect to cursor position or undo chain. I tested on various documents, scrolled, moved cursor positions and did undo-actions, all with varying zoom-factors to try to reproduce the bug-behaviour. Luckily, I did not succeed, neither did I notice other unwanted behaviour.
Winfried Donkers committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d14f7e4ec48f9a9eee0585fb5ee72512e9f4bd19 fdo#40465 fix to maintain correct focus whilst zooming The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Winfried Donkers committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aab8980a52eca1c0e5beefbfca6f24d125d6e097&h=libreoffice-4-0 fdo#40465 fix to maintain correct focus whilst zooming It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Winfried Donkers committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e5dcec6e58b4bd8582380dd1f97957c369ba9182&h=libreoffice-3-6 fdo#40465 fix to maintain correct focus whilst zooming It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
In reply to comment #21, "It may well be that I misunderstand you, but in the submitted patch I see no introduced problems with respect to cursor position or undo chain." I'm not sure we're saying the same thing. When you said "The submitted patch makes that the current cursor position stays in focus during zoom." that implies that the zoomed view is based on the current cursor position, and not on the current view. If that is the case, then this is the opposite of what I said in comment #19: "It's really common that I scroll to another page and then zoom AND LEAVE THE CURSOR WHERE I WANT TO CONTINUE WORKING. It's really annoying to scroll (sometimes many pages away) to another page and then need to zoom in to see details. If the zoom is based on where the cursor is, then the view jumps back, many pages away. Then I have to scroll back to the details I want to refer to." To clarify my work-flow: I usually work with the document width taking up the whole screen so that I can see details. Call this position A. It is slow to scroll to another part of the document (call it position B) using the mouse scroll wheel or the scroll bar when zoomed in for detail. When I need to scroll quickly to B, I zoom out from A so I get a better overview and can scroll faster. When I get to position B, I need to zoom into the current VIEW, B, not the current cursor, A. Then I can get the info I need from B and continue typing where the cursor is (A), many pages away. If I zoom to position A, then I don't see any of the details I need from B. Your solution of zooming into the current cursor position breaks the usability. The zoom should be based on the current view, not the cursor. The zoom should be based on what the user sees on the screen. If I scroll to another page and then zoom, the zoom should be based on what I see, not on where the cursor is. If I type, the characters should be placed at the cursor position and the view changed to show where I'm typing.
(In reply to comment #25) Steve, I think I understand what you mean. The reported bug, which is now patched, is not quite the behaviour that you want. Simply zooimg out and back in (no scrolling) made the view change. That is not desireable, we probably both agree on that. Also scrolling to a certain page and then zooming in did not mean that the page you wanted to zoom in on, stayed in view. The behaviour that you want (being able to zoom in at another location that the cursor position) sounds like a usefull feature, but I suggest hat you submit a separate bug and label it as a enhancement. It will avoid misunderstanding as -OMHO- your request is not the same as the original reported bug. Also, realising your request requires code changes in quite different places than the code changes for this bug fix. Could you put me in the cc-list for the new bug? Thank you!
reading the comments here, i think that Steve has a valid point: the requirements for this bug are incomplete, and the current fix is a regression in some scenarios. when the cursor is visible in the document view, then it is reasonable to expect that it is still visible after zooming, which is what the fix does. but when the user has the cursor on page 1 on the document, and is looking at something on page 250 with 100% zoom and wants to take a closer look and zooms in a little then i'd agree with Steve that it's quite undesirable to jump to page 1. so it would be best to check if the cursor is visible _before_ zooming, and to adjust the view afterwards only if it is. there is apparently SwCrsrShell::IsCrsrVisible method, please check if that is useful here, otherwise there is also SwCrsrShell::GetCharRect which also sounds useful.
(In reply to comment #27) Steve certainly has a valid point, no question about that. To make sure there no misunderstanding from my side: -potential difficulty 1: With the example of the cursor at page 1 and the intention to look a page 250 it is quite certain that page 1 will not be vissible when zooming in (increasing the zoom/magnification percentage). But what if we're talking of page 1 and page 7? it could well be that page 1 is still visible. -potential difficulty 2: Suppose the cursor at page 1 and us wishing to zoom in on page 250: Which page is to be kept in view whilst zooming in? Say we see 8 pages before we zoom in, how does the code know which page is to be kept in view? The pre-patch code did not have a hand hold, so it sort of jumped to the first page that was in view before zooming. I gave it a hand hold (cursor position), and now I am in need of one, if you get my drift. Should we set a pointer to the page (paragraph, character, depending on the zoom percentage) that is to be kept in view. I mean is there a 'virtual cursor position' to focus on whilst zooming? Should this be triigered by a (any, specific?) scrolling action of the user? I'm quite willing to have a go at it, but it'll take some time before I can really start as I would like to finish another patch (that is currently being reviewed) first.
The "user expectations" (as if there's a standard across all software) is pretty much that you zoom in/out wrt (with respect to) the center of the current view (COV) or the mouse position. Having said that, I did a little survey and thought about the difference between zooming wrt to the center of the current view and zooming to the current mouse position. But first, the survey: Here's a small survey of what happens when you turn the scroll wheel: with: No mods Shift Control LibOffice pan U/D pan L/R zoom in/out Draw wrt COV LibOffice pan U/D pan L/R zoom in/out Impress wrt COV LibOffice pan U/D pan L/R zoom in/out Spreadsheet maintain upper-left Gimp pan U/D pan L/R zoom in/out wrt mouse Visio pan U/D pan L/R zoom in/out wrt center of cur selected objects or COV if no objs selected SketchUp zoom in/out zoom in/out zoom in/out wrt mouse wrt mouse wrt mouse Google zoom in/out tilt view rotate view Earth wrt mouse wrt COV wrt COV Having used all of these, it's comforting when the same action gets the same result. When I use SketchUp, it's annoying when I need to scroll, because SU doesn't make use of the modifiers, and, therefore, the scroll wheel won't pan. Zooming wrt the mouse position is like zooming wrt to the center of view, but you have more control over where the zoom occurs. Both methods zoom wrt what you see, which is the most important feature of both---there's no sudden change on the screen when you are essentially magnifying what you are looking at. (A viewpoint jump is okay if I start typing, because the cursor determines where I type, and I expect to type where the cursor is, even if it's out of view.) However, with zoom wrt mouse you can quickly adjust where the zoom point is without having to stop zooming, then use the scroll bars to adjust the center-point, then switch back to the scroll wheel, zoom, then re-adjust the center-point. Using the mouse wheel to zoom and the mouse position to choose the center-point for the zoom is a really fluid action that makes zooming quick, intuitive, and really easy to control and adjust on-the-fly.
(In reply to comment #28) > Steve certainly has a valid point, no question about that. > > To make sure there no misunderstanding from my side: > -potential difficulty 1: > With the example of the cursor at page 1 and the intention to look a page > 250 it is quite certain that page 1 will not be vissible when zooming in > (increasing the zoom/magnification percentage). > But what if we're talking of page 1 and page 7? it could well be that page 1 > is still visible. that is of course true. well i'd just propose to use the cursor visibility check as a heuristic, surely it won't always result in what the user wanted but our task here is to do the right thing "most of the time", we cannot read user's mind and if we're doing it wrong the user can then scroll around. > -potential difficulty 2: > Suppose the cursor at page 1 and us wishing to zoom in on page 250: Which > page is to be kept in view whilst zooming in? Say we see 8 pages before we > zoom in, how does the code know which page is to be kept in view? i can't think of an obvious, easily implemented answer here, so how about we just do the same thing the old code used to do in this case? > The pre-patch code did not have a hand hold, so it sort of jumped to the > first page that was in view before zooming. I gave it a hand hold (cursor > position), and now I am in need of one, if you get my drift. what i'm mostly concerned about is the obvious regression that Steve complains about, which is now backported to the 3.6 and 4.0 release branches. i suggest to fix that first, and if you are still motivated after that, you can think (and perhaps ask UX) about what changing zoom should do in an ideal world :)
To address Comment 28... -potential difficulty 1: > With the example of the cursor at page 1 and the intention to look a page > 250 it is quite certain that page 1 will not be visible when zooming in > (increasing the zoom/magnification percentage). > But what if we're talking of page 1 and page 7? it could well be that page 1 > is still visible. Center on the current view (or mouse). When you zoom out from 7, go to 7/8 (for COV and odd/even pairs) or 6/7 or 7/8, depending on whether the mouse is closer to the top or bottom of page 7 when zooming out. When you zoom out from 250, show 249/250 or 249/250 or 250/251 for mouse zoom. > -potential difficulty 2: > Suppose the cursor at page 1 and us wishing to zoom in on page 250: Which > page is to be kept in view whilst zooming in? Say we see 8 pages before we > zoom in, how does the code know which page is to be kept in view? Use COV or mouse. If you use COV and you're viewing: 1 2 3 4 5 6 7 8 then it's hard to know what the user wants. Right now it looks like it's based on the upper-left page, 1 in this case. But what if I'm interested in zooming in on page 7? I could click on page 7, but then I've lost the place where I want to type. I could fiddle with the scroll bars to put 7 in the upper left, but that's tedious. If you use the mouse position, and it's over page 7, then you should display 6 7 8 then 7 8 then 7 8, repositioning the mouse (which is fast) as needed. 9 10 11 9 10 > The pre-patch code did not have a hand hold, so it sort of jumped to the > first page that was in view before zooming. I gave it a hand hold (cursor > position), and now I am in need of one, if you get my drift. > Should we set a pointer to the page (paragraph, character, depending on the > zoom percentage) that is to be kept in view. I mean is there a 'virtual > cursor position' to focus on whilst zooming? Should this be triggered by a > (any, specific?) scrolling action of the user? After reviewing COV vs mouse, I vote for mouse. It's intuitive because it's WYSIWYG. In either case, when you scroll, you're changing the COV, which becomes the new COV or a new view for the mouse to explore.
update: Using SwCrsrShell::IsCrsrVisible() seems a good idea, but doesn't work. The function checks if the cursor rectangle (SwCrsrShell::GetCharRect()) is within the visible area (SwCrsrShell::VisArea(). For reasons that I can't figure out (yet), the result sometimes is false when the cursor can be seen blinking in the view. This probably means that I will not be able to submit a partial patch that addresses the regression case in time for for version 3.6.5. Enhancing the behaviour to nicely focus on whatever is decided is most user friendly is something I haven't been able to think about yet.
update: I now have a patch that keeps the cursor in focus, when it is visible, and behaves as before January 8 when the cursor is not visible. That solves the regression problem. I intend to commit the patch later today. The behaviour when the cursor is not visible still is to be improved: when the view changes from n pages next to each other to m pages next to each other (m not equaling n), the visible page jumps out of view. For example on a 22 page document, with page 22 visible (and cursor at page 16) it jumps to page 10 when zooming in and back when zooming out. This is something I will be looking into, but that may well be time consuming.
Winfried Donkers committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fa058a4cd6580d5538c49d565499fb5cc4ecfe53 fdo#40465 solve regression when zooming with cursor not visible The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Winfried Donkers committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b8247bd179b939dc62af75432bc1cc03de13c0e&h=libreoffice-4-0 fdo#40465 solve regression when zooming with cursor not visible It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Winfried Donkers committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5aadc1cf65841ce8737ec6602dcc3751e368c395&h=libreoffice-3-6 fdo#40465 solve regression when zooming with cursor not visible It will be available in LibreOffice 3.6.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Winfried Donkers committed a patch related to this issue. It has been pushed to "libreoffice-3-6-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b3ef9d4787a4aab7ad055c5221bbdf002c36297&h=libreoffice-3-6-5 fdo#40465 solve regression when zooming with cursor not visible It will be available already in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The jumping of the page also occurs when changing the width of the window (in which the document is shown) to a size which makes the number of columns change, regardless whether the cursor is in view or not. I'll see if there are other bug reports mentioning this problem (apart from comment 1 in this bug), so that I can fix all likewise problematic behaviour.
*** Bug 44445 has been marked as a duplicate of this bug. ***
Re: comment #19, are you Steve confusing "cursor" and "caret"? It's the mouse cursor (or "pointer") that people refer to in this discussion when using the word "cursor", right? The mouse cursor / pointer, by definition, is always visible on the screen (except if explicitly turned off, like when viewing full-screen video in some media player, which I don't thjink LibreOffice does). In comment #19 you apparently talk about the text insertion point, specific to a text field (like the text document being edited), indicated by the caret. That indeed need not be visible, it might be scrolled off-screen. I don't think anybody wants to change that.
Note the related work on mouse centred zooming by Tim Hardeck from last year, that never got included, see http://lists.freedesktop.org/archives/libreoffice/2013-March/046765.html . Also note that for touch device support, it is essential to have support for zooming centred on a specific position (not "cursor" as such, tablets don't have cursors, but the centre of a two-finger pinch/spread gesture). Which is making getting this bug/feature done more acute.
Re: my comment #40, reading more of the comments here after comment #19, it is unfortunate that LO itself intentionally in the source code uses the "cursor" term (or the abbreviation "Crsr") for the text insertion caret, sigh. And apparently in this discussion the term "cursor" is used for the caret, to. (The term "mouse" is used by many here for the mouse pointer (cursor)). So, I guess it is a lost cause to try to use consistently separate words for these concepts.
(In reply to comment #42) I confirm your findings. I replied so to your comment #40, but apparently I did something wrong as it did not get into the bug..
Having had a look at the patch from Tim Hardek, I think I can make the code to keep the center of the window in focus whilst zooming (for the case that the caret is not visible). But it will be a couple of days before I have the opportunity to build and test the modified code.
Winfried - thanks for all your great work on this bug :-) For touch / tablet-ness we are going to want to be able to pinch-to-zoom a document in an intuitive way that doesn't jump around the place (I guess) and probably bears no relation to where the cursor is or isn't [ lots of demands there of course ;-]. I guess it's an interesting problem; hopefully we can re-use some combination of Tim / your work here. Tim's seemed to be significantly confused by the fact that the scroll zoom in would move the effective center of the zoom and the zoom-out would then try to restore something and (well - I forget what it did but it felt wrong to me ;-)
(In reply to comment #40) > Re: comment #19, are you Steve confusing "cursor" and "caret"? It's the > mouse cursor (or "pointer") that people refer to in this discussion when > using the word "cursor", right? > > The mouse cursor / pointer, by definition, is always visible on the screen > (except if explicitly turned off, like when viewing full-screen video in > some media player, which I don't thjink LibreOffice does). > > In comment #19 you apparently talk about the text insertion point, specific > to a text field (like the text document being edited), indicated by the > caret. That indeed need not be visible, it might be scrolled off-screen. I > don't think anybody wants to change that. I mean that the place you zoom into should be the mouse pointer, not the current insertion point. As I've said before, it's important to be able to zoom in to another portion of the document without losing the insertion point. This means that there need to be two pointers, and the logical ones are (a) the insertion point, and (b) the mouse cursor. The insertion point doesn't, and shouldn't, move as you zoom in and out. The mouse is free to move over any portion of the visible part of the document, so it's the best (only?) candidate for the center of zoom, whether it's in or out. We already have the notion of the view changing to the insertion point when you start typing, so it's already really easy (and intuitive) to return to the insertion-point view. Because mouse-based zoom is used in many other programs, it's intuitive (to a user) to use the mouse position as the zoom center in LibreOffice as well.
I did some tests with bits of Tim's patch, but it does not fix the problem of this bug at all :-( I know what goes wrong, but haven't been able to find where is goes wrong. The pages of the document are 'tiled' in rows and columns, depending on the zoom factor and the window width. When repainting, it jumps to the relevant page(s) by going to the mth row and nth column. If the number of columns changes, because of zooming or because of window resizing, the number of columns changes, but on repaint the code still jumps to the old row number, which now contains a different page. I keep searching, but the pace is slow... IMHO, mouse pointer or finger position (touch screens) related zooming should have its own bug. It is an enhancement (and a longed for one), and not related to the problems this bug addresses.
This is still a problem in 4.0.0.3, just downloading 4.0.1 now. I do think there's actually more wrong thatn just that. I just found a similar thing. I have a document that has several text frames. If I look at the doc with 3 pages next to each other and you delete one of them, the screen jumps two times and ends up slightly somewhere else. Take the attachment, look at three pages next to each other, delete the frame on p. 4, and see what happens.
Created attachment 76232 [details] frame deletion makes pages jump
(In reply to comment #48) > This is still a problem in 4.0.0.3, just downloading 4.0.1 now. I do think > there's actually more wrong thatn just that. I just found a similar thing. I > have a document that has several text frames. If I look at the doc with 3 > pages next to each other and you delete one of them, the screen jumps two > times and ends up slightly somewhere else. Take the attachment, look at > three pages next to each other, delete the frame on p. 4, and see what > happens. Yes, you are correct. The problem is not about zooming, but about repainting the pages in the window when the number of pages next to each other changes. I'm still trying to find the cause. I have changed the description of the bug to reflect the complete problem.
(In reply to comment #41) > Note the related work on mouse centred zooming by Tim Hardeck from last > year, that never got included, see > http://lists.freedesktop.org/archives/libreoffice/2013-March/046765.html . > > Also note that for touch device support, it is essential to have support for > zooming centred on a specific position (not "cursor" as such, tablets don't > have cursors, but the centre of a two-finger pinch/spread gesture). Which is > making getting this bug/feature done more acute. i guess it depends on _how_ you zoom. i usually use the "slider" in the lower right to zoom, in which case the mouse cursor is naturally on the slider and outside the document area, hence "mouse centered" is rather useless in this case, and something like "keep the view cursor visible if it was before" makes more sense. (In reply to comment #42) > Re: my comment #40, reading more of the comments here after comment #19, it > is unfortunate that LO itself intentionally in the source code uses the > "cursor" term (or the abbreviation "Crsr") for the text insertion caret, > sigh. And apparently in this discussion the term "cursor" is used for the > caret, to. (The term "mouse" is used by many here for the mouse pointer > (cursor)). So, I guess it is a lost cause to try to use consistently > separate words for these concepts. Writer uses the term "Cursor" in a more abstract way for any text selection in the document, of which there may be many at a time. One of these is the "View Cursor" (or shell cursor) that you call "caret".
(In reply to comment #51) This bug presently contains two issues: 1. when the window is repainted, the shown page(s) may jump (see comment #47) 2. the present zoom behaviour is that the top-left corner of the window is used as focal point. This could be changed to window-center or mouse pointer position (with window center as alternative when the mouse pointer is not in the visible area). The only thing 'fixed' so far is that when the caret is visible, it will remain visible (i.e. page jumps no longer occur). I very much want to work on issue 2 (large parts of Tim's patch can be used for this), but I need to fix issue 1 first, otherwise no testing is possible. And I still haven't found the code that causes these jumps. I know when the jump will take place I know to which page writer will jump, but I keep getting lost in the maze of calls. I suspect I need to be at the paint function, where (I think) the page to be painted is recalled and where (that's my current guess) the addressing (row/column vs page number) goes wrong. Hints and suggestions are very much welcome.
update: I am now almost convinced that I know what is the problem, but a solution seems to be rather fundamental. After zoom/resizing each page (starting at the first page) is checked for being within the visible area (/core/sw/source/core/view/viewimp.cxx, SwViewImp::SetFirstVisPage()). But the comparison of rectangles (page and visible area) is not correct when the number of pages to be shown next to each other changes. Take for example a document with a zoom factor that shows 3 pages in a row and the top left page is page 16 (6th row). When resizing the screen width to a bit less than needed for 3 pages next to each other, the jump occurs. The page rectangles are now based on 2 pages in a row, whereas the visible area rectangle still reflects the 6th row. As a result the page on the 6th row (now page 11 as only 2 pages fit in a row) is shown and not page 16. I think this problem is caused because the 'focal point' (the position in the document, in the current code the top left page in the visible area before zooming/resizing) is not stored. The iteration through the pages of the document to find the 'focal point' happens a lot, which must be inefficient for large documents. A solution would be to keep track of the 'focal point'. The jump problem will not occur and a lot of iterating through the pages can be discarded with. I think it will also be easier to change the sort of focal point (top left corner, screen center, etc.) But this a rather fundamental change. Where to store the 'focal point'? When to adjust it? How to keep the 'focal point' available and which classes should have Get or Set access to it? Etc. @Cedric Bosdonnat, @Michael Stahl: you are the writer experts, what are your opinions on this? Such a change looks too big for me to handle, but with some guidance I might give it a try. Without guidance (such as hints and comments on my wop) I fear I must change the assignee from me to unassigned... If my text is not clear, please say so and I will try to clarify.
I see no further possiblities to fix this bug without help. It is clear (to me) what generally goes wrong, but I can't pinpoint the exact what and where in the code. When this is possible, it is relatively easy to incorporate a 'focal point' for zooming (e.g. window center of mouse cursor position). I removed my name as assignee to make fixing this bug available for others. Still willing to help (and fix), however :-)
Restricted my LibreOffice hacking area
In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval. Thank you and apologies for the noise
This bug really could use a summary as per https://bugs.freedesktop.org/show_bug.cgi?id=73993, or (likely preferable) a new bug with a clear description of the remaining issues.
Summary of remaining issues: When repainting a multi page writer document, the page that has focus may disappear from the screen. The only issue that has been fixed so far is the case where the page that has focus also contains the caret (text insertion point). The following comments describe what problems remain and what happens: #52 #47 #53
IMHO, it was fairly pointless to reopen this bug. With this many comments about potentialy quite unrelated issues, nobody is ever going to get much useful information out of this bug report. I think. Reading just the previous comment, I don't really understand what "focus" means? The part of a document the user is looking at? ;) That's what it sounds like to me. If the text insertion caret never disappears accidentally (is that now the case?), that is good enough for me. I don't expect the software to know that I happen to look at a different spot in the document and that it should keep that spot visible instead... But ignore me, I am not a Writer hacker anyway,
(In reply to comment #59) > IMHO, it was fairly pointless to reopen this bug. With this many comments > about potentialy quite unrelated issues, nobody is ever going to get much > useful information out of this bug report. I think. > > Reading just the previous comment, I don't really understand what "focus" > means? The part of a document the user is looking at? ;) That's what it > sounds like to me. If the text insertion caret never disappears accidentally > (is that now the case?), that is good enough for me. I don't expect the > software to know that I happen to look at a different spot in the document > and that it should keep that spot visible instead... > > But ignore me, I am not a Writer hacker anyway, tml, I will not ignore you, you're comments are mostly usefull and otherwise entertaining ;) The current status (reopened) dates from around January 2013 and is IMHO justified and explained concisely by e.g. comment #27. That comment also may answer your question about focus.
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]