** Description changed: 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. - I am using KDE, so the colour schemes in question are KDE colour - schemes. I have not attempted to reproduce the bug in other desktop - environments. + 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 has existed for some time, so I think it has probably always - been present. + The bug seems to have always been present. - For the purposes of this bug, I define "inappropriate usage of the non- - white background colour" as being situations where the screen display is - supposed to be providing a WYSIWYG view of a document as it would be - printed or presented and where the ultimate background colour is - intended to be white, but where instead the non-white, colour scheme - colour is used to display the document. - - This is not to say that documents should always have a white background, - but paper is nearly always white (and documents printed as if it is) and - it is silly to design a presentation on a dark blue background when it - will be presented with a white one. + 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 not useful behaviour. + document will look, because this is unstable, unreliable, useless + behaviour.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/159315 Title: [upstream] Appearance Automatic setting should not use theme colors -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
