GNOME Bugzilla – Bug 604327
Command line search -l/--find option don't search.
Last modified: 2013-05-07 16:57:45 UTC
Cannot search string with the -l option. evince -l word -p 20 test.pdf Only jump to the 20th page but don't search. Apparently, in ev-window.c, ev_application_open_uri_in_window() does not setup a search job. It only fill the search widget with the search string. I suppose on start with a given search string and a page number, the search will automatically search the string on the given page, i.e. high light the string. Acrobat reader will highlight keywords: http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf
Besides, if the PDF is already opened, the search string would not be set in the search widget of the existing window.
I confirm this bug in the latest version (2.30) too. The findbar is drawn at the beginning and the search string is set up correctly, but it loses focus again when the document is read. The solution might be trying to make it load the document before it tries to search or opening the findbar every time a new document is read and the findbar was focused.
Possible duplicate: https://bugzilla.gnome.org/show_bug.cgi?id=604327 These are related bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=611619 https://bugzilla.gnome.org/show_bug.cgi?id=694143
Please disregard the first link I posted. This report is the one I actually meant: https://bugzilla.gnome.org/show_bug.cgi?id=694056
*** Bug 694056 has been marked as a duplicate of this bug. ***
To make things easier for future readers I'll quote what I posted in the other bug report: The --find switch does work, but only after engaging the search. See here for reference: https://www.youtube.com/watch?v=GeeIBP8PbGE Recoll (the full-text search tool used in the video above) passes the search string to evince via the --find=STRING switch. The advantage of this behaviour in the use case above is that it allows the user to check the page for any obvious hits before engaging a CPU intensive search. So while it makes sense to fix this regression it might also be a good idea to implement a switch between directly engaging a search and only passing the search term to the search field (e.g. --find=STRING and --searchfield=STRING).
Fixed in git master and gnome-3-8 branch. Thanks for reporting.