Improve highlighting of search results

[Ari]

Hi there,

qpdfview's PDF search is one of the fastest I've encountered on linux. That and the fact that the search bar is persistent across different tabs and doesn't just close as soon as it loses focus makes qpdfview my favorite PDF viewer to search through documents. With that said, I think there still are a few points that could be improved. I have taken the liberty to compile a small list of improvements that I think could make qpdfview's search even better than it already is.

(I hope you don't mind me posting these in one central bug report. If you want me to split the requests up into several reports I'll gladly comply.)

### 1.) Add a pause button ###

## Overview ##

Especially with larger documents sometimes you want to only search through a limited number of pages and highlight the results without having to go through the whole document. Right now you can either let the search process the whole document or quickly search and abort while leaving the results unhighlighted. I think a middle ground in form of a "pause" button would serve qpdfview very well. This is important when handling large 100+ page documents.

## Suggestions on implementation ##

I could imagine a small button in the search bar positioned in front of the "cancel" button. This button would be grayed out if no search was in progress or paused, change into a "pause" button as soon as a search is engaged and transform into a "continue search" button as soon as it's pressed. Pausing the search would restrict the result list to the hits found up to this point and "find next" and "find previous" would allow you to jump between them. Reengaging the search would not search through the document anew but start right where you left the search and continue until either the document end is reached, the pause button is pressed or the search is cancelled.

### 2.) Cache most recent search(es) ###

## Overview ##

When working with documents you will often find yourself searching for a term and then absentmindedly closing the search as soon as a hit has been found, only to then realize that it wasn't the hit you were looking for. This is even more important when working with numerous documents and a large number of tabs. Every time you search for a different phrase in another tab the results in the previous document are lost.

In all of these cases you would have to reengage a search and waste precious time and CPU cycles on processing that has been done before. Wouldn't it be neat if the last search was cached?

## Suggestions on implementation ##

It would be great if there was a way to remember the most recent search for each tab. As long as the newly entered term matches the previous one for a specific document, the cache is used - even if the user decides to close the search bar or the term is replaced by switching the tabs around and searching for other phrases

### 3.) Change search result highlighting mode ###

## Overview ##

I think qpdfview's result highlighting method feels a bit unnatural. Matches are currently overlaid with a transparent blueish box that makes the text under it hard to read. It's not dramatic by any means but I think a highlighting by "shading" the text background would be both more readable and easier to locate on a page.

## Suggestions on implementation ##

I know you aren't particularly fond of comparisons of qpdfview to other PDF viewers but I think it's not bad practice to take good implementations in other pieces of open-source software as an example. That's why I've attached a comparison of the highlighting methods in qpdfview and Okular. I think the screenshot showcases that the "shading" method is a bit easier to read and overall more pleasant.

Thank you very much for taking the time to read this bug report.

Cheers
-- Ari

[Adam Reichold (adamreichold)]

Hello Ari,

Again before reviewing all of this, the best place to discuss ideas for the development is the mailing list at "https://launchpad.net/~qpdfview".

Regards, Adam.

[Adam Reichold (adamreichold)]

Hello again,

I changed the composition mode used for highlights to 'multiply' which should achieve a shading effect (trunk revision 1112). (The color is taken from the theme's default palette for highlights.)

Regards, Adam.

[Adam Reichold (adamreichold)]

Hello again,

Concerning the pause button, I don't think is a good use of time and code (as qpdfview tries to keep small). Especially one can just let the search run through while beginning to review the result. (Also, with the threading improvements in Poppler 0.24, searching won't interrupt rendering any more.)

Concerning caching, I don't think the results are lost on switching tabs any more. You can switch tabs, search for something else, switch back and continue to review the results of your last search using find next/previous. Its only the contents of the search field that will not match the displayed highlights.

Regards, Adam.

[Ari (ari-lp)]

> Concerning the pause button, I don't think is a good use of time and code (as qpdfview tries to keep small). Especially one can just let the search run through while beginning to review the result. (Also, with the threading improvements in Poppler 0.24, searching won't interrupt rendering any more.)

I see your point. There has to be a balance between features and size and this feature would disrupt it. Given how quick searches are with qpdfview this would have only been a small enhancement, anyway. I am glad to hear of the improvements in poppler.

> I changed the composition mode used for highlights to 'multiply' which should achieve a shading effect (trunk revision 1112). (The color is taken from the theme's default palette for highlights.)

Thanks again for implementing this right away. I just tried out rev. 1116 and I can't seem to get the highlighting to work. The search results are invisible for me right now. I tried starting qpdfview with different themes enabled (Ambiance, Radiance, custom ones) but to no avail. Is the color it's supposed to use the same one as the thumbnail highlighting uses? Because that one works, strangely enough.

Cheers
-- Ari

[Adam Reichold (adamreichold)]

I am sorry, auto-complete lead to typo replacing "highlight" by "highlightedText" in QPalette (highlighted text is usually drawn white on blue, hence it seems invisible). This should be fixed in 1118 as well.

[Adam Reichold (adamreichold)]

Since there there was no more feedback on this, I assume the typo was the problem and is is fixed. Also I repurpose the bug report to track the improvement to highlighting only.

[Ari (ari-lp)]

Hi Adam,

the result highlighting works absolutely fine now. Thanks again for the quick fix. As for the change itself I think that it's a major improvement over the previous highlighting method. Still there are three points I would like to discuss that might enhance the current method even further:

1.) The highlighting color changes when window focus is lost. I don't know if this is intentional or not but I would argue that it makes the results harder to identify. One use case where this would be a problem is when working with qpdfview and a document editor side by side. This point also applies to other UI elements such as the search progress indicator and thumbnail highlighter.

2.) Depending on the zoom level characters are sometimes ever so slightly protruding over the highlighting box, which appears to be a bit off center in general. I know that this is nitpicking but I figured I should mention it in case it is easy to fix. If not, please just disregard this point. I attached a screenshot showcasing what I mean.

3.) This point pertains more to the future of qpdfview than its current state. From the bug overview I can see that you have triaged bug #958634 (enhancements for text selection) so I think it is safe to say that at some point in the future there will be text selection by line. This is why I wonder how result highlighting and text highlighting colors will be handled when this feature eventually comes. As it stands, qpdfview's new highlighting method uses the system highlighting color, which would conflict with a potential new text selection tool. I think this might be a good reason to rethink how the result highlighting color is defined.

4.) As a follow-up to point 3.) I would like to add that the current method of defining the result color based on the system highlighting color can make the results quite hard to read depending on the theme. This is to be expected when a background color that is usually rendered behind white text now serves to highlight black text. I think there are two ways of handling this:

  a.) Render highlighted text in XOR mode (white text on colored background), this might lead to problems with 3.)
  b.) Offer a configuration option to change the result highlighting color. Set the default color of the color selection option to a slightly modified version of the system highlighting color (e.g. increased brightness) to avert confusion around 3.)

All of these points are a bit pedantic, so please just set them aside for now if you have more important things to attend to.

#####

I just realized that I completely forgot to address your response on caching.

What you wrote was:

> Concerning caching, I don't think the results are lost on switching tabs any more. You can switch tabs, search for something else, switch back and continue to review the results of your last search using find next/previous. Its only the contents of the search field that will not match the displayed highlights.

You're right, I wasn't aware of that. I guess I always changed the search terms back before searching through the tab and thus triggered a new search. I think the point still stands, though. Searches in larger documents ...

[Adam Reichold (adamreichold)]

Hello again,

ad 1: This is defined by the current theme's palette and hence is the intention of the theme's designer. The idea probably is to be less distracted by programs that do not currently have the focus. qpdfview just respects the themes palette.

ad 2: The highlighted areas are generated by the back-end library, i.e. Poppler, so the only thing that can be done inside qpdfview is to maybe increase the rectangles in all directions by a few units which might make them more inaccurate in other cases. So no, it is not really easy to change or at least the effects of the easy change are not very clear.

ad 3 and 4: As you pointed out yourself, this concerns future development and should hence be discussed on the mailing list. You to clarify point 4a, the text and its background is drawn by the back-end, the highlight is then drawn on top of that, meaning that the method of drawing text cannot be selectively changed. A setting for the highlight color might be useful, but will increase the number of settings even more which is probably not so useful. (But I would rather not apply that setting to the progress or thumbnail indicators, only to the document view as the theme's behavior is definitely intended for those.)

Concerning caching: IMHO light weight means to use as few resources as possible even if it means that some operations will take longer to process. Also caching is always problematic as the cache's size and eviction behavior have to be tuned, necessarily by heuristics as the future resource usage is unknown. So caching search results is a 'won't fix' from my part.

Regards, Adam.

[Adam Reichold (adamreichold)]

Concerning the user-settable highlight color, have a look at trunk revision 1128, on the "behavior" tab of the settings dialog...

[Adam Reichold (adamreichold)]

(As a side remark concerning the speed of searching PDF documents: Which Poppler version do you use (or more specifically against which Poppler version is your version of qpdfview built), since search speed did improve greatly with Poppler 0.22.)

[Ari (ari-lp)]

Adam, I think I have expressed this before but I am absolutely flabbergasted each time at how quickly you respond to user requests and - if apt -implement them. I love the new color selection setting you've added. I see that you've also made the highlighting color independent from the theme settings while leaving the other UI elements be. Fantastic! The new rectangular indicator that marks the current result is also a great addition.

Thank you very much for bearing with me and my nitpicking.

There's only one small issue I found with the new revision: Sometimes the indicator status will not refresh when moving to the next item in the result list. I have attached a screenshot that shows this. Changing the zoom level immediately gets rid of the extra rectangles.

###

As for caching, I can see how the actual implementation would not go along with qpdfview's light weighted nature as much I thought it would. I absolutely understand your decision on not implementing this.

I am very eager to try out poppler's new release as I am still running the stock poppler-utils that came with 12.04 LTS. It will be a while before I will upgrade my system and get to try them out but I am definitely looking forward to it.

Cheers
--Ari

[Adam Reichold (adamreichold)]

Hello again,

I am not sure what exactly causes to the current highlight not to update correctly as I did never encounter the problem. I have however tried to force the viewport to be updated in trunk revision 1133 (which solved some earlier rendering artifacts like these). Please tried that and if the problem persists, any narrowing down of the circumstances under which it occurs would be helpful. Thanks.

Regards, Adam.

[Ari (ari-lp)]

Hi Adam,

that seems to have fixed it. I tested different documents, search terms and zoom modes and wasn't able to reproduce the bug. Again, fantastic work!

Cheers
--Ari