Steps to reproduce: 1. Open attachment 91446 [details] from bug 73247 -> Text is white. It should be black instead Reproduced in Version: 24.2.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 0034d2ab9382da86340738137218791a4ccc9c90 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: fr-FR (es_ES.UTF-8); UI: en-US Calc: threaded [Bug found by office-interoperability-tools]
Regression introduced by: author Heiko Tietze <heiko.tietze@documentfoundation.org> 2023-07-12 12:52:39 +0200 committer Heiko Tietze <heiko.tietze@documentfoundation.org> 2023-07-15 08:33:55 +0200 commit ddb483509113e469b771320fea52f1b089574021 (patch) tree fea1e840da8295bde9eeb7d1b58817a41cbad08e parent 693411e60c6bbd1c2ef25490cc3902f6b2461682 (diff) Resolves tdf#156182 - Automatic text color unreadable with darker cells
It's an intentional consequence of the new contrast calculation. The first color in the gradient #956748 vs. #FFFFFF is 4.87:1 while vs. #000000 it was 4.31:1. => NAB
Created attachment 191724 [details] Comparsion LibreOffice 24.8 master vs MSO
(In reply to Heiko Tietze from comment #2) > It's an intentional consequence of the new contrast calculation. The first > color in the gradient #956748 vs. #FFFFFF is 4.87:1 while vs. #000000 it was > 4.31:1. => NAB then the intentional consequence is wrong. The text in MSO is black and the same should be in LibreOffice since it's a DOCX file
We likely do not use the same calculation in case of automatic colors. But I wonder how things work for solid colors (the automatic apparently takes just the first color into account).
Same issue with attachment 98729 [details] from bug 78469
Created attachment 191753 [details] Test document But previously we used black font on the default Tango Sky Blue background which is now calculated as white, the same on MSO.
Without any formal spec/definition of when to consider a color light or dark, I don't see a way to say for sure what's the "correct" behavior, since that's basically undefined. Some questions to which I don't have an answer: Should LO always do the same as MSO? (And does MSO even do the same across different versions?) Or just when using OOXML docs? (I'd personally tend to be in favor of consistency across file formats.) Or should LO use an algorithm that tries to ensure a proper contrast ratio, as Heiko's commit does? tdf#61993 looks related and has some notes on what formula MSO might be using.
(In reply to Luke Deller from bug 61993 comment 3) > Word 2010 appears to treat a background colour as "dark" if: > 130*red + 255*green * 51*blue < 105*255 My first patch used the w3 algorithm from https://www.w3.org/TR/AERT/#color-contrast return sal_uInt8((R * 299UL + G * 587UL + B * 114UL) / 1000); with IsDark() GetRelativeLuminance() <= 128; and IsBright() GetRelativeLuminance() >= 200; Don't remember why I rejected this solution, maybe because of this reply: (In reply to Myndex from comment #6) > Case 5 is an obsolete and incorrect WCAG 1.0 attempt at something... The alleged MSO function makes no difference to what we had in the past. But if I use a black cell background in Excel 365 the automatic font color is still black. Don't want to fix their problems, though. By the way, the default color Tango Sky Blue / 0x729fcf is calculated extra with the legacy calculation.