[upstream] Appearance Automatic setting should not use theme colors
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LibreOffice |
Invalid
|
Medium
|
|||
OpenOffice |
Confirmed
|
Unknown
|
|||
openoffice.org (Ubuntu) |
Won't Fix
|
Low
|
Unassigned | ||
Bug Description
Binary package hint: openoffice.org
When using any desktop colour scheme that uses a colour other than white as the background colour for text boxes and the like, OpenOffice.org uses the non-white background colour where it is inappropriate to do so.
Likewise, it uses the "input box" color (which in Ubuntu 10.10 is gray and renders quite different from black on some screens).
It happens both with KDE colour schemes or Gnome theme colors.
To reproduce the bug, simply change the desktop colour scheme to one that has a non-white colour as the background colour (e.g. the preset "Dark Blue") and then start, for example, OpenOffice.org Writer or Impress.
The bug seems to have always been present.
The screen display is supposed and expected to be providing a WYSIWYG view of a document as it would be printed, presented, or exported to, say, pdf. Te ultimate background colour is intended to be white, as well as the automatic color for non-highlited portions of the doucment should be black.
As far as I am aware, there are no situations where the non-white colour gets transferred to the printout or, in the case of a presentation, on-screen presentation of the document.
Examples of the bug include the normal Print Layout in Writer (I'd argue it doesn't matter or is even expected behaviour in Web View) and, as far as I know, all the views in Impress, save for the slide presentation itself and the animation previews.
A partial workaround is to set the Document Background colour to White and Font Colour to Black under Options > OpenOffice.org > Appearance. This rectifies the problem in Writer, but not in Impress or Draw. This is ironic, as Writer is probably the least important of these three for the workaround to work on. There might also be other colours that need changing in those settings to make the workaround complete. For Impress and Draw, the page colour must be set for the specific presentation or drawing and the "Colour" view mode specifically selected over Greyscale or Black and White.
The resolution for this bug would be to totally disregard the desktop colour scheme for anything that represents or affects how a finished document will look, because this is unstable, unreliable, useless behaviour.
Changed in openoffice: | |
importance: | Undecided → Unknown |
status: | New → Unknown |
Changed in openoffice: | |
status: | Unknown → New |
Changed in openoffice.org: | |
status: | Confirmed → Triaged |
Changed in openoffice: | |
status: | New → Confirmed |
summary: |
- [Upstream] [hardy] Assumes theme background colour is white. + [upstream] Assumes theme background colour is white. |
summary: |
- [upstream] Assumes theme background colour is white. + [upstream] Appearance Automatic setting should not use theme colors |
description: | updated |
Changed in openoffice.org (Ubuntu): | |
status: | Triaged → Won't Fix |
Changed in df-libreoffice: | |
importance: | Unknown → Medium |
status: | Unknown → New |
Changed in df-libreoffice: | |
status: | New → Invalid |
A means of making the workaround for Writer work for Impress and Draw is to go to Options > OpenOffice.org > Accessibility and disable "Automatically detect high-contrast mode of operating system" and "Use system colours for page previews". It's still necessary to select "Colour" mode over Greyscale or Black and White though. On Impress this seems to require clicking on the slide first, which seems odd to me, and it doesn't affect the slide previews down the left hand side.
For some reason, a side effect of having a dark desktop colour scheme seems to be that OpenOffice.org defaults to not using Colour mode (I don't know which mode it does use - there's no tick mark next to any of them). I have verified that this is due to the colour scheme by changing to a lighter colour scheme and back again.