qpdfview

How to have a verical scrollbar when not in continuous mode

Asked by ralphl

I like to view items with fit-to-page-size and trim-margins set. This way I can view an entire page and move forward/backward with page-up/page-down always viewing a full page.. However, this mode has no vertical scrollbar so to move many pages I have to press and hold page-up/page-down while it slowly pages through the file. I would prefer to have a vertical scrollbar so that I can just scroll to the distant page. However, I can only get a vertical scrollbar in continuous mode. In continuous mode as I move up/down I no longer get full pages. I start to get the bottom part of one page and the top part of another page. Is there a way to be in fit-to-page-size (with trim-margins) and get a scrollbar that causes full pages to be displayed? If not I would like to request it as a feature.

Question information

Language:
English Edit question
Status:
Solved
For:
qpdfview Edit question
Assignee:
No assignee Edit question
Solved by:
Adam Reichold
Solved:
Last query:
Last reply:
Revision history for this message
Best Adam Reichold (adamreichold) said : 		#1

Hello ralph,

what you describe is not implemented, the scroll bars do not know about pages or anything, they just work with the pixels of the display scene which might be a single page or a whole document in whatever layout selected. But you can still use the jump to next/previous page actions in continuous mode, so instead of scrolling continuously, it will jump directly to the beginning of the next/previous page. The default keyboard shortcuts should be space/backspace.

Best regards, Adam.

Revision history for this message
ralphl (lachenmaier) said : 		#2

Adam
Thank you very much. That answered my question and it works as I wanted. I didn't realize that there was a difference between "skip backward/forward" and "previous page/next page". "skip backward/forward" in continuous mode does not skip exactly one page and repeatedly using it causes one to end up in the middle of a page. "previous page/nextpage" always goes to the beginning of a page and repeatedly using it does not cause migration to the middle of a page. So I changed the shortcut for "skip back/forward" to Alt+PageUp/Alt+PageDown" and the shortcut for "previous page/next page" to PageUp/PageDown, and everything works fine.

By the way what is the purpose of "previous page/next page", since its repeated use causes one to end up in the middle of a page. To me this seems to be a not very usefull command.

Ralph

Revision history for this message
ralphl (lachenmaier) said : 		#3

Thanks Adam Reichold, that solved my question.

Revision history for this message
ralphl (lachenmaier) said : 		#4

Adam,
I have to take back a little of what I said above. Although use of "previous page/next page" in continuous mode with "trim margins" set works most of the time, rapid use of it will cause qpdfview to end up with parts of two pages (instead of one complete page) displayed on the screen. I don't know what causes this. It might have to do with my cpu being rather slow.

Thanks again for getting back to me.
Ralph

Revision history for this message
ralphl (lachenmaier) said : 		#5

Adam
In my first comment after your reply, the second paragraph should read:
"By the way what is the purpose of "skip backward/forward", since its repeated use causes one to end up in the middle of a page. To me this seems to be a not very useful command.

Sorry for my mix-up.

Revision history for this message
Adam Reichold (adamreichold) said : 		#6

Hello again,

there are three distinct ways to scroll the document. Move up/down which moves by tiny amount and is intended to continuously scroll through the content. Skip up/down which should move the content by a single screenful, i.e. one can page through the content no matter which scaling was applied. Jump to next/previous page will do exactly that, i.e. paging through a document along its internal structure.

Ending up on the middle of the page when trim margins is active is due to the page sizes changing due to the trimming happening asynchronously after rendering. The latest version from trunk does try to minimize this, but there is currently no sure workaround. This can however be alleviated somewhat by enabling prefetching with a large enough prefetch distance.

Best regards, Adam.