Bug 101020 - Add setting in Writer for changing scroll granularity to a single line
Summary: Add setting in Writer for changing scroll granularity to a single line
Status: RESOLVED DUPLICATE of bug 46988
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
Keywords: needsUXEval
Depends on:
Reported: 2016-07-19 20:18 UTC by J22Gim
Modified: 2016-08-04 21:56 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description J22Gim 2016-07-19 20:18:37 UTC
I'm not sure if this should be called a bug and I don't know if it's LO's fault or it comes from my OS, but but it is certainly annoying :p

I see also that it was commented months ago (*), with no answer, so I try here.
(*) https://ask.libreoffice.org/en/question/52242/how-to-change-single-line-scrolling-behavior-in-writer/

I have observed that when reading a multi-page text in LO Writer (or in anything which shows readable text in the screen, for that matter), there are basically two reading behaviours. Intermittent scrolling or continuous scrolling.

Intermittent scrolling: Some people start reading from some upper part of the screen and when they reach the "bottom" of the screen they scroll down (eg. press PageDwn or click teh scroll bar) so now they see the "next" screen, somewhat "full of new text". So the reader starts reading in the upper section of the screen again. And repeat through a number of screens, until they reach the end of the document.

Continuous scrolling: Another behaviour is more "continuous": the person starts reading in a given place of the screen, and then keeps moving the cursor as he/she reads. This means for example pressing the "down" arrow of the keyboard every time the reader reaches the end of a line (I even accompany the cursor together with my eyes, so I'd keep the "right" arrow pressed all the time). Therefore when the reader reaches the end of the screen, the text simply "flows up" in the screen as the reader presses the "down" arrow, thus continuously feeding the text up in the screen. This may sound complicated to people who use the "broken reading".

If you are "intermittent scrolling" reader, no problem for you in LibreOffice Writer. If you are "continuous scrolling" reader like me, then you suffer with this annoying behaviour: when you reach the end of the screen while reading text and press the "down" arrow (or the right arrow when reached the bottom-right frontier of screen text!), instead of the expected (by me anyway) behaviour which would be to advance ONE line, Writer advances like 8 lines!! Therefore in the exact physical place where you expected to see the next line of text, LO's Writer actually shows a completely different thing (maye the beginning of the next paragraph!) which is VERY confusing and annoying.

Truth to be said, I did not check how other word processors handle this but I can say it is certainly not intuitive. If the idea was to consider both intermittent and continuous scrolling readers, then I suggest to place an option in the configuration where the user can chose how many lines will be fed every time the cursor reaches the bottom (or top, if you're scrolling up) of the screen.

Build ID: 1:5.1.4-0ubuntu1~trusty1
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default;
Comment 1 Aron Budea 2016-07-20 01:13:50 UTC
There is a setting to make scrolling smoother in 'Tools -> Options... -> LibreOffice Writer -> View -> Smooth scroll'. While it's not what you're suggesting, it should make the behavior somewhat less annoying for now.

I could imagine more fine-grained settings to control scroll smoothness/granularity (these seem to be settings each people can have very fine-tuned preferences towards), let's hear what the UX guys have to say.

I noticed the Smooth scroll setting does not affect mouse scrolling, I wonder if that is intended.
Comment 2 Aron Budea 2016-08-04 21:56:35 UTC
I just noticed this is pretty much the same as bug 46988.

*** This bug has been marked as a duplicate of bug 46988 ***