Created attachment 201802 [details] Sample presentation to reproduce the issue This was originally reported in the GNOME a11y matrix chat: > turn on highcontrast, and all your slides are white-on-white > I guess the issue is that my slides were using colorful backgrounds and white text > and it appears that hc just assumes black text and replaces the bg with white ? Steps to reproduce: 1) open the attached sample document in Impress which has red set for the slide background -> it shows fine as long as the high contrast feature isn't used 2) in "Tools" -> "Options" -> "LibreOffice" -> "Accessibility", set "High Contrast" to enabled 3) restart LO and open the sample file again Actual result: In the edit view, the slide now shows white text on light grey background, i.e. has a very low contrast. Expected result: Contrast should be high. (Either don't mess with the slide colors at all, or in a way that results in high contrast.) Further info: This seems to only affect how the slides are displayed while editing. When presenting them on screen, the red background is displayed and the contrast is fine (as with High Contrast disabled). Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 04e66ac54169dd2a00d53abec093375bba90fd60 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 201803 [details] Screenshot of the issue
Self-confirming, as originally reported in the GNOME a11y matrix chat and I can reproduce.
Bibisected with linux-64-25.2 to: commit 1acd37a671b9d3633a7d31a0b60478815fbc685f Author: Armin Le Grand (Collabora) Date: Fri Sep 13 11:42:27 2024 +0200 CairoSDPR: Activate globally to check builds/tests And the problem isn't reproducible with DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1, so it seems CairoSDPR-related. CC'ing Armin Le Grand: Can you please take a look?
(In reply to Michael Weghorn from comment #3) > Bibisected with linux-64-25.2 to: > > commit 1acd37a671b9d3633a7d31a0b60478815fbc685f To mention it, there the text is actually white on white background, so it's completely invisible. (The light grey instead of white background seems to be another behavior change introduced later.)
Created attachment 201806 [details] clips of attachment 201802 [details] in each of the Win11 standard HC themes Odd (or maybe expected), if I place Win11 into one of its HC contrast themes, the presentation does flatten in reasonable ways, text fg does complement canvas bg with a high contrast rendering in all standard Win11 HC themes (Aquatic, Desert, Dusk, Night sky). So, a11y HC response to os/DE HC theming seems correct here. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e38d4e8cf2b1a1b5c146acbe325d31f84da676b0 CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Would note that for Windows builds the Tools -> Options -> Accessibility the High Contrast lb is set to "Automatic" by default, no need to "Enable" it. Is the issue there maybe on the gtk3 backend?
IIRC the determination of fg/bg contrast over low luminance bg came up a few times, like see also bug 156182 and bug 156685, where IsDark() vs. IsBright() got tweaked https://gerrit.libreoffice.org/c/core/+/158024 Don't know if that is at play here when entering HC mode, or if there is something specific to the gtk3 vcl plugin. But seems the fg/bg contrast calculations are working on the Windows builds responding to HC theme settings.
(In reply to V Stuart Foote from comment #6) > Would note that for Windows builds the Tools -> Options -> Accessibility the > High Contrast lb is set to "Automatic" by default, no need to "Enable" it. Explicitly enabling is just what I did to not have to tweak any desktop environment settings, but the exact way it gets enabled should be unrelated here. > Is the issue there maybe on the gtk3 backend? I only noticed later (see comment 3) that this is CairoSDPR-specific, which would explain why it's not seen on Windows. I can also reproduce with qt6 (which also uses Cairo), but using either DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1 or SAL_VCL_QT_USE_QFONT=1 to avoid the CairoSDPR code path makes it work fine there (text becomes black on light background).
(In reply to Michael Weghorn from comment #8) So the CairoSDPR does not reimplement the tools/color luminance based contrast testing? Something needed for testing os/DE HC theme flattening, maybe around BColorModifier_RGBLuminanceContrast? https://opengrok.libreoffice.org/xref/core/basegfx/source/color/bcolormodifier.cxx?a=true&r=c03d752c614b3b19ed89a510d7791bc46604a452&h=368#367
(In reply to V Stuart Foote from comment #9) > So the CairoSDPR does not reimplement the tools/color luminance based > contrast testing? > > Something needed for testing os/DE HC theme flattening, maybe around > BColorModifier_RGBLuminanceContrast? > https://opengrok.libreoffice.org/xref/core/basegfx/source/color/ > bcolormodifier. > cxx?a=true&r=c03d752c614b3b19ed89a510d7791bc46604a452&h=368#367 Armin might know. (I'm not familiar with the CairoSDPR code, so can't say anything right now without spending time to dig deeper first.)