[Evolution] Text Foreground vs Background in Evolution Calendar

[AtomicCanine <atomiccanine gmail com>]

evolution-list gnome org

-----------------------
3.28.5-0ubuntu0.18.04.1
Linux Mint 19.1 Tessa
Cinnamon 4.0.10
-----------------------

I am perplexed.

When I switched from Mozilla Thunderbird/Lightning to Evolution 
Calendar, I noticed a difference in the way in which the BLACK or WHITE 
text color was selected for a given calendar background color.  There 
are some cases in which Lightning seems to do a better job in enhancing 
contrast.

I had originally thought that I had found the way (thanks to Milan) in 
which Evolution Calendar selects WHITE or BLACK text for a given color 
background (color of specific calendar), and that it was, in some cases, 
returning results with insufficient contrast.  After a lot of digging, I 
evidently do not follow it, though.

If I set a particular calendar's color (right click on the calendar 
name, pick properties, pick color) to, say, #FF0000 (solid red), the 
text is BLACK, which is "okay" (though WHITE text is more readable).  
However, the text for #0000FF (solid blue) is likewise BLACK - and 
effectively unreadable.  In my attempt to follow the code, I thought 
each of the preceding examples would select WHITE text.  (#00FF00, solid 
green, also results in BLACK text which is both good and what I would 
have expected).


The parts of the code (from recently downloaded master) into which I've 
been looking are
    src/e-util/e-misc-utils.c    src/e-util/e-misc-utils.h
and
    src/e-util/e-cell-text.c     src/e-util/e-cell-text.h

specifically in the function
    e_utils_get_text_color_for_background (const GdkRGBA *bg_rgba)

The specific code at which I'm looking is....
------
GdkRGBA
e_utils_get_text_color_for_background (const GdkRGBA *bg_rgba)
{
        GdkRGBA text_rgba = { 0.0, 0.0, 0.0, 1.0 };
        gdouble brightness;

        g_return_val_if_fail (bg_rgba != NULL, text_rgba);

        brightness =
                (0.2109 * 255.0 * bg_rgba->red) +
                (0.5870 * 255.0 * bg_rgba->green) +
                (0.1021 * 255.0 * bg_rgba->blue);

        if (brightness <= 140.0) {
                text_rgba.red = 1.0;
                text_rgba.green = 1.0;
                text_rgba.blue = 1.0;
        } else {
                text_rgba.red = 0.0;
                text_rgba.green = 0.0;
                text_rgba.blue = 0.0;
        }

        text_rgba.alpha = 1.0;

        return text_rgba;
}
------

It appears that the RGB values (bg_rgba) are floating point in the range 
0.0 ... 1.0, thus the inclusion of the '255' in the calculation to make 
them into single byte values.

Taking the solid blue background example mentioned above, we have (using 
1.0 for the value of blue):
brightness = (0.2109 * 255.0 * 0.0) + (0.5870 * 255.0 * 0.0) + (0.1021 * 
255.0 * 1.0)
brightness = 26.0355
most definitely "<= 140.0" and thus should yield white text; however I 
get black text.

Now, in the case of (R, G, B) of (0.6353, 0.6353, 0.6353) [corresponding 
to 162 in the 0-255 range and entered as 0xA2, 0xA2, 0xA2 in the color 
picker], the brightness value is 145.80.  This should produce black 
text, but I get white.


Is there something else happening here I'm missing?


Ed

--
Linux Mint 19.1 Tessa
Cinnamon 4.0.10