Apache OpenOffice (AOO) Bugzilla – Issue 85913
row-mapping and column-mapping for charts using their own data is not imported correctly
Last modified: 2013-02-24 21:22:41 UTC
There exist files with charts that have their own data and a column-mapping or row-mapping sequences that swap the data accordingly. See the attached examples to observe the problem.
Fixed in CWS chartmapping
It appears that a file created in the following way: 1. Create a chart in Calc 2. Swap two data series (useing the Arrangement menu in the context menu of a data series) 3. Copy the chart to the clipboard 4. Paste into Impress 5. Save contain a column- or row-mapping that obviously has to be ignored. In current versions (OOH680.m5 or m6) the file loads correctly. With the current fix for this in CWS OOH680/chartmappingfix those documents are loaded incorrectly! So maybe the bugdoc in question has a different problem. As it contains confidential data, I cannot attach it.
Created attachment 51403 [details] An Impress document with a Chart that has column-mapping
Created attachment 51407 [details] This is a bugdoc that shows the issue and the fix in chartmappingfix
I created a bugdoc that shows the initial issue: 1. Create a Chart in Impress with OOo 2.2 2. Save 3. Open file in a text-editor and manually add a column-mapping "1 0 2" 4. Re-load with OOo 2.2 5. Double-click the chart to get a new view. Note that OOo 2.2 loads the document using the column-mapping 6. Re-save => That's how the bugdoc was done. Question remains how such a document can be created in a "regular" way.
Fixed now correctly in CWS OOH680/chartmappingfix. Both bugdocs should load correctly now. The fix was changed to only apply the column- and row-mapping if the range-string for the chart is empty. This was indeed a subtle thing to find out. There are the following situations: 1. The chart gets its data from the container document. Then, the mapping is forwarded as parameter to the data provider and is handled by the container application 2. The chart has its own data, and was created directly in this way. Then, the range-string is empty, and the mapping has to be taken into account (it is still unclear how such a document can be created. Even copying a chart from Calc to Impress, modifying it and copying it again to a different Impress didn't work) 3. The chart has its own data, but was copied from a place where it got the data from outside. Then, there is still a range-string in the file, which is technically invalid. In this case the mapping must be ignored.
Please verify in CWS chartmappingfix
The new chart, unfortunately still exports the column-/row-mapping, although this should not be necessary. Therefore, with the current fix, the attached mapping.odp is written with own data (without a range-string) and column-mapping, i.e. you get a document like mapping_bugdoc.odp. However it breaks on reload. This seems to be a far more subtle fix as thought in the first place and needs thorough testing. Target -> OOo 3.0
Created attachment 51909 [details] Document with column-mapping, own data and series at different axes
Everything seems fine so far. I found one thing with the attached mapping_axes document. The series order in the legend is different. But as I found out, the file is loaded correctly, the series order is correct, only the order of series displayed in the legend is different. With the new chart the legend displays all series attached to the primary y-axis first, and then all series attached to the second axis. Therefore it looks different in the example. Note, that the order of the series is correct, though. When you check the option "Series side by side" in the object properties of a series, you can see that the order in the legend becomes the same as in the metafile. So, this is not a bug related to the wrong mapping import. It is just a different behavior of the legend display (which was intended in the new chart)
verified
seen ok in current master -> closed