Description: AFAIK - Page Up and Page Down move X lines up or down in a text (no idea what X is). Advancing or retreating to the next/previous page break is far more useful than moving an undefined number of lines. I'm currently working in "book mode" which compounds the problem. Ditto for two pages. Only in single page is the advancing some number of lines acceptable. Steps to Reproduce: 1.Press PgUp or PgDn 2. 3. Actual Results: page display advances or retreats undefined number of lines Expected Results: Advance retreat to next/previous page break. Reproducible: Always User Profile Reset: No Additional Info: Currently using 8.5 x 11 inch format but applies to any document with frequent page breaks.
We have .uno:PageDown (bound to page down key) and .uno:GoToStartOfNextPage (not assigned to a shortcut but available via Navigator; the command might have not been available before 7.0). IIUC, the request is to scroll down until the next forced page break (ctrl+enter), whether or not with style change. I doubt this is useful for many (nor it's what you actually need). Btw, you can search for page breaks... see https://ask.libreoffice.org/en/question/74740/search-and-replace-manual-page-break/
I'm running 6.3 - AFAIK this is the latest stable version. I just checked via the Help Update checker. I'm aware of PgUp and PgDn Navigator bindings. They are what I currently use and what prompted this report. GoToStartOfNextPage is AFAIK not in 6.3. It's possible I overlooked or didn't recognize it. Using the book display and multiple page modes are particularly affected by partial page scrolling. While the sample search does, strictly speaking, find a break, it's impractical to repeatedly go through the search process when reviewing a document for editing, proofreading, etc. Scroll to next page break, at least for writing novels, short stories, publishable articles is close to a must-have. Sample screen grabs available - pls advice best way to send them.
Please comment what exactly you want to do. Go to the next page break or to the beginning of the next page. If it's page break, I don't understand the workflow. Plus, have you considered the find&replace dialog?
(In reply to RBEmerson from comment #0) > Description: > AFAIK - Page Up and Page Down move X lines up or down in a text (no idea > what X is). Advancing or retreating to the next/previous page break is far > more useful than moving an undefined number of lines. > The pgDwn/pgUp scroll is os/DE defined as for dupe 105776 and related bug 101211. Not appropriate to reassign PgDwn/PgUp as those are os/DE managed and we *always* use in LO for scrolling and selection. But the requested movement is already available in the 6.4 release implemented on the Find Bar's Navigate By listbox selection. And with the spin-box advance from the Navigator's Page mode. For 7.0 release, the Navigator mode selection has been reworked to match the Find Bar's list box. Behaviros linked, and the by page honors inserted page breaks. And for bug 101211 we will be implementing UNO commands to bind the same move to next page / previous page for keyboard customization Please retest with a 7.0 alpha1+ build. *** This bug has been marked as a duplicate of bug 105776 ***
(Added - Post "Mid-Air Collision" caution) How do I send screen grabs illustrating the problem? The intent/request is to place the next page break at the top of the screen/page display. Currently PgUp&PgDn move approximately a half page. Another way of stating the problem, I guess, show only a full page when using PgUp or PgDn. Agreed different size pages pose a problem. For example A4 pages v. 8.5x11 For the "different page sizes" issue, the user should change scale as needed. Using full screen mode (CTL SHF J) 8.5x11 at 100% happens to work for me, but I count that as only a coincidence. Using Find is plausible, but only if a page break can be entered in the FIND field. AFAIK that's not possible. ----- ADDED: Is it possible to run 7.0 alpha 1 in parallel with the current release rev.? Losing a 300+ page novel to an alpha failure would ruin my day. At least... ----- NOTE: Version, Hardware, and OS fields have been changed to match my particular machine.
Read Bug # 105776 - If <CTL>+PgUp / PgDn is to be used to modify page scrolling, I see no problem with that.
(In reply to RBEmerson from comment #5) > ----- > ADDED: Is it possible to run 7.0 alpha 1 in parallel with the current > release rev.? Losing a 300+ page novel to an alpha failure would ruin my > day. At least... https://wiki.documentfoundation.org/Installing_in_parallel
Great thanks!
Good news mostly, bad news slightly The user finally woke up and smelled the coffee. I found "page by page" scrolling in 6.3 Navigator, albeit with "<" and ">" to execute "previous page" and "next page". 7.0 implements the IMHO more intuitive "^" and "v". However, in full screen mode navigator is no longer visible. How do I bind whatever Navigator does to move whole pages, instead of X number of lines, to PgUp and PgDn respectively? I suggest the former action (whole pages) be the default operation, with X lines as an option to be adjusted in customizing. - - - - FWIW, I got the "no vcruntime140.dll" error after installing V7.0. I've corrected that, but FWIW ensuring Visual C++ runtime is available or can be easily added (no idea about licensing issues) will help people testing the version, but who have no idea about what the error means.
(In reply to RBEmerson from comment #9) >... > > However, in full screen mode navigator is no longer visible. > Never has been... > How do I bind whatever Navigator does to move whole pages, instead of X > number of lines, to PgUp and PgDn respectively? > > I suggest the former action (whole pages) be the default operation, with X > lines as an option to be adjusted in customizing. > > - - - - That is the work on bug 101211, unlikely we will change the default pgDwn/pgUp linkage of os/DE managed scroll (most default to 3 lines).
Now knowing what I should be looking for (insert grumble and rant about being as clear as mud to get that point), the pages consistently wind up where they should be. Almost. While the Navigator up/down arrows put the top of the page(s) at the top of the screen, as expected, using "To Begin of Previous|Next Page" puts the page splits loosely a third of the screen height from the top of screen when scrolling through previous pages, and loosely a third of screen height from the bottom of the screen. The take-away is what the Navigator bar does, doesn't match what "To Begin of Previous|Next Page" does.