Bug 386111 - Selecting text moves it one pixel towards the bottom
Summary: Selecting text moves it one pixel towards the bottom
Status: CONFIRMED
Alias: None
Product: okular
Classification: Applications
Component: general (other bugs)
Version First Reported In: 1.2.70
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-23 14:25 UTC by Oliver Sander
Modified: 2025-06-30 21:17 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Not selected, missing line, thin j in project (352.92 KB, image/png)
2025-06-28 11:10 UTC, ratijas
Details
Selected, everything looks right (354.44 KB, image/png)
2025-06-28 11:10 UTC, ratijas
Details
Line annotation used to draw, the wrong way (776.25 KB, video/mp4)
2025-06-30 21:17 UTC, ratijas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Sander 2017-10-23 14:25:00 UTC
I think the following is a regression introduced by the hidpi branch:

- Open any pdf document
- Switch to selection mode (ctrl-3)
- Select any piece of text

When looking closely, you will see that the selected text has moved a small amount towards the bottom of the page.  Unselecting it moves it back to its original position.
Comment 1 Albert Astals Cid 2017-10-24 22:16:05 UTC
I don't think i can reproduce it either (you mean Ctrl+4, right?)

Could you link the file you're using and maybe some screenshots?
Comment 2 Oliver Sander 2017-10-25 08:12:51 UTC
> I don't think i can reproduce it either (you mean Ctrl+4, right?)

No, I mean Ctrl+3.

I found out that it has to do with display scaling.  On my system, 

~/okular(master)> echo $QT_SCREEN_SCALE_FACTORS 
eDP-1=1.5;DP-1=1.5;HDMI-1=1.5;HDMI-2=1.5;DP-1-1=1.5;DP-1-2=1.5;DP-1-3=1.5;

If I replace all these 1.5 by 1.0 then the bug disappears.
Comment 3 Albert Astals Cid 2018-03-03 23:57:00 UTC
yes, i can reproduce when using QT_SCALE_FACTOR=1.5
Comment 4 David Edmundson 2018-04-09 21:58:51 UTC
Git commit 804d0bd42a23488a6bbd8090ee2590871ddeb64e by David Edmundson.
Committed on 09/04/2018 at 21:58.
Pushed by davidedmundson into branch 'Applications/18.04'.

Fix rubber band selection drawing contents misaligned with scaling

Summary:
in drawPixmap(source, sourceRect) the source rect is in native pixels.

In this code the size was scaled by the DPR, but the location was not.
blendRect is the contents of a selection rectangle, offset from the
bounding darker blue rectangle. Hence we haven't really noticed.

This completely fixes the rectangle when the scale == 2.0/3.0

Some smaller artifacts remain on fractional scale factors, which is a
separate code bug with the same symptoms.

Reviewers: aacid, rkflx

Reviewed By: rkflx

Subscribers: sander, rkflx, anthonyfieroni, #okular

Tags: #okular

Differential Revision: https://phabricator.kde.org/D8980

M  +3    -2    ui/pageview.cpp

https://commits.kde.org/okular/804d0bd42a23488a6bbd8090ee2590871ddeb64e
Comment 5 ratijas 2025-06-28 11:10:12 UTC
Created attachment 182755 [details]
Not selected, missing line, thin j in project

…or one pixel towards the right. Actually, shifted representation (with some text selected) is correct, while unshifted really cuts out one column of pixels from the horizontal middle of the left page: on the attached screenshot collage notice how thin is "j" in "project" on line 3 without selection.

Full Screen, but can happen at every second window size (probably needs to be divisible by 2 with a remainder of 1, or something like that).
View Mode: Facing Pages
Zoom: Fit Width

Monitor: 2560x1600
Global Scale: 150%
QT_SCREEN_SCALE_FACTORS: eDP-1=1.5

Operating System: Arch Linux 
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.2-arch1-1 (64-bit)
Graphics Platform: X11
Graphics Processor 1: AMD Radeon RX 7700S
Graphics Processor 2: AMD Radeon 780M Graphics
Comment 6 ratijas 2025-06-28 11:10:29 UTC
Created attachment 182756 [details]
Selected, everything looks right
Comment 7 ratijas 2025-06-28 12:41:19 UTC
Actually if I zoom it out small enough, pages squeeze vertically (missing horizontal line of pixels) too. It happens on a per-page basis, i.e. only affects pages across which spans the selection. Also, happens in any View Mode: Single Page, Facing Pages, Facing Pages (Center First Page) and Overview.

In Overview there are 3×3 grid of pages, horizontal line is missing only from one row of pages (which one — it's not consistent, might depend on scroll position or something, but so far it's always pages of the same row and never more than one row). Vertical lines are missing from all pages.
Comment 8 ratijas 2025-06-30 21:17:58 UTC
Created attachment 182815 [details]
Line annotation used to draw, the wrong way

This one is even better