Created attachment 188997 [details]
Sample document used on the screenshots

Created attachment 188998 [details]
Screenshots demonstrating behavior

Created attachment 188999 [details]
Screenshots demonstrating behavior

This bug has been present for a long time. Google search yields several times it has been discovered and attributed to OS high contrast setting.

Different platforms / LO versions all exhibit same (wrong) behavior

See these older discussions where the exact same problem has been reported over the years:

https://forum.openoffice.org/en/forum/viewtopic.php?t=54724
https://ask.libreoffice.org/t/cell-colour-does-not-change/44265
https://forum.manjaro.org/t/no-libreoffice-calc-cell-background-colours-after-updates/122066
https://ask.libreoffice.org/t/cell-background-is-invisible/35947/4
https://ask.libreoffice.org/t/calc-cell-background-color-not-visible-on-active-spreadsheet/12389

Also on Windows.

(In reply to V Stuart Foote from comment #11)

> The cell bg colors follow the os/DE HC theme

As expected. The bug manifests if you set a background color on the cell. I assume these screenshots show cells without any fill, so do not seem relevant here.

OK, now I see the perceived issue. Perceived in that LO is handling HC theme exactly as it should, with the UI rendered in a reduced color palette as passed in from the os/DE.

User applied colors in the UI are ignored when os/DE signals HC in use and instead follows the HC theme provided.

Believe this is by design HC theme handling.  

Not clear we need do more as it would need a whole new theming logic to selectively adjust UI elements to "complement" the HC theme in use--where now such elements are ignored.

Created attachment 189014 [details]
Additional content examples

(In reply to V Stuart Foote from comment #13)

 
> Believe this is by design HC theme handling.  
> 
> Not clear we need do more as it would need a whole new theming logic to
> selectively adjust UI elements to "complement" the HC theme in use--where
> now such elements are ignored.

If this is by design, it certainly is very confusing. I checked some more user content and HC display behavior is very inconsistent (colors not always ignored)

- font colors are retained
- background colors are ignored
- conditional background colors, however are retained
- border colors are replaced by gray
- arrows lose arrowheads
- bars in charts are invisible

see new examples attached when viewed with HC.

I am not sure it is a good idea to adjust anything on user objects.

(In reply to V Stuart Foote from comment #13)
> OK, now I see the perceived issue. Perceived in that LO is handling HC theme
> exactly as it should, with the UI rendered in a reduced color palette as
> passed in from the os/DE.
> 
> User applied colors in the UI are ignored when os/DE signals HC in use and
> instead follows the HC theme provided.
> 
> Believe this is by design HC theme handling.  
> 
> Not clear we need do more as it would need a whole new theming logic to
> selectively adjust UI elements to "complement" the HC theme in use--where
> now such elements are ignored.

How users are supposed to understand how to ("correctly") use the color palette for the background color of a cell in Calc with this setting enabled?

If there is some limitation based on OS/DE, then:
* users have no way to know how to select the "compatible" colors in LO/Calc (if there is really such a thing); and,
* users cannot share documents/spreadsheets, if the colors are not seen by some other OS/DE (in the intended way, or at all); and,
* users have no idea whether some OS setting needs to be changed in order to be able to use this feature in LO/Calc.

If the only standard colors that are clearly-usable are black and white, then I don't understand the purpose of having a "High contrast" setting. I might be misunderstanding this feature.

If this setting depends/needs/complements some OS setting, it is not clearly understood from LO/Calc's (options) UI/UX.

FWIW, as mentioned in comment 0, this issue is not new, and it is also seen in recent LO Dev 24.2 versions on MS Windows too.

Setting to NEW (again), so these points can be addressed. This might not be a bug from the POV of how it was intended by developers, but at least a lot of tool-tips, help content and/or wiki pages seem to be needed for users to be able to "correctly" use this feature (or, even better, improve the feature itself). For instance, maybe the "High contrast" label should mention something about "OS-related" in some way; I'll leave the adequate term to UX team.

Quoting from Help content:
"
The cell background color is ignored then.
"
... which would mean _no_ color palette is supported, at all. What's the point of "High Contrast" then? Perhaps it should be named Black/White (Contrast) only? I'm at least confused.

IOW, the feature (and its UI text) is far from clear/intuitive/understandable for users ATM.

Yeah, this is apparently by design. Maybe following the "letter of the law" for some compliance effort in the past, I find the outcome quite odd but there is quite a lot of built-in code that works hard to provide this result for high contrast accessibility. IIRC when I enable a similar setting in e.g. MSOffice I get fairly bizarro-land results too. I tried to cover what I know in slide 7 of https://fosdem.org/2023/schedule/event/lotech_darkmodes/ which I'll paste here:

<<
Accessibility High Contrast Mode

May not be a dark mode, but often is, but this is a special mode. We make a special effort to follow these rules, with arguably strange results:

 * learn.microsoft.com/en-us/windows/win32/winauto/high-contrast-parameter
“Map all colors to a single pair of foreground and background colors. Use the GetSysColor function to determine the appropriate foreground and background colors, using either a combination of COLOR_WINDOWTEXT and COLOR_WINDOW or a combination of COLOR_BTNTEXT and COLOR_BTNFACE. The GetSysColor function returns the colors selected by the user through the Control Panel.
 * Omit any bitmapped images that would typically be displayed behind text. Such images are visually distracting to a user who needs high contrast.
Images that would typically be drawn in multiple colors should be drawn using the foreground and background colors selected for text.”
>>

I don't know if Michael W. has any specific insight into if we're doing this right at all, but I think this old a11y recommendation is why we end up like this.

Agree with Ady that this is implemented in a weird way. Plus, switching on via "[x] Automatically detect high contrast mode of OS" under tools > options > a11y is pretty awkward. 

Besides the question if we need to modify colors at all I believe the configuration should not be affected, in other words the dialog should still show the actual color.

Michael, what is your recommendation? Keep colors depending on HC and fix issues (see c14) or drop it and limit HC to the UI only (my preference).

Created attachment 189020 [details]
Screenshot of the sample document in Excel with High Contrast Black enabled

Created attachment 189021 [details]
Screenshot of the sample document in Excel with High Contrast White enabled

From looking at this a bit:

Excel seems to do the same as Calc and doesn't render the cell background when High Contrast is enabled, s. screenshosts attachment 189020 [details] and attachment 189021 [details], so seems to adhere to what Caolán quoted in comment 16.

(In reply to Heiko Tietze from comment #17)
> Besides the question if we need to modify colors at all I believe the
> configuration should not be affected, in other words the dialog should still
> show the actual color.

That sounds reasonable to me when it's about explicitly selecting a specific color.

> Michael, what is your recommendation? Keep colors depending on HC and fix
> issues (see c14) or drop it and limit HC to the UI only (my preference).

I think dropping the feature completely would be unfortunate, because I'd assume there are people that actually want high contrast in the document, which the current behavior ensures (and Excel on Windows does as well, s. above).

Ideally, we should probably support what the corresponding platform understanding of what a "High Contrast mode" is.

For the gtk3 VCL plugin, I'm wondering whether we need to have any specific code for the case of only covering the UI but not the document or whether this is already covered by the theme, i.e. whether switching to High Contrast in GNOME settings "just" sets a corresponding theme and icon theme and LO already does what it should because it supports themes.

@Balázs: Do you get the expected overall result when disabling the "Automatically detect high contrast mode of OS" or is anything in LO then not using high contrast where you'd expect it?

> 
> @Balázs: Do you get the expected overall result when disabling the
> "Automatically detect high contrast mode of OS" or is anything in LO then
> not using high contrast where you'd expect it?

First, I have no such setting per se. Instead, on my system, I have a selection of 3 options under Tools > Options > LibreOffice > Accessibility > Options for High Contrast Appearance > High Contrast, these are "Automatic", "Disable" and "Enable". I guess functionally this is similar to what you refer to?

Anyway, if I select "Disable" there, the document user content seems to display all colors, ignoring the HC setting in OS. The window/UI components are still in HC mode, whatever that is supposed to be (e.g. different icon set, but not *that much* different, so the intended result here is also questionable - this is a separate issue probably).

I think some context is needed: I filed this report because the HC setting had been turned on accidentally and the documents I worked with looked very awkward, some parts completely, some nearly illegible (e.g. charts and cells with colored background). This is different from someone deliberately turning on HC mode and not getting a reasonable display of their document. I was at a loss because I was unaware of the HC setting and had to investigate what on earth was going on.

I suspect that most of the cases linked in comment #4 are similar.

My point is that there are 2 distinct scenarios and two disjoint sets of affected users: (A) HC turned on deliberately and (B) HC turned on accidentally, as seems to be the case for some people (N.B. I still do not know, and probably never will, why the HC setting had been turned on on my system; I did not recall ever touching the OS display settings when the whole thing occurred.)

I can only speak for group (B), as I never use HC deliberately. The documents were unusable, the display looked wrong and I had to google for hours (not knowing what I was searching for) to find the cause. After finding the cause it seemed that this is a bug (I am not quite sure any more based on the comments above).

However, what I am quite sure is this: if HC is turned on accidentally, the current behavior is very confusing. In addition, I suspect there are many users out there like me who have not the faintest idea that (i) such a setting exists and (ii) it can be "mysteriously" activated somehow.

Maybe default setting to automatically follow OS high contrast setting (at least on the document user content) is not a good idea?

I checked Firefox and Chrome, neither browser does anything when I turn on HC in OS. I do not even find a setting for that, only some high color themes/extensions that have to be manually downloaded/installed/activated.

In fact not much changes on my display (hence the confusion) when I turn HC on. Some applications (e.g. Sytem settings, Evolution mail) change the icon set and highlight color, but the result is not that much different.

I don't find any other application that changes the display of user editable content for HC mode.

Ideal solution would be to detect HC setting being turned on for the first time and display a dialog asking what to do with document content. This would solve the issue with accidental HC setting and still enable HC display for those that turned it on deliberately.

As in comment 13 and comment 16 the os/DE signaled HC mode handling is by design.

Sorry but for those finding themselves having set the os/DE to HC we need to honor such signal from os/DE by default--and yes it explicitly will change colors of document objects. That is the nature of this Assistive Technology noting that other than colors, we also shift into our designated monochrome HC icon theme--Sifr (in a light or dark flavor depending on fg/bg color of the HC theme).

IMHO all of this is correct, and we provide suitable controls in the Tools --> Options --> Accessibility High Contrast options of 'Automatic', 'Disabled', 'Enabled'.

I would say it is a RTM issue, but agree it could be better documented for folks that find themselves lost.

As to enhancement to implement additional support for HC color values for additional document objects--that would need accessibility and UX design work of what would need to be parallel implementation paths of current core handling.

Other than documentation effort, IMHO this is a clear WONTFIX

(In reply to V Stuart Foote from comment #23)
> As in comment 13 and comment 16 the os/DE signaled HC mode handling is by
> design.

Yes, this seems to be the case. However, as already mentioned in comment #14, the current solution is very limited and inconsistent. It may even make the document illegible in extreme cases (e.g. white font on black background disappears completely). The spreadsheets that I use every day look completely rubbish if HC is turned on.

The idea of HC is to make the document easier to read.

The current solution does the opposite. It makes the document harder or sometimes impossible to read.

In my opinion it would be much better not to change the display of colors set by users until a full HC rendering can be produced. A solution that can handle background color, font, conditional formatting of cells, conditional formatting of number colors, drawing objects, charts, etc. ( Basically all objects where the user can change the display color) consistently. Until then, this is a bug, not a feature.

(In reply to Balázs from comment #24)

Are you claiming this from an accessibility perspective, or from a general 'Benjamin' user's perspective.

Our a11y Assistive Technology HC accommodation of table (calc & writer) colors is appropriate for users working with an os/DE signal flag for HC use.

Color handling for other users is unaffected and follows both theme and document template values.

IMHO NAB, and no compelling reason to enhance/refactor for HC use.

If you don't require HC, then do not set your os/DE HC mode, that is an a11y AT--don't abuse it.

(In reply to V Stuart Foote from comment #25)

> Are you claiming this from an accessibility perspective, or from a general
> 'Benjamin' user's perspective.
Does not matter. I provided plenty of examples where HC setting ruins the document display. Is it useful for anyone if document is illegible? I do not think so.

> If you don't require HC, then do not set your os/DE HC mode, that is an a11y
> AT--don't abuse it.
Obviously, although I do not understand the intended meaning of 'abuse' here.

If you like unreadable documents, just leave it as it is now.