Description: Applying certain highlighting changes the font color to white Steps to Reproduce: 1. Open the attached file (using LibreOffice light theme) Actual Results: Font appears to be white. It's actually black. It depends on the highlighting color if the font being black or white Expected Results: Black font Reproducible: Always User Profile Reset: No Additional Info: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Created attachment 204472 [details] Sample
Also in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7afd11f8e476884662c18db85445752cc030b2e2 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
and in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1ea27b7e35faf6619112bf3f1d69e4ec41c0bf23 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded fine with Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: 35f19e5cb93ce218787904e99c2bedfd40e725cc CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
I tested it on both Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1c629ca0048670db4bed5e7d8d76bcf8e81f2158 CPU threads: 32; OS: Windows 10.0 Build 26100; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded and Version: 7.6.8.0.0+ (X86_64) / LibreOffice Community Build ID: 3a0801282a0aabc64a15f9afc3aedeac6226a979 CPU threads: 32; OS: Windows 10.0 Build 26100; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded and i still encountered the problem
Hi Telesto, In the live version, I can open attachment 204472 [details] and see the White text in the "Brick" highlight. I was also able to confirm that when the highlight is removed, the text is, in fact, Black, not white. However, I was not able to trigger the issue with new text in this version. In the Alpha version, I was able to reproduce the issue by creating a new file, adding text, selecting the text and then placing a "Brick" highlight. I also ran a Bibisect that pointed to the commit listed below commit 75d131082ce51ed5a898d97bdc2b7a9fe5ddb340 Version: 25.8.3.2 (X86_64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to rram from comment #5) > I also ran a Bibisect that pointed to the commit listed below > commit 75d131082ce51ed5a898d97bdc2b7a9fe5ddb340 Which bibisect repo is this from? I can't find such a source hash, so it seems you are pointing to a binary hash. In comments we should always share the source hash instead.
As I suspected, this is an intentional tweak to the calculation of when to darken/lighten Automatic font colour based on its background (contrary to comment 0, the font is not "actually black", but Automatic). Done in 24.2 in commit ddb483509113e469b771320fea52f1b089574021
(In reply to Buovjaga from comment #7) > As I suspected, this is an intentional tweak to the calculation of when to > darken/lighten Automatic font colour based on its background (contrary to > comment 0, the font is not "actually black", but Automatic). Done in 24.2 in > commit ddb483509113e469b771320fea52f1b089574021 It already felt a bit like by design. Didn't think of the default Automatic setting... I really associate it with black Their are some issues in my opinion though a) bug 156182 is about Calc, is the intended to apply this to Writer too? b) old documents are rendered different now (backwards compatibility) c) inconsistency - unpredictability - certain highlighting trigger this other don't d) automatic is also of relevance for styles, I guess. So if I start correcting the problem by changing font color to black, I'm going into DF mode.
(In reply to Telesto from comment #8) > (In reply to Buovjaga from comment #7) > > As I suspected, this is an intentional tweak to the calculation of when to > > darken/lighten Automatic font colour based on its background (contrary to > > comment 0, the font is not "actually black", but Automatic). Done in 24.2 in > > commit ddb483509113e469b771320fea52f1b089574021 > > It already felt a bit like by design. Didn't think of the default Automatic > setting... I really associate it with black > > Their are some issues in my opinion though > a) bug 156182 is about Calc, is the intended to apply this to Writer too? > b) old documents are rendered different now (backwards compatibility) > c) inconsistency - unpredictability - certain highlighting trigger this > other don't > d) automatic is also of relevance for styles, I guess. So if I start > correcting the problem by changing font color to black, I'm going into DF > mode. Why would you go into direct formatting mode, if you change it within the style?
Some interesting discussion in bug 161766. The calculation of luminance and what humans perceive as light/dark threshold is a quite academic topic. Your example works pretty well for me but there are for sure colors that do not work well. => NAB