Bug 421950 - Page Up/Down overlap setting no longer does anything
Summary: Page Up/Down overlap setting no longer does anything
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: 1.10.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-05-23 06:44 UTC by Oscar Megia Lopez
Modified: 2020-09-29 15:38 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.11.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oscar Megia Lopez 2020-05-23 06:44:34 UTC
SUMMARY

Setup Page Up/Down overlap to 50% or 0% does not make any difference.
If a line is cutted after press Page Up/Down is cutted in the other half in both settings.

STEPS TO REPRODUCE
1. Setup Page Up/Down overlap to 50%
2. A line is cutted at end of page.
3. Press Page Down.
4. The line is cutted by other half.

The same issue if setup Page Up/Down overlap to 0%

Evince does not cut text lines and have a line overlap that make easier reading pdf files.

OBSERVED RESULT

The page's last line is unreadable in both pages.

EXPECTED RESULT

The page's last line must be readable in both pages.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Archlinux kernel 5.6.13-arch1-1
(available in About System)
KDE Frameworks 5.70.0
Qt version: 5.14.2 (compiled with 5.14.2)
Windows system xcb
KDE Plasma Version: 5.18.5

ADDITIONAL INFORMATION
Same issue in OpenBox.
Comment 1 Albert Astals Cid 2020-05-23 14:21:58 UTC
Another thing that regressed because of the QScroller patches :(
Comment 2 Nate Graham 2020-09-14 17:10:19 UTC
I didn't ever know what this setting was for, and to be honest even after reading the bug report, I'm still not sure I totally understand. Now, there's definitely a bug in that it stopped working, but I wonder if it might make more sense to have a sensible overlap amount by default rather than making it user-configurable but zero by default.

Thoughts?
Comment 3 Albert Astals Cid 2020-09-14 21:16:51 UTC
Sorry but no, the feature was broken, the feature needs fixing.
The feature is there because people use it (and hence there's a bug report about it when it broke).

The feature is quite simple, it let's you configure how much of the previous viewport you get to see when moving a viewport down/up by pressing page up/down keys
Comment 4 Nate Graham 2020-09-14 23:06:07 UTC
Sure, we need to fix it for sure. I was wondering if we might set a different default setting after it is fixed (obviously).
Comment 5 Albert Astals Cid 2020-09-14 23:13:10 UTC
(In reply to Nate Graham from comment #4)
> Sure, we need to fix it for sure. I was wondering if we might set a
> different default setting after it is fixed (obviously).

I don't know, i tend to prefer being conservative in changing things that have been the same for a long time.

I guess one way would be having kuserfeedback report how much people change this setting (we don't have kuserfeedback at all)

Or doing a poll blog about it.

*my personal feeling* is that maybe 0 is not "the perfect value", but it's a value everyone can agree makes some sense as default, and if they want to tweak it, they can.

If we set it to 2%, some people will say "what 2% makes no sense, should be 3%" and others will say "make it 0%, why are you making page down not do a page down"
Comment 6 Nate Graham 2020-09-15 02:40:58 UTC
Well with 0%, you're still vulnerable to that: people can say "why are lines cut off by default, and why isn't there a sane default for this setting?" :)
Comment 7 Kishore Gopalakrishnan 2020-09-27 09:38:47 UTC
Hi. I've left a pull request here: https://invent.kde.org/graphics/okular/-/merge_requests/288
Comment 8 Nate Graham 2020-09-29 15:38:18 UTC
Fixed by Kishore Gopalakrishnan with https://invent.kde.org/graphics/okular/-/commit/740318df9022f27ec07eb77f2d01fda802ce4018 in Okular 1.11.2!