STR #1625: menu items text color has changed yielding poor contrast

STR #1625

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	menu items text color has changed yielding poor contrast
Version:	1.1-current
Created By:	kontakt.andreas-schoemann
Assigned To:	matt
Fix Version:	1.1-current (SVN: v5748)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	kontakt.andreas-schoemann 10:40 Mar 05, 2007

preferences.png
8k

Trouble Report Comments:

#1	kontakt.andreas-schoemann 10:40 Mar 05, 2007

The text color of selected menu items has changed from white to black. In combination with selection color blue it is difficult to read the text. Fltk: v1.1.x-r5724 OS: Windows XP Compiler: gcc/mingw

#2	AlbrechtS 07:00 Mar 06, 2007

Yes, I found this, too, but didn't have the time to file an STR yet. That's what I found out: There has been an STR (#837) and a fix in r4339: ------------------------------------------------------------------------ r4339 | mike | 2005-05-12 19:08:35 +0200 (Do, 12 Mai 2005) | 4 lines fl_contrast() now compares the luminosity of each color (STR #837) ------------------------------------------------------------------------ However, this fix has been changed again in r5489: ------------------------------------------------------------------------ r5489 | mike | 2006-09-25 18:36:52 +0200 (Mo, 25 Sep 2006) | 8 lines [...] src/fl_color.cxx: - fl_contrast(): Require at least 1/3 (85) instead of 1/2 (127) for contrast against the background. ------------------------------------------------------------------------ IMHO, this last change should be rolled back (and in fact, the code shows 90 instead of 85). I experimented some time and added a #define LTH (luminosity threshold) to modify the check and added some printf statements (see below). You can test it with every FLTK Fl_Input widget by selecting text. It seems to me that the first two statmenst after "// Compare ..." mean that we do accept a lower contrast than we would get if we changed the color to FL_BLACK or FL_WHITE, because we _prefer_ the actual foreground color (fg). I'm not a color/luminosity/contrast expert, but as it looks, the value 90 seems too low to me. The normal Windows XP selection color has a contrast value of 95, as the OP's display seems to show. Conclusion: I think that the comparison threshold (LTH) should be raised _at_least_ to 127 again, which would mean: if the fg and bg colors already have a contrast that is higher than the minimum contrast that we would have to accept in the worst case (127), then we use the original fg color; otherwise we must use black or white. BTW: wikipedia shows a slightly different luminosity formula in [1]: Luma (Y’) = 0.299 R’ + 0.587 G’ + 0.114 B’ [1] http://en.wikipedia.org/wiki/Luminosity#In_photometry_and_color_imaging Maybe, this one is better? Regards Albrecht P.S. source code from src/fl_color.cxx: // Compute the luminosity... l1 = ((c1 >> 24) * 31 + ((c1 >> 16) & 255) * 61 + ((c1 >> 8) & 255) * 8) / 100; l2 = ((c2 >> 24) * 31 + ((c2 >> 16) & 255) * 61 + ((c2 >> 8) & 255) * 8) / 100; #define LTH (127) /* threshold, FLTK: 90 */ //* printf ("L1=%d, L2=%d, L2-L1=%d\n",l1,l2,l1-l2); //* fflush (stdout); // Compare and return the contrasting color... if ((l1 - l2) > LTH) return fg; else if ((l2 - l1) > LTH) return fg; else if (l2 > 127) return FL_BLACK; else return FL_WHITE; } // // End of "$Id: fl_color.cxx 5638 2007-01-24 12:03:36Z matt $". //

#3	matt 12:21 Mar 06, 2007

Yes, I changed the value from 81 to 90 for exactly that reason. On my WIndowsXP Teletubbies-Background original settings, 81 gave me black text on dark blue, just as described. Setting the contrast to 90 gave me white text, but I see how this can still be not enough. 127 seems a bit to high though, because we *are* overriding the developers wisches for a certain color here. This annoys the heck out of me when Fluid overrides my colors for the graphical labels!

#4	AlbrechtS 13:06 Mar 06, 2007

Okay, let's have another look at the problem. My users' problem was that they had black text with a dark blue background in Fl_Input-derived text inputs. I looked into fltk's src dir. and saw: $ grep fl_contrast Fl_In*.c* Fl_Input_.cxx: fl_color(fl_contrast(textcolor(), selection_color())); which obviously is the problematic part here (selecting text). Most of the time, the text _is_ black, and I would expect it to be inverted (white) when the text is being marked as selected. And there are similar cases in other source files. So, what about thinking about a different approach here, e.g. fl_color(fl_contrast(fl_invert(textcolor()), selection_color())); with fl_invert() having to be defined. But, whatever the text selection functions would do, IMHO it is obvious that the contrast in the given example is not "sufficient". From the docs: fl_contrast() ... "Returns the foreground color if it contrasts sufficiently with the background color. Otherwise, returns FL_WHITE or FL_BLACK depending on which color provides the best contrast." So, it's a matter of definition, what would be sufficient.

#5	kontakt.andreas-schoemann 07:56 Mar 07, 2007

Readability of displayed information is most important and the default settings should guarantee proper readability. The current state unfortunately does not do this, neither on Windows nor OS X. Another problem related to this one: I tried to change FL_SELECTION_COLOR to FL_BLUE in Enumerations.H in order to possibly improve the situation but that breaks the build: fluid doesn't compile any more.

#6	matt 02:55 Mar 20, 2007

Fixed in Subversion repository. I increased the minimal required contrast to 96. I also increased the weight of the blue component in the luminosity calculations. I will have a test run on MS Windows now, but I believe that this should give better results in all cases.