| Summary: | FILEOPEN: Incorrect text color in textbox | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Xisco Faulí <xiscofauli> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | buzea.bogdan, eyalroz1, heiko.tietze, m.weghorn, suokunlong, xiscofauli |
| Priority: | medium | Keywords: | bibisected, bisected, regression |
| Version: | 24.8.0.0 alpha0+ | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=156182 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | Heiko Tietze | |
| Bug Depends on: | |||
| Bug Blocks: | 104449 | ||
| Attachments: |
Comparsion LibreOffice 24.8 master vs MSO
Test document |
||
|
Description
Xisco Faulí
2024-01-02 18:04:30 UTC
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. *** Bug 159983 has been marked as a duplicate of this bug. *** *** Bug 160719 has been marked as a duplicate of this bug. *** To comment 8: When opening MS Office documents, it is *definitely* a valid assumption that we must show the same as MSO. We need a very good reason to deliberately decide to differ. When opening *own* existing files, we may want to consider the fact, that such changes are in fact *breaking* changes, i.e. they break someone's existing document. So one option is a compat flag, even if the changed algorithm will break less existing documents. (In reply to Mike Kaganski from comment #12) > When opening MS Office documents, it is *definitely* a valid assumption that > we must show the same as MSO. We need a very good reason to deliberately > decide to differ. Well, suppose there's a bug in MSO, which causes a calculated color to be black rather than white... But I do agree that, when it's not too much trouble, we should by default aim for "bug-to-bug compatibility" with MSO when opening DOCX files. (In reply to Eyal Rozenberg from comment #13) ... but also note that our current behavior is wrong also in the absolute sense, as pointed out in my dupe bug 160719. |