After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 598759 - Ignore spaces when searching in PDF files with OCR
Ignore spaces when searching in PDF files with OCR
Status: RESOLVED OBSOLETE
Product: evince
Classification: Core
Component: PDF
2.26.x
Other Linux
: Normal enhancement
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-17 11:43 UTC by Simon Eugster
Modified: 2018-05-22 13:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Simon Eugster 2009-10-17 11:43:55 UTC 
Because: I've got a PDF here with the word «Lemma» in bold type. I cannot find it by searching for «Lemma» but only «L e m m a».

Ignoring spaces (perhaps with an option to switch it on/off) would be an easy workaround. Fixing the whole OCR might be a little more complicated ...
Comment 1 Sven 2013-03-18 04:52:55 UTC 
I don't know why you speak of OCR. I see the same problem with LaTeX generated PDF files. There's absolutely no OCR involved.

\documentclass{article}
\begin{document}
TODO
$TODO$
\end{document}

Compile the above tex document with pdflatex, and search for TODO. The first TODO is found, the second is not. Now search for "T ODO". The second TODO is found, but not the first.

Adobe Reader is able to find both TODO strings when search for TODO.
Comment 2 GNOME Infrastructure Team 2018-05-22 13:40:08 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/111.