Issue 75613 - Automatic high contrast mode confuses impress users
Summary: Automatic high contrast mode confuses impress users
Status: CONFIRMED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: OOo 2.2 RC3
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 81503 (view as issue list)
Depends on: 112003
Blocks:
  Show dependency tree
 
Reported: 2007-03-21 16:37 UTC by tpesonen
Modified: 2013-10-08 11:43 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description tpesonen 2007-03-21 16:37:03 UTC
Found on SUSE-supplied standard KDE 3.5.6 on SUSE 9.3

OOo 2.2 rc3 now adopts colours from the desktop and assigns them to automatic
colours. If I want to get rid of this colour scheme and have my documents
displayed with their "true" colours, I need to alter them in
Tools->Options->Appearance. I can get my Writer docs to show with the normal
white background and black text this way.

The problem now is that if I start Impress, the slides still use the
desktop-inherited background colour, but the font colour is changed to black as
set in the options. This results, on my system, black text on dark background in
Impress. There seems to be nothing in the Options that would enable me to get
rid of the automatic (dark) background colour in Impress.

This leads to the following dilemma: I can make my Writer docs look "normal"
(white background, black text) but then my Impress slides will become impossible
to work with, having now black as the font colour, but with automatic dark
colour as the background colour. Only Writer recognises that the background
should not be of automatic colour. Impress does not respect this, nor allow me
to see the slides' original background in design view.

So: Either I have to content with automatic colours in Writer--something I do
not want to do--or accept the fact that Impress cannot be used due to the
ridiculous colour combination of black on top dark background, and even so that
the slides' background graphics do not show at all.

Impress shows the slides' true colours when viewed in slide show.

The solution: Make it possible for one to choose whether Impress uses automatic
or "true" colours. As it stands now, I cannot use Impress without accepting
automatic colours for the whole OOo, including Writer docs. This is not
acceptable by any standards.
Comment 1 wolframgarten 2007-03-22 08:50:31 UTC
Reassigned. Is this an official OOo-version you are using or is this a version
distributed by some other source? Reassigned.
Comment 2 tpesonen 2007-03-22 16:44:52 UTC
Official OOo 2.2 RC 3, downloaded from openoffice.org website. 
Comment 3 kpalagin 2007-03-25 15:03:34 UTC
tpesonen,
any chance you could provide detailed repro steps so that I can try it on Suse 
10.2?

Alternatively, if you have access to fairly powerfull machine with Windows you 
could try reproducing the problem in virtual machine (using free 
http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx) 
with Suse 10.2.
Comment 4 tpesonen 2007-03-25 18:15:27 UTC
Additional info and repro steps:

I also tested OOo 2.1, and this issue is present there as well: All colours and
behaviour, etc. are the same, it seems, irrespective to which version--2.1 or
2.2 RC's--I test. Note that 2.0.4 and earlier do not have this problem. On the
other hand, they don't adopt the colours from KDE either, but default to
standard black-on-white colour scheme for the documents.

To reproduce:
It doesn't seem to matter what the desktop colours are. Simply setting up a
colour scheme for the desktop at KDE Control Centre -> Appearance and themes ->
Colours. Selecting a theme with a darker background naturally makes this issue
more prominent.

1. Launch OOo 2.1 or 2.2 RC. I here used 2.1 for the screenshots, (first two
borrowed from bug 75614) as it shows exactly the same behaviour. Go to
Tools->Options->Appearance. On my OOo 2.1/2.2 RC's it is displayed as shown
below. Note that document background and font colours are set to automatic, and
this is also the default setting for a new installation.

www.lut.fi/~tepesone/OOo/75614-3.jpg

4. Change document background to white, and font colour to black.

www.lut.fi/~tepesone/OOo/75614-4.jpg

5. Text documents now appear with a white background and a black font colour.
But go to File -> New presentation -> Next (Empty presenatation chosen) -> Next
(with the defaults) -> Next (with defaults) -> Create.

Now Impress and the slides are shown as in the screenshot below:
www.lut.fi/~tepesone/OOo/75613.jpg

Note that unlike in Writer, the slide still has a darkish background, dispite
the option "background = white" that was set. There is no way to get rid of this
background, or have the original background (with a possible graphical theme) to
show. Opening an existing presentation also shows this similar dark background,
dispite what the background for the opened presentation happens to be. The
background is always shown correctly when viewing a slide show.

Please also note that bug 75613 might be related to this one. It is also
possible that bug 75566 is related in one way or another.

My system runs SUSE 9.3 with standard SUSE-provided xorg-x11 6.8.2-30 with KDE
3.5.6. I also updated to latest SUSE-built 3.5.6-41 RPM's, dated mid-March, but
that had zero effect on this issue. Previously I ran the very first SUSE-built
3.5.6 RPM's that became available at the time of the 3.5.6 release, through KDE
website.
Comment 5 tpesonen 2007-03-25 18:20:30 UTC
The numbers for the repro steps got mixed in the last post as I edited it. The
steps are correct, but the numbers came as 1, 4, 5. They should of course have
been numbered 1, 2, 3. 
Comment 6 christian.guenther 2007-04-17 16:27:43 UTC
Thanks for the step by step description.
Set to new and change the target.
Comment 7 christian.guenther 2007-04-17 16:29:00 UTC
I can reproduce the bug.
Occurs also on Windows.
Please have a look.
Comment 8 wolframgarten 2008-06-13 10:11:56 UTC
Component changed.
Comment 9 wolframgarten 2008-06-13 10:13:35 UTC
*** Issue 81503 has been marked as a duplicate of this issue. ***
Comment 10 Dotan Cohen 2010-01-28 09:38:33 UTC
This issue seems to be related to Issue 75614 (Writer) which was fixed. Can the
Writer fix be used in Draw as well?
Comment 11 clippka 2010-01-28 09:50:51 UTC
The issue is that one upon a time, someone decided that if the desktop
background color is 'darkish' then the desktop must be in high contrast mode to
aid users that have visual impairment. May argument back then against it was
that cool users will use black desktop themes and will get confused by all the
'features' of high contrast mode.

This issue is not a bug about impress, impress behaves like it is designed for
high contrast mode. The bug is rather that people unwillingly trigger this high
contrast mode.

My two ideas about this are still

1) disable automatic high contrast detection by missusing the desktop color and
make it an application option that has to be set

2) if an application option alone is not an option (because people who need it
will not find it) then upon first detection of a black desktop the user should
be *asked* if he want high contrast mode.

cl->fl,mt: I'm not sure if this is a user expirience decission or accessibility
so please both have a look
Comment 12 tpesonen 2010-01-28 10:03:55 UTC
The problem is not that Impress assumes the high-contrast mode automatically;
the problem is that if the user purposely selects in Options that the document
should show its real colours (this is sometimes necessary), it fails to do so.
Note that this very issue was fixed for Writer (and then filed against Draw as
well, since it shows the same bugs.) This is a bug.
Comment 13 malte_timmermann 2010-01-28 10:37:29 UTC
tpesonen is right.
It's simply a bug that Impress ignores the document background configured in
tools/options/appearance.
Comment 14 clippka 2010-05-31 16:50:48 UTC
cl->tpesonen,mt: No, the bug is in the writer. If I have kde and the gtk plugin
is used then we detect the black system background as high contrast mode. To
verify this, draw a filled rectangle and you see it is drawn without a filling
as it is specified for high contrast mode.
If you disable high contrast mode (using
tools->options->accessibility->Automatically detect high contrast mode of
operating systems) impress&draw paints the background correct.

Impress acts here as specified, no backgrounds and no filling during high
contrast mode.

therefore, the bug is in writer to use colors when high contrast is activate and
the bug is that we activate high contrast just because the user has a dark
desktop background. Since users without disabilities do not know how to disable
high contrast.

Before this bug comes back to me again, I can implement that impress uses the
configured document color like the writer does, still you will see no background
images and no filled shapes as long as we are in high contrast mode. This will
not be fixed by just implement the same bug the writer has.

cl->mt: back to you as the accessibility expert
Comment 15 malte_timmermann 2010-06-01 16:28:46 UTC
There are many things to consider here, so I wrote a new task to rework all this
HC stuff: #112003 #.

I don't think it makes sense to do some temporary hacks/fixes here, we need to
redesign the concept of the high contrast mode and if/when to use it automatically.

I still think that the colors in the OOo configuration should always be used
when different from "default", but this depends on how we define the HC mode in
the future.

So it probably the best is to completely postpone this issue.

Letting this depend on #112003#, same target, where 3.x hopefully means next
feature release after 3.3.