Observed in versions 6.1.5.2 and 6.2.3.2 To reproduce the problem: Go to Tools > Options > Application Colors Under Document background, select Dark Gray 3 and click OK Select data for chart (example data attached) and ensure that font color is Automatic Click on Chart Wizard icon in the Standard toolbar Select any chart type Click Finish Click outside chart to leave edit mode Click chart to select it Click and drag a selection handle to increase or decrease chart size Expected result: The font color in the chart axis labels and legend is black Result: The font color in the chart changes from black to white when the chart size is changed. Because the chart background is white, the white text becomes invisible.
Created attachment 151473 [details] data for testing chart
I could reproduce this on Linux 6.2 Version: 6.2.3.2 Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: threaded
With the mention that text is first black, but after going outside of the chart and resize it the font color change...To automatic which in this case became WHITE. Reproduce also on Version: 6.3.0.0.alpha0+ Build ID: 96ab20756316b25b7f2343a15596bc5114ea5a68 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-02_14:29:16 Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: threaded
No repro 4.0, usign Appearance and darkest grey. Repro 4.2 with Grey 10. Regression. Repro 7.0+.
Bibisect with 41max: 7019e8654514116303a57895f660b5f3a39f364f is the first bad commit commit 7019e8654514116303a57895f660b5f3a39f364f Author: Matthew Francis <mjay.francis@gmail.com> Date: Fri Sep 18 10:43:03 2015 +0800 source-hash-77e21bb36a2cdaaa0f4049dee0d45c5b2325c6e9 commit 77e21bb36a2cdaaa0f4049dee0d45c5b2325c6e9 Author: Luke Deller <luke@deller.id.au> AuthorDate: Sat Mar 9 01:26:56 2013 +1100 Commit: Fridrich Strba <fridrich@documentfoundation.org> CommitDate: Mon Mar 11 14:54:57 2013 +0000 Change definition of "dark" colour for fdo#61993 Previous source-hash-b0dec5f73dbfe2ca1db2fec6d3e84472f2b62a3f. Single commit. https://gerrit.libreoffice.org/plugins/gitiles/core/+/77e21bb36a2cdaaa0f4049dee0d45c5b2325c6e9%5E!/ I'm not sure if Luke is active, but I'll add in CC to see.
Thanks Timur. This commit 77e21bb36a2cdaaa0f4049dee0d45c5b2325c6e9 simply changes the threshold at which a colour is considered "dark". When I revert the change in commit 77e21bb36a2cdaaa0f4049dee0d45c5b2325c6e9 upon latest git master, I can still reproduce the problem using a document background of "Dark Grey 3" (red=28,green=28,blue=28). I suspect your bibisection was using a slightly lighter colour? Would it be possible to repeat bibisection with a darker colour? In terms of debugging the underlying problem, I notice that the decision to use a white font comes from editeng/source/editeng/impedit3.cxx ImpEditEngine::GetAutoColor() (because if I change that to return COL_LIGHTRED instead of COL_WHITE then try to reproduce this bug, the font color in the chart axis label becomes light red when I resize the chart). This wrong decision appears to be because it is referring to background colour of the ImpEditEngine instance which is different from the background colour of the chart.
Another bibisect in 4.1 with 80% grey gives the same result.
Dear Cathy Crumbley, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproduced in 7.6.1.1 using the Dark scheme in Application Colours. After resize or filesave, colour becomes unreadable. The other way around, in Draw/Impress, the chart starts with unreadable dark-on-dark, then uses white on resize or filesave. No change in Writer. Given that: - we now have the Dark scheme in Application Colours - it is applied automatically in some cases (see e.g. bug 152184) - it affects Draw/Impress as well, not just Calc - it is a regression - it affects accessibility I am increasing the priority to "high" Version: 7.6.1.1 (X86_64) / LibreOffice Community Build ID: c7cda394c5de06de37d8109c310df89a4d4c3a98 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Confirming the issue for Dark/Impress with transparent chart background but not Calc where the background is white.
(In reply to Heiko Tietze from comment #10) > Confirming the issue for Dark/Impress with transparent chart background but > not Calc where the background is white. Try resizing the object outside of edit mode, maybe?
(In reply to Stéphane Guillou (stragu) from comment #11) > Try resizing the object outside of edit mode, maybe? Nope, maybe because I'm on kf5.
According to comment 6, this is not a regression
To avoid the issue of thresholds, I tested with a black document background (thanks for the hints, Luke). Using the linux-64-releases bibisect repo: - OOo 3.3 to LO 3.6.7.2: white font, doesn't change after resize - since early 4.0 (some builds could not run): starts with black font, but resize updates it to white Because Calc uses a white chart area, it looks like the issue was inherited (white on white always) and slightly improved in 4.0 (black on white at creation, but white on white at resize). Because Draw uses a "none" fill for the chart area, it looks like a regression in 4.0 (was white on black always, but is now black on black at creation, then white on black at resize). So the underlying issue is the same in both components, but there's two aspects: - generally, automatic font colour in the chart should consistently be based on whatever is visible behind it, straight away at chart creation. This is an inherited issue. - specifically, the issue of font colour change on resize is a regression in 4.0. I'm focusing the summary on this issue. Using linux-43all bibisect repo, looking for the "font colour updates after a resize" issue, I get to the following range: https://git.libreoffice.org/core/+log/4316e643ef345b0f673b4a03a80a4b7cb3185588..ae4e4a11d4300f7448cb6bd170fcb034542caddc From that range, I'd say the most likely one is the mega commit "re-base on ALv2 code": 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 Charts objects are extra tricky in that they have a chart area but they also have an object background (see e.g. bug 125714) and can contain a number of extra objects with their own background (title, legend).
(In reply to Heiko Tietze from comment #12) > Nope, maybe because I'm on kf5. I can reproduce the switch in colour in both Draw and Calc with gtk3, kf5 (cairo+xcb), and gen.