STR #1625

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.1 ]

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:


Name/Time/Date Filename/Size top right image
 
#1 kontakt.andreas-schoemann
10:40 Mar 05, 2007
preferences.png
8k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#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.
 
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.