Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Automatic high contrast mode confuses impress users|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||clippka, issues, kpalagin, malte_timmermann|
|Version:||OOo 2.2 RC3|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:||112003|
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
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.