-
-
Notifications
You must be signed in to change notification settings - Fork 296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
smooth 1:1 horizontal scrolling gesture for touchpads #862
Comments
That would be a great feature. It would feel closer to read a book (turning a page). Kooha-01-26-2022-18-06-21.mp4 |
This is basically the same as continuous scrolling, except with snapping. You need to prefetch and render adjacent sections and try to maintain current scrolling position while doing that. So it's possible, but bit tricky to implement, and it will make performance even worse than it already is, especially when rendering long sections. One idea that would make things a lot simpler is to do this only for in-section navigation. The downside is that when you go to the next or previous section, the new section would not slide in as you scroll. Instead you only start loading the new section after you've swiped out the current section. Another point that I should mention is that this can problematic for vertical writing. You could make the pagination work like horizontal writing except rotated 90 degrees, but that's not really how a real book would flip. I think there are some non-standard CSS properties in WebKit that can fix this but the downside is that it's non-standard and can stop working at anytime if Apple decides to remove it. All of the above apply if there is to be any sliding animation. Whether it follows the input 1:1 or not is a minor detail that can be readily solved once you've successfully set up the whole thing. All this is for reflowable books only. For fixed layout books things are much, much easier. So another option would be to start by adding it only for fixed layout books. Also there's an additional complexity if this is to be built on Epub.js. Epub.js's codebase is already pretty complicated and there are sometimes weird sizing bugs that I just can't figure out. It's probably unwise to modify Epub.js for this. Instead it might be easier to write a new pagination library. |
Well, Epub.js does already have a continuous paginated mode. So I think this is might not too hard to do. Using this continuous paginated layout, one can do the following:
One issue is that Epub.js doesn't expand sections to create blank columns in this mode. This might seem trivial to some people, but it results in inconsistent layouts where a section sometimes starts verso, and sometimes recto, depending where you start paginating. This means that the position of some text can change sides after, e.g., clicking on a TOC item. And this can be disorientating. In non-continuous mode, a section always starts from verso. Ideally with continuous pagination one could make it always start from recto as is commonly found in physical books. But to simply things, one can start by modifying Epub.js to expand to full page widths whether in continuous mode or not. |
Thank you for the extensive replies! Definitely the built-in continuous paginated mode seems the way to go. Subjectively, the recto-verso section issue is not so important to me. |
Just another note, as with continuous scrolling, things get complicated if you have mixed directions. The difference is that continuous scrolling requires uniform block direction, while this requires uniform page progression direction. One option is to force the same direction for all section documents. This will probably be fine for 99% of books. Another, probably better option is to use the non-standard The last option would be not forcing a uniform direction for page progression. This will probably result in a more confusing user experience, but has the advantage of, well, allowing you to have mixed page progression direction. And speaking of mixed layouts, technically EPUB supports mixed pre-paginated (fixed layout) and reflowable documents in the same book, as well as mixing scrolling (continuous or not) and paginated layouts in reflowable sections. I don't know if this is supported by any reading system at all. But still it's just something to consider. |
Just found a link documenting |
I've added a basic sliding effect (not 1:1) with the new renderer in the gtk4 branch. It still only renders one chapter at a time. For inter-chapter transitions, the old chapter slides out, but the new chapter is displayed without any animation. Essentially the trick described in my first comment. It doesn't follow the gesture 1:1 but seems to work well enough. Experimenting with it a bit, I feel that a problem is that there's no clear separation between spreads. This will make it quite disorientating if you make it 1:1. If this is ever to be implemented, a better way might be to do this in GTK, with the approach outlined here: #188 (comment). This would allow one to make the spreads stack, similar to the back/forward navigation gestures in Epiphany/WebKitGTK. And it would sidestep all the problems related to CSS columns. |
Added 1:1 touchscreen gestures to the new renderer (johnfactotum/foliate-js@772cbe0). Unlike touchscreens, however, there's no DOM event for touchpad scroll end. So doing it for touchpads would require connecting to the |
Amazing !!! |
Is your feature request related to a problem? Please describe.
When scrolling horizontally for turning a page using a touchpad there is no animation, and the page changes suddenly. This lack of action feedback during the action itself may be confusing sometimes.
Describe the solution you'd like
A transitional 1:1 animation for changing the pages, much like the workspace switch animation present in Gnome 4X.
The text was updated successfully, but these errors were encountered: