Since Macintosh System 6.5 days (showing my age!) I've set my text highlight color to a bright purple. This color's rare use in documents, my general liking for purple, and my long use of it for this purpose all conspire to quickly draw my eyes to highlighted text. I'm sure other users have their own equally valid preferences for text highlight color. KDE accommodates all of us by allowing each of us to set: System Settings: Appearance: Colors: Edit Scheme: Colors: Common Colors: Selection Background just how we like it. Most applications pick up this system setting and things Just Work(TM) as each of us wants. It appears that Okular does pick up and use the system-wide "Selection Background" color for its "Selection" tool. But then it seems to use a hard-coded bright yellow to highlight the background of text found via ctrl-f. At least, I've been unable to find a way to change this color to anything but the default bright yellow. Although this bright yellow often works acceptably to highlight found text, not being able to change it causes these problems: Problem 1) Using bright yellow to highlight found text conflicts with using the same bright yellow by default for Reviews: Pop-up Note, Inline Note, and Highlighter. This can make it difficult or impossible to locate highlighted found text in a heavily marked-up document. Several bugs have been opened over the years regarding this problem: Bug 355043 - Cannot differentiate between review and search highlights Bug 244049 - Search/find highlighting color should be different from annotation highlighting color Bug 237014 - Find tool when text has been highlighted Bug 273968 - Usability: change highlight color for text search and/or annotation Bug 330158 - Default colour of search highlighting is almost the same as annotation colour. Bug 317824 - Highlight color of search term is overlapping with annotation Bug 311034 - default search result and highlight colours are the same - usability problem Partial solution 1a) Newer Okular allows each of these Reviews colors to be changed, and that is much appreciated. But that alone does not completely solve this problem, because bright yellow is such a traditional color (and thus excellent default choice) for highlighting and sticky notes. A far better solution in my opinion is to keep using bright yellow for these Reviews purposes, and to change the found text background highlight color. Partial solution 1b) As noted in Bug 375735 - Option to change default highlight search color there's a patch on the way to draw a black outline around found text to help highlight it. While helpful, I'd argue that this is also an incomplete solution to this problem. A bright color is far more effective than a black outline at drawing my eyes to highlighted found text. Especially when working with documents like forms that already contain many black-outlined boxes. Problem 2) Hard-coding the found text highlight color is contrary to what users expect. Especially since KDE allows us to customize so many colors and themes to our liking, it's natural to assume that there's a KDE setting *somewhere* that will allow changing Okular's found text highlight color. So we spend time searching for the right setting to change, becoming increasingly frustrated when we can't find it. And eventually filing bugs like this one and the others linked. Proposed solution) I respectfully suggest that a future version of Okular highlight found text using the background color from System Settings: Appearance: Colors: Edit Scheme: Colors: Common Colors: Selection Background or another system-wide setting if that one is deemed more appropriate. Sincerely, Frank
No, that solution doesn't work, because people that use dark themes (where selection is usually a white-ish color) would not see the selection when reading PDFs (that usually have a white background).
@Albert Astals Cid: You're right, I didn't think of that as I don't personally use dark themes. Hmm... how about using system Selection Background color for the found text highlight, and its inverse color to draw a box around this highlight. And an option to invert these colors in case that works better with the theme in use? Perhaps someone who uses dark themes can chime in... Thanks, Frank
Let's get the border around and then we can discuss if adding options to tweak it makes sense
True, I was going to send a patch for that. Adding the border is now simply diff --git a/ui/pagepainter.cpp b/ui/pagepainter.cpp index 047220f95..94429af93 100644 --- a/ui/pagepainter.cpp +++ b/ui/pagepainter.cpp @@ -385,6 +385,8 @@ void PagePainter::paintCroppedPageOnPainter( QPainter * destPainter, const Okula QPainter painter(&backImage); painter.setCompositionMode(QPainter::CompositionMode_Multiply); painter.fillRect(highlightRect, highlightColor); + painter.setPen(Qt::black); + painter.drawRect(highlightRect); } } // 4B.4. paint annotations [COMPOSITED ONES] I am not convinced that hard-wiring Qt::black is a good idea. What is a good color?
@Oliver Sander: Cool patch! I agree, color selection is now seeming more complicated than it first appeared. I began wondering about a dotted- or dashed-line border with, say, alternating dark and light pixels. But that seems unnecessarily complex to implement. What about using *2* rectangles, one just slightly bigger than the other, one in a dark and the other in a light color? Or even *4* rectangles in alternating dark and light colors? It seems THAT would be pretty easy to see as (at minimum) a double-box no matter what the theme and document colors in use...
(In reply to Oliver Sander from comment #4) > True, I was going to send a patch for that. Adding the border is now simply > > diff --git a/ui/pagepainter.cpp b/ui/pagepainter.cpp > index 047220f95..94429af93 100644 > --- a/ui/pagepainter.cpp > +++ b/ui/pagepainter.cpp > @@ -385,6 +385,8 @@ void PagePainter::paintCroppedPageOnPainter( QPainter * > destPainter, const Okula > QPainter painter(&backImage); > > painter.setCompositionMode(QPainter::CompositionMode_Multiply); > painter.fillRect(highlightRect, highlightColor); > + painter.setPen(Qt::black); > + painter.drawRect(highlightRect); > } > } > // 4B.4. paint annotations [COMPOSITED ONES] > > I am not convinced that hard-wiring Qt::black is a good idea. What is a > good color? Maybe try KColorUtils::darken ? https://api.kde.org/frameworks/kguiaddons/html/namespaceKColorUtils.html#a11e97bbb394b7e619163c2cc6b9a513a
No need for KColorUtils, QColor has 'darken' natively. Feel free to play with the parameter. Patch is at https://git.reviewboard.kde.org/r/130238/
Reviewboard is going away soon. Can you upload your to our Phabricator instance? https://phabricator.kde.org
https://phabricator.kde.org/D7662
Thanks! I've slightly edited the summary to include "BUG: 384267" which will automatically close this bug report once the patch is committed.
I don't think that's going to work, i'm 92.46% sure that BUG: needs to be at the beginning of the line at alone, not in a sentence like you wrote it.
Ah, thanks Albert. Changed.
I just want to echo this report as it affects my usage too. In order to improve my ability to sleep, I use redshift to reduce the colour temperature of my screen and tinted glasses to filter out blue light. The yellow highlight colour will easily get lost once I've gone below a certain temperature threshold and so, the ability to change the highlight colour for the search and find function would be greatly beneficial to users like myself.
(In reply to Albert Astals Cid from comment #1) > No, that solution doesn't work, because people that use dark themes (where > selection is usually a white-ish color) would not see the selection when > reading PDFs (that usually have a white background). (In reply to Frank Myhr from comment #2) > Perhaps someone who uses dark themes can chime in... I use dark themes. All themes available in System Settings use blue or light blue for Selection Background, but I always change it to brown or purple, so it does not glare and the white text is still easily readable. (In many places, the Selection Background is used permanently, so it has potential to glare.) No my problem with Okular is different to yours. Text selection (using Text Selection mode) makes text invisible, because PDFs use black text. I need to change the Selection Background color locally in Okular, while I am relatively ok with yellow for Ctrl+F searching. Does this need another bug report? Although there is no color sheme entry for Search Highlight Background, I suggest adding these options: Configure -> General -> Appearance: [_] Use custom background color [KColorButton] (already there) [x] Use custom text selection color [KColorButton] [_] Use custom search highlight color [KColorButton] I already suggested to add another KColorButton to the Ctrl+F search bar, right?
(In reply to David Hurka from comment #14) > No my problem with Okular is different to yours. Text selection (using Text > Selection mode) makes text invisible, because PDFs use black text. I need to > change the Selection Background color locally in Okular, while I am > relatively ok with yellow for Ctrl+F searching. Does this need another bug > report? Since this is about "search color" and your issues not with "search color", yes i would suggest you open a new bug.
I am also affected by this problem. Yellow is a very effective highlight color, which makes search results unnoticeable. I would like to suggest that application contains 2 settings: 1: whether to use system default 2: if not then which color (color chooser). This should be relatively simple to implement.
I also have issues with this. I run with KDE Night Mode enabled (i.e., the screen is significantly shifted towards yellow/orange). This causes yellow highlights to become essentially invisible (or very hard to to see) on the page. Also I regularly search PDFs with lots of small text and it can be hard (even without Night Mode on) to easily find bright-yellow on the page. More contrast to improve visibility is needed with Ctrl-F highlighting. ASIDE: Yellow is a great highlight colour when NOT using Night Mode, colour inversion, large text, and/or reviewing using yellow --otherwise it is the worst (as implemented in okular since Night Mode renders it essentially invisible, inversion makes it unseen-black and viewing using yellow essentially makes it unseen if the two overlap). Choosing any of the Accessibility settings does not work since none of these changes the highlight to something noticeable/contrasting. In most situations those settings the Ctrl-F hard-coded yellow background becomes invisible (i.e., essentially black if inverting colours) and although the letters highlighted are a slightly brighter/bolder yellow but such is not easy to see with Night Mode off (and essentially impossible to see with it on). I would like to ask that the Ctrl-F highlight be configurable as follows: * Status quo: Default to what currently happens. * Allow the user under Accessibility to choose a some sort of "High contrast invert" for Ctrl-F matches. The high contrast invert would completely invert what is underneath the Ctrl-F highlight box. Sure if the area underneath is 50% gray the inversion would be ~50% gray, i.e., useless, but Ctrl-F matches text and virtually all PDF pages have significant contrast between text and what is underneath the text so that a colour inversion should be very visible. Most documents though, the inversion would make Ctrl-F finds white letter with a black background. It would also be ideal to make user-customizable the colour of the border of the box that surrounds the Ctrl-F yellow highlight. The current colour "black" is useless: it blends in to the page's text (i.e., it doesn't draw the user's attention to the found text) and if Accessibility's invert colour (etc.) is chosen it becomes invisible, etc. Currently there are times when the only way I can see where a match is on a page is to turn off Night Mode completely --and even then I have to look carefully because most PDFs I look at have a lot of small text in them --the yellow is too subtle a colour for such to stand out easily.
I missed mentioning I am using Okular v21.08.1 --but all past versions also have these issues.
Please fix this bug. This is an accessibility issue to me (I cannot see much difference from white and yellow for my eye problem)