Created attachment 194931 [details]
Sample file to test

Created attachment 194932 [details]
Screenshot from version 24.2

Created attachment 194933 [details]
Screenshot from version 7.6

Could be a duplicate?
https://bugs.documentfoundation.org/show_bug.cgi?id=157618

Black would be better readable.

There exist calculation rules in https://www.w3.org/TR/WCAG21. Perhaps it should be considered to use that rules to determine the threshold for switching between white and black text color?

(In reply to m_a_riosv from comment #4)
> Could be a duplicate?
> https://bugs.documentfoundation.org/show_bug.cgi?id=157618

I don't think so. The switch between white and black text color works in principle in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: aaf2967d74a9a7ba2d28433e1872422ce38b6244
CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: default; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: default
However, the threshold value for the switch could be set better for greenish colors.

Let's CC Heiko, since he is responsible of the changed threshold (not so long ago, IIRC).

The calculation (actually only the threshold) was changed for bug 156182. Tinkering with this breaks existing documents and affects compatibility. But it might be necessary.

Related Q&A in Portuguese:
https://ask.libreoffice.org/t/fonte-mudando-de-cor-ao-mudar-a-cor-do-fundo-da-celula/107080
Setting the background color to #11FF11 is a workaround.

I get the impression here that the issue is not with the threshold, but some other issue in how an automatic text color is chosen?

I do recall from #156182 that only the threshold was changed, as a compromise solution. It was a compromise as still the incorrect coefficients (and lack of linearization) were being used to calculate lightness. As I understand it, the calculation is still:

aLum = (Red(aColor) * 76 + Green(aColor) * 151 + Blue(aColor) * 29) / 256

Which is incorrect but has the advantage of some computational simplicity. The coefficients 76,151,29 relate to the obsolete NTSC system, which has been dead for about two decades. These are still used for some "standard def" video for legacy reasons, but don't relate to modern displays.

The incorrectness here is most visible in saturated green. An immediate improvement can be had by swapping out the coefficients with those more related to modern sRGB displays:

aLum = (Red(aColor) * 56 + Green(aColor) * 182 + Blue(aColor) * 18) / 256

Threshold = 154



And if saving cycles is important, this can be simplified to remove the division:


aLum = (Red(aColor) * 2 + Green(aColor) * 7 + Blue(aColor))

Threshold = 1540


MORE ACCURATE METHODS AVAILABLE

We've done a lot of research here and it's not necessary to re-invent anything, but real improvements make it necessary to incorporate more correct color science into this project. If you want a finer and more accurate way to set text either black or white, we have a "most simple but correct" version of a text color flipper at the MaxContrast repo:

https://github.com/Myndex/max-contrast

This addresses lightness contrast only, and does not address the font weight (which is  also important, but hey, baby steps...)

A key factor missing in the LibreOffice calculation is that gamma encoded colors need to be linearized before applying the coefficients. If linearization is not performed, then you'll experiences the kinds of errors noted in this bug.


-----

@Regina: the calculation rules listed in WCAG 2.x are incorrect, and fail badly for dark color pairs. WCAG 2.x contrast math should not be used, and the results from WCAG 2.x math have been shown to be harmful to readability for those with color vision deficiencies.



-----


SUMMARY OF THE COLOR SCIENCE

#00ff00 should calculate so that it is paired with black. In fact, from about #0b0 up to #0f0 should pair with black. Darker than #0b0 can pair with white.

All red-only #n00 or blue-only #00n should pair with white.

Reason: the majority of luminance (lightness) is "green" and comes from the green primary on a display. Blue makes up 7% at most, and red about 22%.

Luminance/lightness contrast is what is needed to view text. Contrast middle is about #a2a2a2, though there are a number of factors at play, and the actual perceptual middle can vary between about #999 and #b0b0b0.

#a2a2a2 is a reasonable flip point. For saturated colors, the equivalent luminance is 0.36 Y, and this requires that the appropriate coefficients are used to weight the R,G, and B primaries.

This was discussed in the original bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=156182


----

The JS code from the Max Contrast repo https://github.com/Myndex/max-contrast.
Send it RGB ints, it returns a string (or however you want to define black/white)


function maxContrast (sR = 0xa4, sG = 0xa4, sB = 0xa4) {
  
  const trc = 2.4, sRco = 0.2126729, sGco = 0.7151522, sBco = 0.0721750; 
  const flipY = 0.342; // based on APCA™ 0.98G-4g middle BG color

  let screenY = (sR/255.0)**trc*sRco + (sG/255.0)**trc*sGco + (sB/255.0)**trc*sBco; 

  return screenY < flipY ? 'white' : 'black'
}

Alternately, of course:

   return screenY < flipY ? 1 : 0  // return 1 for white 0 for black
or
   return screenY < flipY ? 0xffffffff : 0xff000000    // return ARGB hex value


And the ** is the JS exponent operator, so for other languages:

  screenY = pow((sR/255.0),trc) * sRco + (pow((sG/255.0),trc) * sGco + pow((sB/255.0),trc) * sBco; 



The MaxContrast function is the simplest but accurate, color-only model. Further accuracy can be had by also incorporating spatial contexts (such as font weight) and surrounding contexts, but that is a much bigger fish to fry.


Thank you for reading,

Andy


Andrew Somers
Director of Research
Inclusive Reading Technologies, Inc.

https://readtech.org/ARC/

While I understand the rationale for this change in behavior with version 24, could we please have an option to disable it?  I don't want white text, ever.  If the cell text spills over into an adjacent cell which has not been formatted, that text is no longer visible (white on white).  And frankly, the white looks pretty terrible/unreadable most of the time when it is triggered automatically, even in the highlighted cells.

This change has visually broken many of my documents now that I recently updated.  Obviously I can solve it by changing all of the text in all the documents to "black" instead of "automatic", except that some of those documents do have specific font color changes and so it becomes a real headache to have to manually recreate all those specific changes after a blanket change to stop this annoying behavior.

(In reply to Myndex from comment #9)
> We've done a lot of research here and it's not necessary to re-invent
> anything, but real improvements make it necessary to incorporate more
> correct color science into this project. If you want a finer and more
> accurate way to set text either black or white, we have a "most simple but
> correct" version of a text color flipper at the MaxContrast repo:
> 
> https://github.com/Myndex/max-contrast

Note, that we can't use the (derivatives of) max-contrast in our project, because it's GPLv3.

Looked into the topic. While changing the calculation is simple, and adding an option to return to the legacy calculation would be possible too, it has a lot of impacts: RGB(128,128,128) previously being at the exact mid luminance now clear below, disabled objects become colored slightly different, SVG export of semi-transparent shapes is different, etc.

We test as many functions as possible to ensure the application to be stable. Don't know how many of those unit tests need to be modified, or where it rather makes sense to adjust the processing.

(In reply to bchemnet from comment #10)
> While I understand the rationale for this change in behavior with version
> 24, could we please have an option to disable it?  I don't want white text,
> ever.

You had always had this option. Use explicit colors, not auto. The automatic color of text is, *by definition*, the color that is black on light backgrounds, and white on dark. No option is needed to change that. Users who don't need automatic behavior must not use automatic colors.

(In reply to Heiko Tietze from comment #12)

We may change unit tests, it the change is reasonable (it really seems so). Also, we need to add more unit tests to check the legacy mode.

Of course, such a change is a big one, and is not just a bugfix (so it's for release notes of a new version).

(In reply to Mike Kaganski from comment #14)

Note also, that this change needs a compatibility option in documents, not a setting in user preferences. Old documents must retain their look. New documents need to use the new algorithm. This BTW allows to keep old unit tests pass without modifications.

*** Bug 162269 has been marked as a duplicate of this bug. ***

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/74d910231c5591f5e497fc52f2a0132c8f41a271

Resolves tdf#161766 - WCAG 2.1 compliant luminance for isDark()

It will be available in 25.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.