Created attachment 79896 [details]
3D chart graphic exported to SVG from AOO Draw

Created attachment 79897 [details]
3D chart graphic exported to SVG from AOO Calc

Created attachment 79898 [details]
3D chart graphic exported to SVG from AOO Writer

Export is done using AOO API, you can test with this extension that adds to the context menu of a selected chart a menu item to export the chart graphic:

http://people.apache.org/~arielch/extensions/contextmenuinterceptor/

The extra path is

 attachment 79898 [details] 
<path fill="rgb(255,255,255)" stroke="none" d="M 8004,9022 L 0,9022 0,0 16007,0 16007,9022 8004,9022 Z"/>

 attachment 79897 [details]
<path fill="rgb(255,255,255)" stroke="none" d="M 7594,8996 L 0,8996 0,0 15187,0 15187,8996 7594,8996 Z"/>


Commenting this line, the hex encoded image becomes visible.

Created attachment 79899 [details]
Snippet of the code exporting the chart graphic

Note that the code is exactly the same in Calc and Draw/Impress, so the difference might be that Calc/Writer add a white background to the chart graphic, and the svg export places this background above the hex encoded image element.

Adapting the Summary to reflect the actual bug: not only the hex encoded image is hidden by the white filled path representing the chart background.

ALG: I have to take a look at this. It is correct that 3D is a encoded picture, SVG has no 3D part, no other way to do it. Need to check where the white polygon comes from...

(In reply to comment #7)
> Need to check where the white polygon comes from...

The white polygon is the "Chart Area"/page background, it has a default fill color set to white, see StaticPageBackgroundDefaults_Initializer::lcl_AddDefaultsToMap in chart2/source/model/main/PageBackground.cxx

Calc/Writer leave this default as is (in Calc, if the chart area was transparent, the sheet grid lines will interfere with the chart wall grid, making it hard to visualize the chart).

In Draw/Impress, right after you insert a chart (may be in FuInsertOLE::DoExecute sd/source/ui/func/fuinsert.cxx), the chart defaults are modified (ViewShell::AdaptDefaultsForChart in sd/source/ui/view/viewshe2.cxx), the document's page background's "FillStyle" is set to drawing::FillStyle_NONE).

So this is a feature (though it looks rather inconsistent to make Draw/Impress behave different from Calc/Writer!).

Exporting a 2D chart in Calc/Writer to SVG also exports the white "Chart Area", but the path with white fill color is defined as the fourth element in the svg, and as the order in which element are defined is the order in which elements are drawn, it does not hide the subsequent elements.

It looks like the issue is not this background, but its misplacement within the svg document when the 3D chart is exported. An experiment, exchanging the places of the <image> with the <path> seems to tell that their position withing the svg document is swapped.

Created attachment 79906 [details]
Swap experiment

Swapping the position of the <image> with the <path> element in the svg document

ALG: @Ariel: Does this also happen with 2D-charts? I tried to install the extension, but the extension manager tells me that 'loading component library failed' with my 3.5 build. Can the same be caused by direct interactions?

ALG: Two problems here:

(a) The background fill somehow 'moves' in front of the graphic, but only on export (only to SVG? Ariel, what about exporting 3D chart to other formats that way?)

(b) Indeed I removed the default back fill since I enabled regular fill styles for Chart OLEs (in their role as normal SdrObjects). That fill from the chart content breaks this feature. It also should be removed in SW and SC IMHO.

ALG: @Ariel: Have you made some checks (please look at comment 10,11)? I still cannot reproduce, but try to find the problem...

ALG: Changed the default for the chart to create an invisible background object, so that in all applications the fill style will have an effect when set. E.g. in SW when inserting a chart and setting the resulting object's fill style to red, this cannot be seen (only a red border), so this is an error per se from my POV. Same in Calc when setting a fill color.
This may already resolve the export error in the default case (since the background is missing), but at the activated chart you can add a fill style again. BTW: The default line style for the chart was already none, so that settings in the apps on the object containing the chart had an effect.
This fixes case (b) for all apps, comitting...

(In reply to comment #10)
> ALG: @Ariel: Does this also happen with 2D-charts? 

No, with 2D chart everything is ok, exporting to SVG and other formats.
With 3D, exporting to raster formats works fine, only SVG produces this behavior.

> I tried to install the
> extension, but the extension manager tells me that 'loading component
> library failed' with my 3.5 build. 

I see the same error on a non-pro 3.5 build on Windows. Strangely, I could install the extension on 3.4.1

ALG: Changing the default is bad for data exchange since defaults are not saved; it is indeed necessary to set the attributes after chart creation; changing to that...

ALG: Okay, when adding mechanisms to change the fill background setting using too.ling after creating the chart OLE all is fine, checked all exchanges (draw/impress/calc/writer) with older versions in both directions. Comitted that.

@Ariel: Looks like a specific SVG export error, I never looked at SVG export. Can you try if it can be worarounded by setting fill to none in the activated chart OLE's ChartAreaFormat, please?

ALG: Tried the following to reproduce:
- New Impress
- Insert chart (button in top toolbar)
- Set to 3D chart
- In activated chart, right-click on empty space, use 'Format Chart Area" and set a AreaFill Color (lightred)
- Deactivate chart
- Select chart
- Use Export, use 'selection' in dialog, export to SVG
-> Works well here...

This *should* use what the API uses, so I still cannot reproduce, but the exporter seems to work, too...

(In reply to comment #14)
> > I tried to install the
> > extension, but the extension manager tells me that 'loading component
> > library failed' with my 3.5 build. 
> 
> I see the same error on a non-pro 3.5 build on Windows. Strangely, I could
> install the extension on 3.4.1

there might be a bug: installing the MySQL Connector from http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/downloads/list results on the same error on a 3.5 non-pro build, Windows 7, 64 bits.

Both extensions install fine in 3.4.*, on the same computer.

Created attachment 79912 [details]
Zipped folder with documents, macros, and samples

On Linux, after updating to rev. 1402787 the bug is no longer reproducible: the path with the white background appears as the first element, in Calc/Writer

The same on Windows, with a pro build with rev. 1409264 (the extension can't be installed in a non-pro build, but in a pro-build it works; this might be a regression, I'm not sure, but anyway this is another bug)

@Armin: you might have fixed this with one of your last week committs :)

Resolving as fixed

@Armin: yesterday with one of your changes charts have transparent background in Calc; I guess this might be a controversial default: now Calc grid is visible through the chart, and it makes hard to visualize it.

ALG: @Ariel: Yes, you are right. I saw that and I see it controversial, too.
@Regina: Setting you to CC since you often know a good solution ;-)

Pro:
In principle it is the right thing to allow the user to give the object a fill in the usual way (what is much more intuitive than to activate chart and set it there, who will know that). The consequence is that the coart is transparent (it's background). The grid lines in calc are helpers which are only visible in the edit view, not when printing.

Contra:
The visualisation with the helplines is irritating (indeed)

Alternatives:

(a) I can set this back to default for charts created in calc
(b) leave it as it is

When doing (a), on the first look all seems well. When the user sets a fill style (e.g. color) this will not get visualized. He *has* to know that there are two sets of attributes,
- one from the chart (editable when chart is activated)
- one from the SdrObject containing the chart OLE (editable normally)
where the first covers the last.

I thought about only painting a backgrund for edit view, but this is difficult, error-prone and wrong (when the user has already another draw object behind the chart, WYSIWIG would be wrong).

I tend to do (a) since it covers the standard case (and explain how to switch off chart fill to all which will write bugs...)

Any better ideas?

I have tried Ariels extension with a r1397615 on WinXP. I see now error. The chart area is drawn first and therefore in the back of all other elements.

In Calc the default should be a white chart area, because in default settings the grid is shown in AOO (in contrast to LO) and the grid is printable, a setting which I use often. I have not heard anyone complain about the defaults, so why change them?

The object background should be set to none as for all other OLE objects. People know to set the chart area filling, because that has always been possible and is possible in other applications too. The object background is not exported to PowerPoint (or PP does not know such background?) and LO still ignores the object background of OLEs, so using the object background instead of the chart area will give compatibility problems.

In edit mode there is already a temporarily white background. What do you mean with "I thought about only painting a background for edit view"?

ALG: @Regina: Thanks for taking a look. I'll change back the default for charts created in calc. "I thought about only painting a background for edit view": Forcing a white fill behind chart OLEs in calc onl yin edit view (not in print, export, ...).

ALG: BTW, PPT knows fill style for OLEs, that was the reason to add and enable this feature;-)

ALG: Ah I see the EditMode possibilities which may be misleading; here is what I call them:
- (Document) edit view: Where you manipulate objects in the application
- activated OLE edit...

ALG: Okay, changed and committed. Done.