Version: 0.6.5 (using KDE 4.0.5) OS: Linux Installed from: Fedora RPMs When the page does not fit (too large zoom), choosing Previous/Next Page don't have the behaviour I want -- the top of the next page will be centred horizontally, rather than keeping the position on the page intact. As an example when this is useful, in some cases the document has wide borders, and it would be very convenient to zoom in so the actual text is visible and nothing else. However, this is foiled by the viewport position being reset when switching pages, so the user (me) has to recentre the viewport on the text. (BTW, I think it's hard to automate this, since headers and footers should be ignored.) I'm not sure if this could replace the current behaviour without others complaining, so it might be preferable to add it as a separate action available for the user to add a shortcut for, or to make it an option in settings. For what it's worth, in good old gv, PageUp/PageDown behaves like this. Not quite enough to make me switch back, though ;-)
*** Bug 361862 has been marked as a duplicate of this bug. ***
*** Bug 343101 has been marked as a duplicate of this bug. ***
In presentation mode there needs to be side by side page viewing, and the ability to navigate through the pages by just touching the screen. The wheel works, but is too small to use to navigate accurately and quickly. I have a folding laptop/table computer. The keyboard doesn't work when it's configured as a tablet, and mouse at the piano is not as good as simply touching the screen. A touch on the right side of the screen should move the document forward, and a touch on the left side should move it to the previous page.
(In reply to gbodley from comment #3) > In presentation mode there needs to be side by side page viewing, and the > ability to navigate through the pages by just touching the screen. The > wheel works, but is too small to use to navigate accurately and quickly. I > have a folding laptop/table computer. The keyboard doesn't work when it's > configured as a tablet, and mouse at the piano is not as good as simply > touching the screen. A touch on the right side of the screen should move > the document forward, and a touch on the left side should move it to the > previous page. I think that this is unrelated to this bug, which is about the part of the window shown when navigating through the keyboard. Same for few other comments on navigation-related bugs. Please keep the comments on topic for each bug; no need to report the same issue on unrelated bugs.
Just to add some explanation, other PDF viewers in particular but also some other document viewers/editors will use this behavior under a secondary keybinding (e.g. CTRL+Page Up/Page Down). ~~Thus this could be viewed as an additional feature perhaps, rather than having to decide between behaviors.~~ There already appear to be two behaviors that I have noted below. The That said, this is a nice-to-have feature for heavy PDF inspecting/use is jumping forward/backward pages but retaining the position on a page (e.g. zoom level, view-shift left/right, and vertical scroll on a page). This is useful for use checking things like header/footers, title blocks on drawings, and for quickly viewing overall formatting like margin sizing. When using single-page view and zoomed out to at least fit the page, this is already usable this way. However for large document pages, or smaller details within a page, zooming and panning becomes necessary. Interestingly, there already are somewhat two behaviors. Both will preserve the level of zoom (which is desired!). However: 1. When zoomed in, using the scroll wheel, arrow keys, and Page up/down to navigate will preserve your horizontal position in a page, but page up/down will not retain vertical position on page. 2. Paging using the next/previous page buttons will reset the relative page position to a default location on each page change. - If this default position is kept by the user, this behaves as desired/described by others, however it seems like this "default position" being changed to match the previous view would be more desired.
I'll add to this some details: There are currently two ways of going "1 page" down: Way 1: Going one view worth of page down. If zoomed in more this is less than one page. If zoomed out this is more than 1 page. This is done with animation. Way 2: Going to the start of the next page. This is done without an animation (which is useful if you want to compare the two pages). Way 1 can be achieved in the following way: - PageUp / PageDown Way 2 can be achieved in the following way: - Right/left arrow There are two proposals: Proposal 1: Add a way 3 that goes to the next page, but preserve position. The shortcut would be Ctrl+pageup/pagedown Proposal 2: Replace way 2 with way 3. I'll add that sometimes way 2 is more useful to me than way 3. This is in the situation where I'm viewing slides of a presentation. Then I would like the slide page to start at the top of my screen when going to the next slide. Otherwise, when I scroll down slightly for one time, I have to fix that for the next slide to show neatly and fully on my screen. With way 2, I can just press the right arrow and the next slide with show neatly on my screen. I'm curious to know what other PDF viewers do. I think it's good for okular to be compatible with them. If nothing comes up I think Proposal 1 is the best and that should be implemented.