Issue 75613

Reassigned. Is this an official OOo-version you are using or is this a version
distributed by some other source? Reassigned.

Official OOo 2.2 RC 3, downloaded from openoffice.org website. 

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.

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.

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. 

Thanks for the step by step description.
Set to new and change the target.

I can reproduce the bug.
Occurs also on Windows.
Please have a look.

Component changed.

*** Issue 81503 has been marked as a duplicate of this issue. ***

This issue seems to be related to Issue 75614 (Writer) which was fixed. Can the
Writer fix be used in Draw as well?

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

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.

tpesonen is right.
It's simply a bug that Impress ignores the document background configured in
tools/options/appearance.

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

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.