Hey!
Currently in the book view when you go to the next page with the right arrow it goes at the top of the page.
I’d like to have it keep the scrolling position.
An example use case is when the page template has a large top margin which is constant over the document so you want to scroll down and just keep that scroll because you don’t need to scroll over the text as it fits the screen. As screenshots are worth a thousand words :
Hmm scrolling two pages at a time is part of the 3.4 pre-release using facing or book modes since it is same as for PDF.
In previous versions 2 to 3.3.3 you would need to use Fixed Page UI which in version 3.2 was easy to toggle on off but toggle was not included in 3.3.3 thus again needed advanced manual setting. However mouse scrolling should still shift the full pages up or down two at a time.
I think you missed the point, I was talking about keeping the scroll position when going to the next pages, not about scrolling two pages. Or did I misunderstand your message?
Sorry I am not clear on your problem once view & zoom is set it should stay constant (Unless set to auto fit width/content) scrolling similar size pages as shown in both above examples of both interfaces, should not change that from pages to pages, unless the page changes shape like sometimes happens in a comic book.
If you need a programmable place on page like scroll down 50 pixels or go x pixels towards right hand page then that needs to be written as a custom user command (will work in PDF but not sure if possible in an eBook format). and depending how done requires a shortcut written as ALT F something, (cannot be just one key unless written in AutoHotKey)
Ok it seems your need is as described in
But that would need a custom solution similar to that written by that user. There is no feedback as to where user has currently zoomed to be applied to next page, (it might be possible in some but not all cases. So the simplest solution is for each document specify a false top of page (PDF has no margins as such, is just big white space without printing) and custom zoom offset (margin) from left. Never tested if that is possible in current ebook view, but should still work for PDF so may work with eBooks ?
That’s exactly the same issue indeed!!
So, I read the conversation, attentively, multiple times, and, I have trouble understanding why coding such a vertical scroll keeping feature would be harder than the horizontal existing one. (english is not my native language which doesn’t help)
PDF pages have no values for margins especially when using images or vectors, only fonts may give a clue where the ink might be found, and many pages have a top line or sideways text to ink print for page number or title, so no way to know where the content may be desired by a human. Every document can vary so not much use having a default setting that needs constant change. Agreed a set of say Music sheets may all have similar positions for the violin lines of text but that would also be a moving target, from composer to composer.
It would be a useful feature but can be variable for each format so in the past Mobi page scaling would be different to PDF and different for Comic images. With the more standard use of FixedUI perhaps that is less of an issue now but every user will still want different settings for different documents.
We’re not talking about automatically detecting where the content is. We’re talking about the user moving manually the viewport on the area he wants and just keep that area.
I mean, you already do just that horizontally. I can’t see why custom margins or content borders detections would be needed for that.
in Continuous mode the view-port does not work simply by page in effect the top of file moves upwards, you can argue that the top of pages should also be known by calculating from the zoom (which is the case with single pages.) but in continuous scroll the view-port is shifting.
Using Ctrl page move it can be reset to top of next page, and then a given value could be applied but it would need to be stored as a constantly shifting line in the sand of the previous page.
I am not the developer so cant say its a real problem but would be another slowdown for the majority of users. That feature may be in the more bloated Acrobat, since It has view-port thumbnails, that may be carried over fixed page to page ?
Yes SumatraPDF could perhaps be the first to provide such a method in a lighter-weight viewer but someone needs to code it.
I really can’t see it as a slowdown or a bloated feature, it’s just a little calculation, and a feature which would greatly help improving the UX.
Or maybe just reset at (the top of the page + the value)?
And yes someone would need to code it indeed, but it’s not urgent. It should just be taken into consideration for potential further adding, it would be great I think.
