Bug 386110 - ctrl+f highlighting only works for low zoom levels
Summary: ctrl+f highlighting only works for low zoom levels
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: 1.2.70
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-23 14:08 UTC by Oliver Sander
Modified: 2017-11-23 23:30 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Sander 2017-10-23 14:08:14 UTC
When searching for text with ctrl+f, the found text is highlighted by yellow rectangles.  However, this only works at low zoom levels (wild guess: all zoom levels that work without tiling).

Steps to reproduce:
- Open any pdf document that contains text
- Search for a word that exists in the text
- If yellow highlight appears: zoom into the word, eventually
  the highlight will disappear
- If there is no highlight: zoom out, it will appear eventually.

I think (but didn't test) that this is a regression introduced by the hidpi branch.
Comment 1 Albert Astals Cid 2017-10-24 22:14:04 UTC
Hmmm, seems to work here, i opened https://ev.kde.org/reports/2017-en.pdf zoomed to 1600% and searched for minutes and it showed up yellow, does that work for you?
Comment 2 Oliver Sander 2017-10-25 08:11:05 UTC
No, it doesn't.  The searching itself works, but there is no highlighting.

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 David Edmundson 2017-11-15 23:05:17 UTC
Page painter line 117

if ((*hIt).intersects(limitRect))


is failing when it shouldn't.

If you move the highlight into the top left quarter of the screen then it comes visible.

The bufferedHightlight rect is fine, so it's our calculation of limitRect that's wrong.
Comment 4 Albert Astals Cid 2017-11-15 23:34:00 UTC
Note intersects is really funny and may not be doing what you expect, i.e. if two rectangles share an edge, they intersect.

That bit me a bit recently and i have a branch that changes some intersects() to calculating the intersection and checking for width > 0 && height > 0
Comment 5 David Edmundson 2017-11-23 23:04:26 UTC
Git commit 1a3dc7d8e05fe0cd2d83ad5ed6365045e3f8e202 by David Edmundson.
Committed on 23/11/2017 at 23:04.
Pushed by davidedmundson into branch 'master'.

Fix highlight/annotation clipping with Qt scaling

Summary:
pixelValue/pixelValue will give us a normalised value.

Normalised values shouldn't be modified by a device pixel ratio.
We want scaledRect not dScaledRect.

Test Plan:
Searched for text. Zoomed in, panned about
Created annotations, they still seemed to work

Subscribers: #okular

Tags: #okular

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

M  +4    -4    ui/pagepainter.cpp

https://commits.kde.org/okular/1a3dc7d8e05fe0cd2d83ad5ed6365045e3f8e202
Comment 6 David Edmundson 2017-11-23 23:30:55 UTC
Git commit ab433f701af8b64182184fc41f950d6dd246fbc2 by David Edmundson.
Committed on 23/11/2017 at 23:29.
Pushed by davidedmundson into branch 'Applications/17.12'.

Fix highlight/annotation clipping with Qt scaling

Summary:
pixelValue/pixelValue will give us a normalised value.

Normalised values shouldn't be modified by a device pixel ratio.
We want scaledRect not dScaledRect.

Test Plan:
Searched for text. Zoomed in, panned about
Created annotations, they still seemed to work

Subscribers: #okular

Tags: #okular

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

M  +4    -4    ui/pagepainter.cpp

https://commits.kde.org/okular/ab433f701af8b64182184fc41f950d6dd246fbc2