Bug 266535 - Searching for an asterisk skips over the second asterisk in a pair of adjacent asterisks
Summary: Searching for an asterisk skips over the second asterisk in a pair of adjacen...
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 0.11.2
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-17 16:58 UTC by Eike Hein
Modified: 2011-03-09 04:46 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.

CCBUG:266535


 M  +1 -1      textpage.cpp  


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