Bug 160719 - Automatic text color for table cell bg of RGB=(0,255,0) is White, should be Black
Summary: Automatic text color for table cell bg of RGB=(0,255,0) is White, should be B...
Status: RESOLVED DUPLICATE of bug 158989
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://ask.libreoffice.org/t/when-i-...
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks: Options-Dialog-Colours
  Show dependency treegraph
 
Reported: 2024-04-18 17:14 UTC by Eyal Rozenberg
Modified: 2024-06-01 12:37 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-04-18 17:14:00 UTC
Consider this document: attachment 112798 [details] (it discusses another bug, but that's not important). In that document, we have a table. All table cells' text color is Automatic. Some of these table cells have background color RGB = (0,255,0), i.e. full Green with no Red or Blue.

LibreOffice choose White for the text color in this case. However - White is a poor choice here: Ihas a lot less contrast, with this kind of Green (which, btw, has a brightness value of 100%); Black would have been a much better choice. Not sure what the color choice logic is, but its result in this case is off.
Comment 1 V Stuart Foote 2024-04-18 18:50:45 UTC
Confirm. In Writer, but also copied the table from Writer to Calc. Where for see also bug 156182 at 24.2.0 the luminance/contrast threshold was adjusted.

Yet in Calc the Automatic formatting for text on a 0,255,0 bg cell remains white.

So are we just not testing the luminance contrast threshold in appropriate fashion? Or do the IsDark() / IsLight() GetLuminance() ranges for RGB greens somehow in need a different test?

@Heiko?

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 30c6e51fc9cb0fa864e1755271343d847fcced25
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 2 Eyal Rozenberg 2024-04-18 20:32:14 UTC
(In reply to V Stuart Foote from comment #1)

Thanks. Indeed, the behavior is the same in Calc, and I had forgotten to mention I was using:

Version: 24.2.0.2 (X86_64) / LibreOffice Community
Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f
CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US


I should also say, that the "problem" is not with the Brightness value I mentioned earlier; for Red, i.e. RGB = (255,0,0), the use of White text is fine, and probably even a little better than Black. It's also not about Luminance/Lightness, in the HSL model, since for both Red and Green, the L value is 50%.
Comment 3 Heiko Tietze 2024-04-19 07:45:26 UTC
Obviously an issue with the luminance calculation and/or the used threshold for dark. I suggest to discuss this topic on bug 156182.
Comment 4 Mike Kaganski 2024-06-01 12:19:41 UTC
So, this is a regression after commit ddb483509113e469b771320fea52f1b089574021 (Resolves tdf#156182 - Automatic text color unreadable with darker cells, 2023-07-15). Adding respective keywords.

Any such change, even with a different threshold, will necessary break some existing documents. Maybe that is worth a special compat flag, but at least this fact should be considered.
Comment 5 Mike Kaganski 2024-06-01 12:29:09 UTC
*** Bug 159983 has been marked as a duplicate of this bug. ***
Comment 6 Mike Kaganski 2024-06-01 12:30:19 UTC

*** This bug has been marked as a duplicate of bug 158989 ***