https://bugs.documentfoundation.org/show_bug.cgi?id=167511
--- Comment #23 from Armin Le Grand (collabora) <[email protected]> --- (In reply to Michael Weghorn from comment #22) > Thanks, Armin! I can confirm the text color is now black (correct) with High > Contrast mode in editing mode now for CairoSDPR as well. Okay > However, black is now also used (even with > DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1) in actual presentation mode, > where the actual red background is shown, and the actual font color (white) > should be used, too, in my understanding. > > Do you have an idea on how to avoid that? Not really - what the change does is to react on HighContrast being set, so in principle the presentation *should* then be in high contrast too, right? The question is what is the error here... Of course when it was like that (ignoring HighContrast for presentation mode) until now that's an argument to stay at that (what also means we have no way to have presnetation in HighContrast - but never had - but would maybe need due to accessibility?). That's what I meant with it being an error by implementing it using hacks in the renderer - presentation mode is another renderer and it's not implemented there. I still think it should not be implemented in all renderers for all times, but where the draw commands or primitves get crafted - that way it will work in all renderers (including presentation mode and future ones like e.g. SkiaSDPR). What to do? For now I will try to find a way to not do the in principle right thing for slideshow mode - somehow (see, that will probably be another hack and we get deeper and deeper into the rabbit hole). In principle we would have to remove those hacks in OutDev and move all that stuff to where the rendering is defined. Imagine the code to draw a button: It is hard-coded to some colors and these hacks make e.g. DrawRect in OutDev ignore that colors and use HighContrast ones. Instead the code to draw a Button should have a color scheme from where it picks the colors. Then just use schemes for normal and HighContrast and whatnot. Problem is that there is never budget for things like this, I guess that's also the reason it is implemented as it is for now. Understandable, no one pays for cleanups which make it look as before ignoring the security and cleanup effect. But also ignoring that the code gets *again* more and more quirky and ssth like these modes need dozens of dozens of bugfixes - exactly for that reason. I would not be surprised when costs for that are a multiple at the end compared to just clean it up once. sigh... > I'd defer testing further cases until that's solved unless you think it > makes sense to still do it now. Okay -- You are receiving this mail because: You are the assignee for the bug.
