Bug 172244

Summary:	find ignores spaces
Product:	[Applications] okular	Reporter:	Marcel Partap <mpartap>
Component:	general	Assignee:	Okular developers <okular-devel>
Status:	RESOLVED FIXED
Severity:	normal	CC:	Regnaron
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:

Description Marcel Partap 2008-10-05 23:55:17 UTC

Version:           0.7.80 (using 4.1.68 (KDE 4.1.68 (KDE 4.2 >= 20081001)), Gentoo)
Compiler:          x86_64-pc-linux-gnu-gcc
OS:                Linux (x86_64) release 2.6.27-rc8-git1

Problem is, i want to search a document for the occurrence of tick as a word, the author is Thomas Schwentick and his name is in a small signature on every page of the 126 page document. Adding a space before tick does not give the expected result: Schwentick is still matched even though it clearly does not contain a space. *annoyed*

Comment 1 Pino Toscano 2008-10-06 00:30:37 UTC

Can you please attach the "problematic" document?
Without it, there's really nothing we can do.

Comment 2 Oliver Putz 2008-10-15 19:02:42 UTC

I think I have the same problem. In general, okular seems to treat whitespaces in the search field as wildcards. As a usecase where this problem surfaces: Think of a mathematical document where you want to find the letter "T" (referring to some particular structure for example).

Searching for ' T ' as well as searching for '" T "' results in words like "The" to be found too.

So I would suggest that okular either adds the possiblity to search for regular expressions, or that some special character (e.g. "") makes each character in a "query" count (including the spaces)

Comment 3 Pino Toscano 2008-10-15 20:01:26 UTC

> I think I have the same problem.

"I think" does not makes bugs confirmed (so don't do, please).

> In general, okular seems to treat whitespaces in the search field as wildcards.

It does not.

> Think of a mathematical document [...]

A PDF document can be made up in many ways, and so the "text" inside it.
Remember: what is you see in a PDF document does imply *nothing* about its text.

> So I would suggest that [...]

We need test documents, not suggestions or speculations.

Comment 4 Oliver Putz 2008-10-16 09:46:48 UTC

Well, it happens with pretty much every document I tried, but try

http://www.emis.de/journals/JGAA/accepted/2007/Eppstein2007.11.1.pdf and search for the single letter SPACE n SPACE for example. (the first match will be the "n" in the "and" of the title of the pdf)

Another example is

http://dip21.bundestag.de/dip21/brd/2007/0798-07.pdf where searching for SPACE in SPACE will find the in within "Richtlinie" on the first page...

Comment 5 Pino Toscano 2008-10-19 11:43:26 UTC

(In reply to comment #2)
> In general, okular seems to treat whitespaces in the search field as wildcards.

No, Okular just ignores whitespaces in the query, as I just verified.
(Still have to figure out why, as that logic comes from the very first(!) oKular (as it was named at that time) implementation.)

Comment 6 Pino Toscano 2008-10-19 11:55:37 UTC

SVN commit 873277 by pino:

Do not ignore (white)spaces in the search query when searching within the text of a page;
search verbatim in the text page, while any other change in the query should be done at a Document level.

BUG: 172244


 M  +0 -16     textpage.cpp  


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

Comment 7 Pino Toscano 2008-10-19 11:56:16 UTC

SVN commit 873278 by pino:

Backport: do not ignore (white)spaces in the search query when searching within the text of a page.
Will be in KDE 4.1.3.

CCBUG: 172244


 M  +0 -16     textpage.cpp  


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