In the theme colours, changing the font colour doesn't do anything if the background colour is darker than "Light Gray 2". Instead, the font colour is always white. Steps to reproduce: 1 - Choose: Tools > Options 2 - Under the first list "LibreOffice", select the "Application Colors" set 3 - Under General, change "Document background" to black, and "Font color" to red. 5 - Click "Apply" -> Nothing changes 6 - Change "Document background" to "Light Gray 2" (or higher) -> font colour changes. I encountered this issue in LibreOffice 24.2.0.3 under Linux. But I also tested it in 24.2.0.3 and 24.8.0.0 under Windows, and it had the same effect (font colour against dark themed background is always white). Obviously LibreOffice can still be used with this bug, but I find it rather uncomfortable on the eyes given the very high contrast--which leads to making the background colour brighter, which negates the purpose of a dark theme.
I also tried resetting my profile, but it made no difference.
Confirm in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b39c6082aa975ed8e5696c3dc24c3025ed07bbb6 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo Works in Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.4 Calc: threaded
Setting black background and red font doesn't works. Font is white. But for instance setting black background and lime color for font works.
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Heiko Tietze ; Could you possibly take a look at this one? Thanks c360bb4042d85a453b2cf898bf815aafb6afd4ad is the first bad commit commit c360bb4042d85a453b2cf898bf815aafb6afd4ad Author: Jenkins Build User <tdf@pollux.tdf> Date: Sat Jul 15 09:22:37 2023 +0200 source ddb483509113e469b771320fea52f1b089574021 154352: Resolves tdf#156182 - Automatic text color unreadable with darker cells | https://gerrit.libreoffice.org/c/core/+/154352
The default font color is automatic and depend on the background. The mentioned patch changed the calculation when the color is considered to be dark, an improvement for accessibility. You can change the font color in the same dialog or you define it on the paragraph/character style level. Is there any issue beyond the observation that something has changed?
Yes, I understand that the automatic font colour adjusts itself based on the background colour--that is definitely a good thing. But I am referring to non-automatic colours getting changed: if you put the background to a dark colour, then change the theme's font colour to a dark or semi-dark colour (non-automatic), then it just gets switched to white anyway (even if you chose blue or red, etc.). Not only is this strange (given that a non-automatic colour whas chosen), it is also inconsistent with how light colours are handled, as one can set the themed font and background colour both to "Light Gray 2" (or higher) and then the text cannot be seen. This however, makes sense to me as the user specifically chose both colours (if he doesn't want the text to be visible, so be it). But if you just see this as a preference issue, then I can live with changing the font colour at the character level--I just liked to be able to view the document in a different theme without modifying its content (that, and I don't understand why a non-automatic colour is being modified).
The actual patch is https://gerrit.libreoffice.org/c/core/+/158024 (the mentioned was reverted). It changed the calculation when a color is treated as dark moving the threshold from black or very dark towards the middle values. The issue with the font color has always been there and is also present in Calc: if the background is treated as dark and the font color is dark it becomes white, and vice versa, ignoring whether the font color is defined as automatic or a fix value. For example sc/source/core/data/patattr.cxx ScPatternAttr::fillColor()
We have two functions, IsDark() and IsBright() with thresholds of <=156 (62 before) and >=245. Meaning below a contrast of about 60% (25% before) or above 95% we use the defined font color.
Tomaz, you made some changes for the mentioned Calc method in https://gerrit.libreoffice.org/c/core/+/154061. Please advise how to proceed.
(In reply to Heiko Tietze from comment #9) > Tomaz, you made some changes for the mentioned Calc method in > https://gerrit.libreoffice.org/c/core/+/154061. Please advise how to proceed. I didn't look into this issue - yet. My change here was mostly refactoring as we called one GetFont method, which does 2 things - prepares the font and color. But in some cases we only cared about the font and in other cases only about the font color. When we were only interested about the font we called GetFont with SC_AUTOCOL_BLACK (which always changed AUTO to black). I changed this to 2 methods fillFontOnly and fillColor (and fillFont that does both) and then call fillFontOnly() when we were not interested in the color. Maybe I did a mistake at refactoring? It is possible...
*** Bug 159582 has been marked as a duplicate of this bug. ***
*** Bug 159628 has been marked as a duplicate of this bug. ***
Created attachment 192641 [details] Font effect Outline Another problem with the commit is Font effect - outline. See testcase and printscreen from 7.6 and 24.2
(In reply to raal from comment #13) > Created attachment 192641 [details] > Another problem with the commit is Font effect - outline. See testcase and > printscreen from 7.6 and 24.2 I can confirm this started at ddb483509113e469b771320fea52f1b089574021 (and was not good either at f07d47fff571c4446988715f3c21362b9eed4265~1) I'd suggest to focus on this issue here, as the problem of fixed dark font not respected for dark background is an issue inherited from OOo. (Bug 161595) Heiko, what do you think of that issue with font - outline?
(In reply to raal from comment #13) > Another problem... => bug 161863
The color defined as Automatic in tools > options > app colors is used for bright backgrounds, for example if your spreadsheet has a white cell background. It turns into white if the cell background becomes darker, mid grey, red, green, etc. The question is, what could be the opposite of a random color, or should we really use it unconditionally?
Created attachment 195107 [details] Calc test document
Created attachment 195108 [details] Writer test document The replacement happens only for dark on dark; changing the application color for fonts to magenta, for example, affects all backgrounds but white, light grey, and yellow.
I suggest to remove "Font color" from Tools > Options > Application Colors (and to always check against the background unless the color is set directly in the paragraph or cell etc.).
Woah, woah, I definitely enjoy the ability to set the global font colour in "Tools > Options > Application Colors" (theming is largely hindered without it). It seems the only issue (if there even is one) is in relation to the "Automatic" option for the font colour. Which--I will remind--that my initial issue was that even when a non-automatic colour was chosen, it was getting overridden (as though automatic). However, that issue has been fixed (I don't remember in what update, but not too long after my prior posts). If there are further issues with the "Automatic" colour option, that is a different problem as far as I'm concerned--my problem has all ready been fixed (many thanks). And I would appreciate not losing the "Tools > Options > Application Colors > Font color"
(In reply to zaakari from comment #20) > Woah, woah, I definitely enjoy the ability to set the global font colour in > "Tools > Options > Application Colors" (theming is largely hindered without > it). It seems the only issue (if there even is one) is in relation to the > "Automatic" option for the font colour. For what purpose? I mean you could see a blue font but printout would be black unless you set the font color to blue. It's not WYSIWYG anymore. > Which--I will remind--that my initial issue was that even when a > non-automatic colour was chosen, it was getting overridden (as though > automatic). However, that issue has been fixed (I don't remember in what > update, but not too long after my prior posts). This could be fixed by having only Automatic, ie. no customization.
(In reply to Heiko Tietze from comment #21) > For what purpose? I mean you could see a blue font but printout would be > black unless you set the font color to blue. It's not WYSIWYG anymore. I know it doesn't affect the final document--but that's the point: I can edit a document in a style that I like, or that is comfortable to the eyes on a monitor screen; without changing the document's output format. And if I'm working on a large project, it's easy to test colour changes across multiple files by using the global settings (rather than having to change each file individually).
Created attachment 195280 [details] Styled document view Here's an example of my current theme, which I like for working with; yet I still know the document will "print out" in standard black and white.
Created attachment 195281 [details] Styled document display Sorry, last attachment I had marked as PDF, but is actually a JPEG.
(In reply to zaakari from comment #23) > Here's an example of my current theme... Distraction free reading mode in dark environment- with low contrast achieved by grey font color. Sounds like a reasonable use case.
Created attachment 195398 [details] Impress test document
Created attachment 195399 [details] Calc test document
Created attachment 195400 [details] Writer test document
Patch submitted; it works but text in shapes is not updated on app color changes (edit or group etc. apply the new color). Shapes behind text in Impress is not taken into account, probably also not for other modules.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8534ad7b7b9aae2520d731cf748ff0aadfe2f0ed Resolves tdf#159541 - Fix font color must not change depending on background 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.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/98706cbfa6307de2f5a11ff0e5edb4120ad57bb8 Related tdf#159541 - Fix font color issue in Calc 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.
This caused a regressoin that reverted changes from bug 156182, automatic text color is dark again and not dependant on the cell background.
Correction: 1st patch did previos, 2nd patch fixed that. Sorry, not both were backported where I tested.