GNOME Bugzilla – Bug 596888
Provide some indication that search is not available
Last modified: 2018-05-22 13:38:43 UTC
I just opened a .ps file and tried to search within it. I typed Cntl+F, "/", Alt+F, clicked the content pane to make sure it had focus and then repeated. Then started looking through the menus. Wasn't sure what was going on. Finally realized that search may be disabled for this type of document. We should probably show a simple indication that search is not available in these cases.
I agree, but I don't how to expose that in the UI. Do you mean showing an info dialog (well in the message are actually) when trying to search? or any other idea?
you could use the infobar we have in gtk now
(In reply to comment #2) > you could use the infobar we have in gtk now We already use it indeed, that's what I meant with "message area" (hmm, there was a typo there :-P)
Seconded: I just had similar confusion with a DVI document. In particular, I pressed "/" and nothing happened; there should be some feedback to tell me that I can't search.
A quick "Search not available for this document" infobar along with a beep might be a simple solution.
Created attachment 146033 [details] [review] a patch adding warning for search in a non-searchable document Hi, this patch shows warning for a situation when a non-searchable document is opened and user presses "Ctrl-F" or "/". The text is "The document doesn't support search". It doesn't show it when there is no document. It is implemented through a new action since insensitive actions are not activated (Edit->Find...). Its name is "CtrlF" and is sensitive in the case of non-searchable document (except the situation with no document opened). Regards Marek
*** Bug 166285 has been marked as a duplicate of this bug. ***
Hi, I ran into this problem not knowing a pdf could consist only of an image. Simple-scan for example saves it's multipage scans as pdfs. I feel I've been mislead when the app say's it didn't find a word, where in reality no searchable text was in the document. This is not always transparent for the user. The above described patch is fine for me. But let me word the requirement more broadly: Any filetype that can be shown with evince that does not have any (via ctrl-f or edit,find) searchable content, shouldn't - display the search-bar / offer find in the edit menu - allow inputting a search term - and return "0 found on this page" as though a search had taken place. Ideally: - edit, find is greyed - ctrl-f gives an acoustic warning / message as in the patch But this covers probably just a small number of use cases - pdfs completely without text. For most cases there will be mixed (image/s and text) pdfs. But these can be misleading. For example 75 pages scanned texts (image) and one line of searchable text. A possible solution could be a visual cue - images and text with different, very light colored backgrounds (or frames). And so as not to interfere with a true representation of the document, the coloration would only take effect when activating search (ctrl-f / edit, find). okay. file it under nice to have but not feasible. (But it would be the right thing)
Review of attachment 146033 [details] [review]: I like this, although it does not solve the complete problem, we don't have a way of knowing whether a PDF has text embedded and hence poppler will search something or not. Still, don't know if the message is the correct one, as it's evince which does not support search for backends different from pdf one.
-- 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/105.