Calc: Automatic Font Color changed from 7.6.7.2 to 24.2.5 for tonal colors

[steve2018]

I am mostly not using styles, because in many cells there is a mix of font colors, but once all issues are tackled I set the whole cell to use the automatic font color and the background to tonal green 58%
LO 7.6.7.2 was using black for the text, but with 24.2.5 I now get white text, which is hard to read.
(Safe mode profile and factory reset did not help.)

Workaround: Setting the font color to black instead of automatic or applying a style. As now calc can filter by color it is a minor issue, but why is this change not mentioned in the release notes? (At least I cannot find anything, can somebody please point that out to me?)

[steve2018]

2024-08-05 calc tonal colors.xls (202.5 KB)
I forgot the attachment

[mikekaganski]

tdf#161766

[steve2018]

Thanks for pointing this out; (apparently I have been using the wrong search words); I had suspected that somebody must have noticed this already, so I asked here instead of filing a bug

Do you think the bug report would benefit from this attachment here?

Also the " *** Bug 162269 has been marked as a duplicate of this bug. ***" points to a bug report with an interesting attachment.

[mikekaganski]

@steve2018

I had suspected that somebody must have noticed this already, so I asked here instead of filing a bug

This is not good. Doing this, you didn’t change important metric of the bug importance: its duplicate count. Note that the amount of work that you or the community had to do didn’t decrease: I had to read your question, comprehend it, connect to what I knew about the existing Bugzilla issue, and comment here. Same as if I did the same in Bugzilla marking an issue as a duplicate.

There is another metric you can still change: add yourself to CC list of the bug. The two fields allow us to see how important the problem is to users. Thank you.

About attachments: currently a fix is in the work. I hope that it resolves it cleanly, because part of it is restoring old behavior in old documents. But the samples may still help, allowing to see if all cases are covered.

[steve2018]

Thanks for pointing this out; I always assumed duplicate bugs are highly annoying to developers. I also normally search around for quite a bit before I would file/post anything (at least 99% of any problem I research already has a solution or a bug report), but sometimes I just seem to use the wrong keywords.

I have added myself to the bug list.

I am rechecking the live color chart before I will attach it to the bug report.

[mikekaganski]

Heh. Often, the duplicates are annoying not to developers, but to those bug triagers, who themselves have incorrect expectations. And it’s pity, when such a triager would write something like “You should look for duplicates before filing your report” in your bug report… Of course, it might differ from project to project, but in general, requiring users to waste their time searching for duplicates is stupid, because users have so differing idea about what is wrong, and which words to use to describe that - and that’s OK; guessing that another person (possibly from another country, with a different native language) might call this bug is just a silly game, that would most often just decrease the incentive of the user to finally file the bug: they would say “it’s too much of work to just file that”.

And again: duplicate count is definitely a very useful metric.