I am using 5.4.0.3 64bit ver on win 10. In Writer, I have set the zoom to entire page (view > zoom > entire page)
when I press PgDn, the cursor jumps to the beginning of the next page, BUT I see about two thirds of page 1 and one third of page 2. I want to go to page 2 AND see page 2 in its entirety (and none of page 1). How do I achieve this?
NB. Going to tools > customise > and changing Page Down to “To Beginning of Next Page”, as suggested elsewhere, doesn’t improve the situation. Even if I go via navigator (F5) and click the little arrows next to page number, the scrolling is still random. I’d be grateful for any help as this is driving me mad. Thanks.
Hello @slepy.slepa,
Here is a workaround to achieve what you want:
After jumping to the next (or previous) page, when it shows only 1/3 of the page, just choose the menu "View : Zoom : Entire Page".
Alternatively you could connect your own Shortcut Keys to the following macro’s:
Sub Writer_Show_Next_Page_ENTIRELY()
REM Displays the next Writer Page in ZoomType = ENTIRE_PAGE.
Dim oDoc as Object : oDoc = ThisComponent
If oDoc.supportsService( "com.sun.star.text.TextDocument" ) Then
Dim oViewCursor as Object : oViewCursor = oDoc.CurrentController.getViewCursor()
Dim oViewSettings as Object : oViewSettings = oDoc.CurrentController.getViewSettings()
If oViewCursor.jumpToNextPage() Then
oViewSettings.ZoomType = com.sun.star.view.DocumentZoomType.ENTIRE_PAGE
End If
End If
End Sub
Sub Writer_Show_Previous_Page_ENTIRELY()
REM Displays the previous Writer Page in ZoomType = ENTIRE_PAGE.
Dim oDoc as Object : oDoc = ThisComponent
If oDoc.supportsService( "com.sun.star.text.TextDocument" ) Then
Dim oViewCursor as Object : oViewCursor = oDoc.CurrentController.getViewCursor()
Dim oViewSettings as Object : oViewSettings = oDoc.CurrentController.getViewSettings()
If oViewCursor.jumpToPreviousPage() Then
oViewCursor.jumpToStartOfPage()
oViewSettings.ZoomType = com.sun.star.view.DocumentZoomType.ENTIRE_PAGE
End If
End If
End SubPossibly performance could be somewhat improved if the outer If’s content would be enclosed in oDoc.lockControllers … oDoc.unlockControllers pair (however, didn’t test myself; just a guess).
Sorry but the LibreOffice scrolling and paging is totally wacko.
While working on a long document I went through the same quest.
There simply is no way to logically move through a document as you would expect.
After hours of frustration, I finally gave up and installed Word.
Word works as I expect when paging and scrolling at different zoom levels, and page views.
This is rather ironic given that the long document I am working on is LibreOffice documentation.
I have seen some discussion in the bug tracker but it is mostly just about slow scrolling.
Little to nothing about the interface behavior which users expect.
So this bad usability is not likely to change any time soon.
As a test case I submitted a small user interface change/improvement.
Months later … lots of discussion, but no action.
And the currently proposed “solution” is just dumb.
So probably a waste of time to submit any kind of bug/improvement.
Working on a 450+ page document in Word is much easier.
I can just focus on what I am doing, not on fighting the weird document navigation issues.
Sorry. I know this is not a LibreOffice solution, but don’t waste any more time like I did.
This is more of a rant than an answer. It would be much more helpful if you cut the badmouthing and provided a link to the bug report in question.
I don’t think it’s possible to do this as of version 5.4.
It seems that most things commands are designed to move the cursor, rather than move the view directly. This is not inherently a bad thing, since it’s usually quite useful to see the surrounding context of whatever content you jump to.
I can think of one place where page up/down keys work the way you want, which is print preview (ctrl+shift+o). It’s kind of flaky though - the behavior of both the scroll wheel and the page up/down keys varies depending on the zoom level.
While editing, the closest thing to what you want is probably the previous and next functions in the navigator, as suggested in this answer. Unfortunately, it’s not possible to bind these functions to the keyboard.
As far as I can tell, the simplest thing to do while editing is to actually scroll with the scroll bar, mouse wheel, or touch pad.
thanks, KH. I tried the print view but the PgDn key does nothing there, and I don’t seem to be able to edit, so that is useless for my purpose. I tried the navigator, too, as I said in my original post - but that doesn’t work properly either (funny thing is, I think it worked properly a few months ago).
I appreciate this PgDn behaviour might be by design (to see context) and I don’t propose the default behaviour is changed. Is there way to suggest improvement to the software?
Hmm, don’t know what to say. What Petermau describes is also different from what I experience.
I found a couple bug reports related to scrolling without much recent activity. I tried to revive one by asking whether it would be feasible to make the commands from the navigator available for key bindings and etc.
But this doesn’t solve your problem if the commands aren’t working the same way for you. I think that itself might be bug that should be reported on Bugzilla.
On my Linux-Mint Mate system, LibO 5.3, 5.4 and 6.0 (EN-GB) PageUp, PageDn on the Navigator Sidebar seems to work as you expect. Select full page by VIEW > ZOOM > ENTIRE PAGE. Then use Pf11 to bring up the Sidebar, then choose Navigator and PageUp / PageDn. May also work for you.
This approach uses the mouse and is independent of the keyboard keys (page up / page down).
Does it work for you using PageUp/PageDown keys on the keyboard rather than clicking on the icons in the Navigator? Also, where in the Navigator do you have “View complete page”? I can’t see that.
You can jump between pages, either to previous/next page or to a particular one, using the Navigator
Thanks to Librebel for a solution that works. It first jumps to the first third of the next page and then redraws the whole page, which is somewhat disconcerting visually (yet understandable given the approach chosen), but acceptable. For the benefit of anyone reading this, I’d like to clarify that in FreeOffice PgUp/PgDwn keys works as expected and the whole thing feels faster than LibreOffice (though FreeOffice might have other disadvantages). Evidently a “native” solution in LibreOffice would be preferable to the macro, so if anyone reading this IS a developer of LO or knows one of the team, drop me a line and I’ll try to convince them to fix this 
Well, I’m glad you found an acceptable solution. Still, while I suppose that you might have some valid reason to want this, I don’t see any universal value in implementing this in a text-centric workflow that Writer is built around (being not a desktop publishing software, but word processor). It should offer something valuable to substantial amount of users to be worthwhile for inclusion into core.
Mike, I find what you wrote a bit condescending (“while I suppose that you might have some valid reason to want this”) - as if I were inventing nonsensical challenges.
From an user’s perspective, if you have a software that allows displaying full pages, then it makes sense to be able to go from one full page to another full page. Whether it’s a word processor or something else is a moot point in my view. Whether this is valuable enough for large enough of people, that is of course debatable.
- “From an user’s perspective, if you have a software that allows displaying full pages, then it makes sense to be able to go from one full page to another full page” - I doubt that formal logic would find this assertion valid. The implication will only be valid if the antecedent necessarily leads to consequent, but I don’t see this here. For this to make sense, it’s not enough to be able to see full pages. A reason is required.
.2. “Whether it’s a word processor or something else is a moot point in my view” - well, I’m not a native English speaker, so I might be wrong what you mean; but if you mean that I might be wrong in asserting that Writer is a word processor, then you are wrong: I know what Writer is at the code level, and its logic. If, on the other side, you mean that it doesn’t matter if this is a word processor or not, then - well, from “a user’s PoV”, it might not matter, but it does from PoV of those …
… who created the software for a specific purpose, and who made it to favor some kind of workflow, and not some other. It’s not that those other aren’t good; it’s just not the purpose of this specific software.
(In addition to the suggestion by @librebel and to the comments by @mikekaganski with which I agree. I just felt kind of tempted by the question, but will probably neither apply what @librebel suggested nor what I sketched myself.)
-1- ‘PgDn’ is mistakable. It generally addresses the View / Window / Frame and not the content rendered therein. After all there is lots of content classes that are not subdivided in pages - and strictly spoken LibO Writer documents aren’t either. This fact is disregarded again and again in user posts. Pages are mostly created by automatic wrapping. They depend basically on the chosen paper size and also may depend on trifles influencing the rendering differently on different systems e.g. Pages are always kind of a phantom. Only the ‘ViewCursor’ knows anything at all about pages. If you choose the document view ‘Web’ e.g. any length of text is treated as one page…
On German keybords the ‘PgDn’ key is not labeled ‘Seite abwaerts’ (page down) or the like, but ‘Bild abwaerts’ (picture/view down) telling more clearly what should be expected.
-2- To show a page wrapped for some standard paper size (A4 e.g.) in a ‘Fit width and height’ mode I have to set the zoom to 70% or lower on my screen. Not good.
-3- What comes next to a feature I might judge valuable in the context would be something like ‘Browse by pages’. But then an additional specification is needed where the ViewCursor should be placed (SoP, EoP, …?) on every next page. Such a feture might be useful under rare conditions with any zoom chosen for other reasons.
-4- I wrote a bit of code for the purpose in BASIC. As the situation is a bit dodgy basically we should not expect it to run flawlessly and to produce the expected result if called in a debugging session. You may experiment with it via ‘Tools’ > ‘Macros’ > ‘Run’. For permanent use it should be placed in a module of the ‘Standard’ library in ‘My Macros & Dialogs’ and made accessible via a command placed in an extra toolbar and by a shortcut (Alt+PgDn e.g.) using ‘Customize’. A demo containing the code is attached here.
Code (Please excuse the high complexity.):
Sub browseToEndOfNextPage() 'Experimental!
myDoc = ThisComponent
myCC = myDoc.CurrentController
myVC = myCC.ViewCursor
myVC.JumpToEndOfPage()
REM The Boolean returned by the function JumpToEndOfPage() is ignored here.
REM I couldn't even find any specification of its meaning.
myVC.GoRight(1, False)
myVC.JumpToEndOfPage()
End SubLupp, your macro doesn’t work for me. Yes, it jumps to the end of the next page, but LO displays about 4/5 of the new page and 1/5 of the page after that. As for your pt 1), if I have full page displayed I expect to go down a page. If I have 1/3 of page displayed (e.g. on a small screen) I expect to go down 1/3 page. Ad pt 2), I have big enough screen to see the full A4 w/ margins at 120%. See also the multipage view. Shouldn’t that page down by displayed pages rather than some random amount?
OK. I was basically aware of what you expected. This should even be achieved without changing the ViewCurser: Cursor and selection persist; the view moves. I couldn’t find access to control the view in the needed way via the api - and considering what I personally would probably like, I made an alternative suggestion.
Awaiting another answer describing direct control of scrolling, best with access to page wrapping. Not too confident, however.