Issue 35482 - high contrast can't be put off despite configuration setting
Summary: high contrast can't be put off despite configuration setting
Alias: None
Product: ui
Classification: Code
Component: ui (show other issues)
Version: OOo 1.1.2
Hardware: All Unix, all
: P3 Trivial with 2 votes (vote)
Target Milestone: OOo 3.2
Assignee: stefan.baltzer
QA Contact: issues@ui
: 70501 88084 (view as issue list)
Depends on:
Reported: 2004-10-13 23:13 UTC by wouter
Modified: 2017-05-20 09:26 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

screenshot of high contrast mode and relevant OO settings (62.79 KB, image/png)
2004-10-13 23:14 UTC, wouter
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description wouter 2004-10-13 23:13:20 UTC
I can't find a way to turn off high contrast mode. The appropriate setting in OO
configuration doesn't do anything.

Steps to reproduce:

- use a very dark gtk2 theme (such as Tenebrific)
- OO uses high-contrast mode
- switch off "Automatically detect high contrast mode of operating system" in
Tools > Options > > Accessibility
- restart OpenOffice

--> OO still uses high contrast mode.

PS: If I switch to a light theme, OpenOffice immediately changes to 'normal' mode.
Comment 1 wouter 2004-10-13 23:14:34 UTC
Created attachment 18383 [details]
screenshot of high contrast mode and relevant OO settings
Comment 2 stefan.baltzer 2004-10-19 18:01:34 UTC
SBA-> Wouter: OOo 1.0.2 is quite old. Please switch to a newer version (OOo
1.1.3 is available as well as OOo 2.0 cand. developer builds), verify your
findings and comment. Thank you.
Reassigned to ES.
Comment 3 wouter 2004-10-19 20:52:14 UTC
Sorry. It's 1.1.2, which is much more recent. I don't know if 1.0.2 had any high
contrast mode already.

Anyway, the options in the configuration window don't see to do anything at all.
Comment 4 eric.savary 2004-10-27 14:54:51 UTC
ES->MT: same thing on Windows. it has probably never worked....
When the option is OFF, OOo should come back to a normal non HC mode.
If not on the fly, at least after restart
Comment 5 malte_timmermann 2004-11-03 14:12:11 UTC
MT->SSA: IMHO we can't detect HC on/off, because it's just a theme and we guess
depending on colors.

Not sure - who can have a look at that? (VCL)
Comment 6 stephan_schaefer 2005-12-02 16:12:25 UTC
ssa->pl: I'm not sure who evaluates the "Automatically detect high contrast mode
of operating system" setting, but at least the toolbar images (high contrast vs.
normal) are set by the framework.
Comment 7 wouter 2005-12-24 04:29:43 UTC
This issue persists in the 2.0 branch, independent of the setting "Automatically
detect high contrast mode of operating system".

This is in Debian 'unstable' under Gnome. Curiously enough, OO doesn't go into
high contrast mode when run under KDE -- despite a similar, dark theme.

Toggling this setting has no effect at all. I wonder what the point of it is
then;  surely, the person(s) who implemented this function or any related
OS-specific code must have a clue about what's going on here.
Comment 8 philipp.lohmann 2006-01-10 17:38:36 UTC
see also issue 59364

However, what is the actual problem with the screenshot ? As far as i can see
OOo follows the theme (which is very dark) and the toolbars show the HC dark
icons (which they are supposed to do when the background color is very dark).

In general the highcontrast setting is not used very often over OOo's
application code and mostly in error.

On Windows systems the "high contrast" setting is just a checkbox which enables
a different set of themes. This setting is normally read from the system unless
you have enabled "Automatically detect high contrast mode of operating system",
in which case this setting is overridden by a guess based on the window
background color. On Unix systems the settings cannot be read from the system at
all since there is no such setting as "high contrast", HC is just another theme.
Here the "setting" is simulated by guessing - which happens to use the same
method as the "automatic" guess.

So i think there is no defect, but perhaps you expected something different to
happen by toggling "Automatically detect high contrast mode of operating system" ?
Comment 9 psquared89 2009-03-19 20:36:01 UTC
I believe the status in the screenshot _IS_ an error.  According to the ui spec
( ):

7) Automatically detect high contrast mode of operating system

This option will be used by the function GetHighContrastMode (responsible
developer is Philipp Lohmann). If this option is active (default is on) the
internal function GetHighContrastMode determines a high contrast mode not only
by analyzing a maybe existing flag of the operating system. Then the function
will also determine if the window background is dark by using the IsDark
function and return true regardless if a high contrast flag is set or not.

Instead of asking for this single flag at the SvtAccessibilityOptions the
applications should use the above method

The way I read this is that the system should only attempt to determine whether
the theme is a high contrast theme if this box is checked.  If this box is
unchecked, then OOo should not do any kind of theme checking and simply use
whatever the user-configured theme is.

Dark themes are becoming much more popular, especially with their default
inclusion in many popular distros.  Accessibility mode can make OOo virtually
_unusable_ for more advanced tasks, and there is NO way* to turn it off if
you're using a dark theme!  This makes this a _serious_ usability bug IMHO. 

*If there is, I haven't found it. Such a setting I would then consider FAR too
cryptic and generally a defect in usability.
Comment 10 philipp.lohmann 2009-03-20 10:30:35 UTC
*** Issue 70501 has been marked as a duplicate of this issue. ***
Comment 11 philipp.lohmann 2009-03-20 10:33:08 UTC
Comment 12 philipp.lohmann 2009-03-20 10:53:44 UTC
correct OS
Comment 13 philipp.lohmann 2009-03-20 14:42:50 UTC
fixed in CWS vcl101
Comment 14 philipp.lohmann 2009-04-28 15:07:21 UTC
please verify in CWS vcl101
Comment 15 eric.savary 2009-05-06 14:18:56 UTC
Fixed but failed in vcl101.
Let's give an other CWS a try...
Comment 16 philipp.lohmann 2009-05-06 14:24:07 UTC
Comment 17 mini 2009-05-28 14:42:02 UTC
Is issue #82875 a duplicate? And issue #52511 and issue #87147 ?
Comment 18 techgurufloyd 2009-06-05 18:14:34 UTC
I'm using KDE, and my kde themes are applied to gtk apps. It seems the threshold
is as follows:
OOo enters Contrast Mode when my system window background color is:
rgb: 38,38,38 or hsv: 0,0,38 (#262626)
rgb: 39,39,39 or hsv: 0,0,39 (#272727) disables that mode.

The Accessibility option "Automatically detect high contrast mode of operating
system" has no effect in any of the apps.

High Contrast Mode affects fill color on objects in impress as well as the
background color and borders of the cells in calc. Basically, all of the new
transparent selection stuff in 3.1.0 is disabled in this mode. In Writer I can
set background color on text, but not on objects (or at least, I can set it, but
it is not visible due to this mode).

A fix allowing me to use my dark themes in conjunction with open office, without
enabling the High Contrast Mode would be appreciated. Thanks!
Comment 19 philipp.lohmann 2009-07-07 12:16:50 UTC
ok, fixed but failed. The guessing part indeed is no more, but we finally have
OOo in the originally desired state where a dark background would result in the
high contrast "theme" everywhere it mattered (like in dialogs, toolbars,
virtually everywhere). And now we don't want that anymore I guess.

This will be more tricky than I expected. How awkward. It means that I and my
predecessors have told developers all those years "don't use the HC flag,
evaluate the background and see if it is dark". And now it will have to be the
other way around to make this work.

@cd: any input from the framework and toolbar point of view ?
Comment 20 Frank Schönheit 2009-07-14 16:29:21 UTC
Uhm, really?

That would be literally hundreds of places, where we would need to change the
"BackgroundColor.IsDark" heuristics. No fun at all.
Comment 21 techgurufloyd 2009-07-14 17:32:08 UTC
I think that would be fine if the HC option were enabled by default. If someone
has a dark theme, they can disable it.

"Application::GetSettings().GetStyleSettings().GetHighContrastMode()" should
then be used in place of every current instance of "BackgroundColor.IsDark".
GetHighContrastMode() should check "BackgroundColor.IsDark" if and only if the
HC flag -- enabled by the "Automatically detect high contrast mode of operating
system" option -- is on. At this point, if BackgroundColor.IsDark returns below
the acceptable threshold, then is the OOo HC mode enabled by returning true from

To save cycles, you might be able to just check BackgroundColor.IsDark once on
startup (and when the HC Flag changes) and set someother flag that
GetHighContrastMode() would use to check this.

Granted, I have not looked at the code base (and so maybe everything I've said
here is already clear and I didn't need to bother saying anything), but would
doing something like this work?:
sed -e

Where would that not work? Why else would the BackgroundColor.IsDark be used
that is not an accessibility thing?
Comment 22 philipp.lohmann 2009-07-14 18:24:52 UTC
@fs: yes, no fun at all.
@techgurufloyd: yes, that's essentially the plan. Only there are some places
where IsDark is not asked for HC mode but to react on dark settings (e.g. not to
paint black text on black). So it's not completely automatic.
Comment 23 philipp.lohmann 2009-09-01 11:41:19 UTC
fixed in CWS changehc; unfortunately the whole review could not be done due to
missing resources, but most of the UI does not use the guessing mode for HC
anymore if switched off in tools->options. The benefit for dark themes justifies
not waiting for all places to be fixed and therfore delay integration.

See also followup task 104678 (target 3.3). That also will cover the current
problem that switching off the "autoguess HC" mode only gets active after restart.
Comment 24 philipp.lohmann 2009-09-01 11:44:18 UTC
please verify in CWS changehc
Comment 25 stefan.baltzer 2009-09-09 09:05:12 UTC
Verified in CWS changehc.
Comment 26 lohmaier 2010-03-25 23:05:03 UTC
*** Issue 88084 has been marked as a duplicate of this issue. ***
Comment 27 gehrehmee 2010-12-10 22:23:10 UTC
This still seems to be coming up under 3.2.0. Only useful workaround so far is
to "export SAL_USE_VCLPLUGIN=gen" in .bashrc somewhere.

It seems like the document formats tend to assume white backgrounds as a
default. Eg, you can set the foreground color to a value you expect to be
visible, regardless of the system's configured background color. (partially ot,
but related). With this in mind, I'd expect the only useful behavior is to
ignore the system theme for document content, and only use the theme for
decorations/widgets that aren't part of the document.