Bug 266535

Summary: Searching for an asterisk skips over the second asterisk in a pair of adjacent asterisks
Product: [Applications] okular Reporter: Eike Hein <hein>
Component: generalAssignee: Okular developers <okular-devel>
Severity: normal    
Priority: NOR    
Version: 0.11.2   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description Eike Hein 2011-02-17 16:58:10 UTC
The affected Okular version reports itself as 0.11.2, but is a recent SVN checkout of trunk.

Secondly, let me preface this by saying that '*' refers to a literal, single asterisk character throughout this report, not to a matching/globbing expression.

The behavior I'm seeing happens while searching for '*' in a PDF document. The document is a book, written in English, containing both regular prose writing and code listings written in Python. Embedded both in the regular English prose writing and the code listings are many occurences of '**' (i.e. a pair of adjacent asterisk characters, the power operator in Python), sometimes several per page, and on many pages.

Using Okular's search feature (accessed by Ctrl+F) to search for '*' in this book always only marks and jumps to the first '*' in any occurence of '**'.

In other words, a search for '*' may yield the following result, where <> are used to denote the yellow (in the default color scheme, at any rate) marking Okular paints:

[...] <*>* [...]

Clicking "Next" on the search bar now will not produce the expected result of marking the second '*' in the same occurence of '**':

[...] *<*> [...]

Rather, it will jump to the next occurence of a single asterisk or the first asterisk in a pair of asterisks elsewhere in the text.

I initially assumed there may be some magic there that intentionally produces this behavior if the subject of a search is found several times adjacent to each other, but Pino Toscano has indicated this is not the case, so this is likely a bug.
Comment 1 Eike Hein 2011-02-18 15:26:39 UTC
Addendum: It only happens on forward search, not backward.

So it's probably a bug (off-by-one or so) in TextPage::findTextInternalForward ...
Comment 2 Albert Astals Cid 2011-03-09 00:48:23 UTC
SVN commit 1224201 by aacid:

Fix off by one error on setting the search boundary limits
Fix researched by Christopher Reichert
Will backport to 4.6 if works fine in trunk for a while
BUGS: 266535

 M  +1 -1      textpage.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1224201
Comment 3 Eike Hein 2011-03-09 04:28:05 UTC
Thanks Christopher! I tried your patch both on the original book I had the problem with and a specially-crafted test document that contains nothing but the string "**" to make sure it also works fine at the document start and end, and indeed your patch seems to have fixed the problem. I'll backport it to the 4.6 branch.
Comment 4 Eike Hein 2011-03-09 04:46:10 UTC
SVN commit 1224223 by hein:

Backport r1224201 from trunk, fixing an off-by-one in the forward
search code. Original patch is by Christopher Reichert.


 M  +1 -1      textpage.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1224223