Pagination function

[tcitworld]

Received through Google Play email contact.

Hi

I'm very interested in your service, as I'm looking for a non - US based archiving/reading app.

I'be been trialing your android app and I've noticed the pagination function has a small glitch. Lines are often cut off half way through, and then on the next page, again half of the text is displayed.

I've attached two screenshots to illustrate.

I'm emailing to ask whether you'll consider fixing this /developing the pagination function further. Paginated reading is a must have for me, so I want to be sure this feature won't disappear and will be fixed before signing up.

[di72nn]

I don't think it can be considered a bug (non-touch scrolling was never a proper feature, it's not on by default). I do agree it should be improved though.

However, I don't know how to approach it better.
The webview currently takes all the vertical space it needs (i.e. no scrolling inside webview), so purely-JS-based scrolling won't work.
Suggestions are welcome.

Pagination was also mentioned here.

Regarding this particular case: it is possible to reduce the "percent of screen height to scroll" to at least don't have lines that are cut on both sides of scrolling.

[simon-20]

Hi,

I submitted the "bug"/"non-bug" report.

On the general point: for me as a user, pagination is a make-or-break feature. It is much, much easier to read (easier on the eyes) with pagination turned on. I think there is research on how pagination aids reading because it's easier on the eyes, since it means one always knows where to look next, whereas when you scroll up manually, you never perfectly get the new top line in exactly the same position. (It's similar to how non-justified text makes reading easier.).

With respect to the particular case: I tried adjusting the "percent of screen height to scroll" to get round the split lines issue. I couldn't find any value that made any difference on this. Could you post what values worked for you?

[simon-20]

Incidentally, if there's a feature that's available in the app, then even if it is not turned on by default, it seems fair enough to call a problem with that feature a bug, if it affects the main purpose of the app, which is reading text (and one can't read split lined text).

I realise it doesn't make much of a difference, except, if it's labeled a bug, maybe it'll be addressed sooner?

Anyway, I appreciate all your work. I will subscribe to the thread for updates.

[di72nn]

Could you post what values worked for you?

I don't often use it, so I only know that reducing the value should reduce the amount of text that is cut by increasing overlap.

if it's labeled a bug, maybe it'll be addressed sooner

I don't think so, considering the lack of development time.

It seems to me that implementing it properly may take a significant amount of work (and I still don't know where to start), I'm not aware of any simple non-proper, but "good enough" approaches.
Suggestions or maybe good examples (preferably in FOSS apps) are welcome.