Apache OpenOffice (AOO) Bugzilla – Issue 115082
Chart Area not displayed with system background colour
Last modified: 2013-09-25 20:41:27 UTC
I am using OpenOffice.org 3.2.1 on KDE 4.5.2 on openSUSE 11.3. The background of all charts in OpenOffice.org documents is that of the system "View Background" colour, even when the actual Chart Area fill colour is set to something else. (However, when printing or exporting to PDF, the actual Chart Area fill colour is used.) Reproducibility: Always Steps to reproduce: 1. To make the problem more noticeable, first select a colour scheme with a conspicuous View Background. In KDE 4, this would be via System Settings->Application Appearance->Colors->Colors->View Background. Set it to something obviously non-white, such as dark grey or red. Then hit Apply. See attached file systemsettings.png. 2. Launch Calc and create a chart, or open an existing document containing a chart. The chart's background will be the same colour as the system View Background. See attached file chart.ods and screenshot chart.png. 3. Double-click on the chart to start editing it. The toolbar will show a button "Format Selection" next to a drop-down box. Select "Chart Area" from the drop-down box and click "Format Selection". Go to the Area tab. The Fill tab will probably claim that the fill colour is already set to White, though this is contradicts what is actually shown. Selecting another fill colour and hitting OK has no effect on the appearance of the chart.
Created attachment 72066 [details] System Settings dialog in KDE 4
Created attachment 72067 [details] Spreadsheet containing a chart
Created attachment 72068 [details] Screenshot showing incorrect display of chart
Do you use go-oo.org or do you use OpenOffice.org from http://download.openoffice.org ?
I use the official openSUSE 11.3 binaries.
I was asking because vanilla OOo doesn't have KDE4 system integration integrated so I was sure that it's a problem related to go-oo.org If you'd like to see by yourself then set the following variable within a shell and start the application from there export SAL_USE_VCLPLUGIN=gen This would use the generic (no) system integration and I believe your problem would pass away. Anyhow I leave this issue open because KDE 4 integration is something still missing for vanilla OOo. Changing issue type to ENHANCEMENT and assigning to pl
changing component and subcomponent
I can confirm that the problem does not occur when the environment variable SAL_USE_VCLPLUGIN is set to "gen". Am I correct, then, in assuming then that this problem is specific to the openSUSE build? If so I'll report the problem on the openSUSE bug tracker.
At the moment, OpenOffice.org does not come with the KDE4 plugin like openSuSE branded version does. So it may help you to report this in the opensuse tracker (and presumably get an update via yast once the problem is fixed). However I'll keep this issue and fix it at some point since OOo should have the KDE4 plugin, too. Preferably sooner than later.
I have reported this as an openSUSE 11.3 issue on the Novell bug tracker at https://bugzilla.novell.com/show_bug.cgi?id=647339
Even with KDE4 plugin I cannot see OOo taking the view color for the Chart, only for the (e.g.) calc document background. Anyway I just talked to iha and it would seem that chart does not react to system colors at all (aside from the "high contrast" flag which gets usually triggered by a dark background color); instead hard colors as per the currently selected chart color scheme are used. So changing this would be a chart issue, not KDE4 specific. Therefore I'll also set "platform" and "OS" to "All" and change the issue title.
The color value that is typically used to indicate that a color should be chosen automatically is currently identical with 100% transparency. In contrast to other document backgrounds the chart needs the possibility to be 100% transparent. This is the default for charts in impress for example. So for the chart the typical mechanism that is used by the other application cannot be used. A different approach will be needed.