move (pan?) within the page on UP/DOWN

[gasche]

I want a keyboard-only workflow to read PDF documents. Currently the texpresso viewer enables this in fit-height mode, but not in fit-width mode where I have to use the touchpad to scroll through the page.

This naive PR implements "pan up" and "pan down" actions when pressing up/down key. I can now browse through the document by hitting "down" until the end of the page, and then "right" to get to the next page.

Notes:

• I needed to add code to "reset the pan" on {previous,next}_page: when I am at the bottom of a page and press "right", I want to end up at the top of the next page, not at the same position. I briefly tried to understand the size computations to know which value of pan.y to set to be at the top of the page, and gave up; the code use 1. / 0.. Feel free to suggest a better value -- or modify the patch, etc. (Note: previous_page also resets to the top of the page, I am not sure if people would want something different there, maybe start at the bottom of the page?)
• Ideally I could keep browsing with just up/down: when we hit the page boundary, "down" again would go to the next page. I am not familiar enough with the geometry stuff to implement this easily.
• the "pan down" action does not pan by exactly the viewer height, but by 0.9 times that. This helps provide some continuity in the content to know where to restart reading. It might be even better to smoothly scroll to the next position, but I don't know how to implement it, and it might be disturbing to some people, and I don't think it is necessary.

[let-def]

Thanks for the contribution. I started working on your patch to allow browsing with up/down and to compute the right value for panning (rather than using 1 / 0).

I am not satisfied by the current geometry code but this representation was easy enough for a quick'n'dirty renderer. I would like to implement a "continuous" view at some point, with a stream of all pages that can be scrolled through.

For the 0.9 factor, did you try a few other ones? For the SyncTeX code, after some experiments I decided to use the value 2/3 as I felt it gave a good trade-off between scrolling speed and smoothness. Do you have any thoughts about that?

[gasche]

I tried 1, and I didn't like it, and then 0.9. Please feel free to change to 2/3 if you think this is better or just for consistency.

[gasche]

This looks nice, thanks! (I haven't tested it, but I am sure it is an improvement over my first implementation.)

[let-def]

I just added left/right panning. Now only pageup/pagedown change page immediately. I am not sure whether it is useful or not...

I was also thinking about a two columns panning feature: when reaching bottom and the view is not aligned with the right of the document, it would pan right and scroll to the top of the document.

[gasche]

I think that the two-column panning behavior should be configurable, otherwise it could be confusing / not what we want for some workflow.

(Note: maybe there is an even more structured way to handle two-column modes, by letting people define bounding boxes for the columns for odd and even pages.)

[let-def]

I like the patch as it is. I removed the left/right pan feature as it is unclear how useful it is, I merge this PR and will open a new one to track future development.

I agree with that the two columns mode should be opt-in, but this probably requires a better UI that will not happen anytime soon.

Thanks!

[let-def]

It should be possible to infer the two column structure from the DVI (as well as improving cropping, focusing, etc). This also requires too much work to be implemented in the short term.

[gasche]

There is something weird with the new implementation where "down" may pan jump to the following page. Sometimes I am at the bottom of the current page, but pressing "down" does not bring me to the top of the next page, it brings me below the top -- there is a thin slice at the top that I cannot see.

Observed behavior:

• I am at the top of the page
• I press "down", and I get immediately at the bottom of the page
• I press "down" again, and I start below the top of the next page

I observe that this occurs when in "crop border" mode, and only on some pages. I believe that this occurs on page that have more whitespace at the top than the other -- they correspond to the beginning of a chapter. When I am at the beginning of such a page in cropped mode, and I press "right", I end up at the same vertical position on the next page (if we think of coordinates before cropping), which is not the beginning of the cropped page but below it. I get the same behavior if I press "down" twice instead of "right", breaking the possibility of continuous reading. I guess that both those behaviors are small bugs.

[gasche]

(Ah, looking at the diff again I see that this corresponds to the FIXME comments in the code.)

[let-def]

Maybe using +/- inf is the simplest fix :).

[gasche]

I remain unsatisfied with the current behavior: when I try to move through the document using "up" and "down" I am often lost, not sure where I am.

I looked at what Okular does (it's my go-to PDF viewer, but I don't want to suggest that it is the only reasonable model to follow):

• up/down appears to move the view by a small absolute amount (no sure in which unit this is expressed; viewport coordinates? by default nSteps is 10)
• pageup/pagedown move the viewport by its full height, but they use a smooth scroll animation

Source:

• key bindings: https://github.com/KDE/okular/blob/38679152b9f42cd6387d5cefae1e2e8529cda25b/part/pageview.cpp#L2028-L2049
• ScrollDown function: https://github.com/KDE/okular/blob/38679152b9f42cd6387d5cefae1e2e8529cda25b/part/pageview.cpp#L5217-L5239

Maybe I should try to implement a smooth scroll animation on up/down in Texpresso to feel less lost?