Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Pasting graphs from Excel into Impress(not sure about others) does not use original selection of x and y data ranges. Arbitrarily changes x and y ranges into columns. | ||
---|---|---|---|
Product: | General | Reporter: | bananaphone103 |
Component: | chart | Assignee: | Armin Le Grand <Armin.Le.Grand> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | Major | ||
Priority: | P3 | CC: | Armin.Le.Grand, awf.aoo, fanyuzhen, jsc, jyl44, oooforum, pescetti |
Version: | 3.3.0 or older (OOo) | Keywords: | regression |
Target Milestone: | 4.0.0 | Flags: | jsc:
4.0.0_release_blocker+
|
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Attachments: |
Description
bananaphone103
2012-08-14 03:57:09 UTC
Created attachment 78927 [details]
I think try copying this graph in impress. I haven't been able to reproduce the problem again... When I paste the graph into impress now, it simply doesn't show up.
In the attachment I put a bunch of 1000's below , I was hoping for the pasted graph to plot 1000. the problem hasn't happened to me again, although now the graph just doesn't show up at all.
I confirm this issue. Three additionnal comments: - this is not an XLS problem, it occurs with ODS - not linked to specific chart, all types is concerned - pasting action loses chart datas in all apps (Writer or Calc) Maybe same bug than https://issues.apache.org/ooo/show_bug.cgi?id=118840 Thanks to have a look, this is a cruel regression. Is this a regression? I experience the same behavior in 3.3.0. Steps: 1) Open the test document by bananaphone103 2) Right-click the chart, then Copy 3) Paste in the same document: the pasted chart is identical to the original one 4) Paste in a new Calc document: the pasted chart differs from the original one I experience the same behavior in 3.4.1. (If it works in 3.3.0, it's easier to identify when it broke) Hello Andrea, I did it with a 3.3.0 and Win2008 TSE. The problem don't occur. Created attachment 80015 [details]
Screenshot 3.3.0 with chart pasted in new ODS
Marking regression. Indeed it is a bit tricky: - OpenOffice.org 3.2.1 Linux 64-bit: broken (no red/blue lines in pasted chart) - OpenOffice.org 3.3.0 Linux 64-bit: broken (lines become diagonal) - OpenOffice.org 3.3.0 Windows: works (so, regression!) - OpenOffice 3.4.0-beta (April 2011) Windows: still works - OpenOffice 3.4.0 Windows: broken (lines become diagonal, same as 3.3.0 Linux 64-bit above; regression confirmed) So this is a regression, at least on Windows, and it used to work correctly until 3.4.0-beta. hello, Also with dates on the X Axis on graph Example File .ods : http://forum.openoffice.org/fr/forum/download/file.php?id=53013 1. Data and graph on the Sheet1: the copy and paste of the diagram gives a result identical to the one that we obtain with the versions FR “Feuille1”! No column and no values display in the paste. Issue indicated for the version FR but which finally affects US also!. http://forum.openoffice.org/fr/forum/download/file.php?id=53014&mode=view 2. Data and graph on the Sheet2 : the copy and paste of the diagram modifies the Dates YYYY of the data on JJ/MM/1905 http://forum.openoffice.org/fr/forum/download/file.php?id=53015&mode=view Bypassing : Edit graph > Edit the X Axis > Format Axis... > Numbers > To Shoot Source Format > Format Code : Standard > OK Created attachment 80801 [details]
paste the chart of banaphone on a new calc
(In reply to papayes from comment #8) > Created attachment 80801 [details] > paste the chart of banaphone on a new calc The issue occurs in AOO 400m2 Rev 1489073 2013-06-03 (US) tested with WIN 8 PRO and Mac Os X 10.8.3 set showstopper flag ALG: Taking a look, preparing some libs ALG: Different versions, different stuff. Symphony still has #118840#, does not clone data, so correctly in same chart, but loses data in different document target. OOo3.3 does the same. OOo2.2 loses data after activating the chart, ranges are lost, copy/paste locally loses rest, to different document target copies parts, but also wrong. What should happen is that the copy-command makes a complete clone of the chart data to a local table. Taking a deeper look. ALG: Debugging chart XML in/export. Export writes full dada (1..7, 7x12, 7x13), but import only reads (1..3, 3x12, 3x13). Investigating why this happens... ALG: May still have to do with #118840#; there, the data for the table is forced to be added, before only the ranges were on board. Thus, this chart load error may be old, but never triggered before. Checking by temporarily removing that change... ALG: As expected: With #118840# removed it works as long as the sheet is called 'Sheet1', other sheet names or pasting to new calc looses data. Thus indeed this task maybe old but uncovered by fixing #118840#. ALG: Changed in activated original chart in 'Data Ranges' from 'Data series in rows' to 'Data series in columns' and all works well, all data gets copied as expected. This may be a good hint: exchanging rows/colums leads to loading three instead of seven data points per row. Also the display looks similar (from the trend) as the original error. Thus, this maybe an old chart load error. ALG: Setting a breakpoint in chart2/source/tools/InternalData.cxx:148, select chart from original, press CTRL+C -> chart gets saved, reloaded (for getting model/dimensions) and breaks there, all data is there. Going to another calc and pasting -> breaks there, only some data is there when loading the same chart. ALG: Debugged the chart lifetimes and the load/save cycles. - Load bugdoc is the first load of instance (a) - CTRL-C: save (a), create (b), load in (b) -> load in (b) seems okay - CTRL-P: save (b), create (c), load in (c) -> load in (c) has row/column flipped Has to do with InternalDataProvider's member m_bDataInColumns which is true by default. Forcing it to false in debugger makes the roundtrip work, so something is going wrong here. ALG: At initial load: ::com::sun::star::chart::ChartDataRowSource gets initialized to ChartDataRowSource_COLUMNS from SchXMLPlotAreaContext constructor. Then changed to ChartDataRowSource_ROWS from SvXMLImportPropertyMapper from XMLShapeStyleContext which seems okay. At copying: In SchXMLExportHelper_Impl::exportTable the call to xChartDoc->getData() creates an InternalDataProvider. IN the constructor the call to DataSourceHelper::detectRangeSegmentation changes the m_bDataInColumns from the default true to false (correct). The createInternalDataProvider helper also copies the data, but creates four lines in this case, see lcl_internalizeSeries and the @todo comment there. The value of bHasOwnData in SchXMLExportHelper_Impl::exportTable() is no longer correct (?). The call lcl_getDataForLocalTable creates two further InternalDataProviders using ChartDataWrapper inside lcl_getDataForLocalTable for the two accesses to xAnyDescriptionAccess, this cannot be wanted (?). Have to check InternalDataProvider lifetimes... ALG: Lifetime is okay, but creating three temporary InternalDataProvider for export seems not effective. Still in copy, but now to import: the constructed InternalDataProvider does *not* change the internal m_bDataInColumns to false in DataSourceHelper::detectRangeSegmentation due to this bool not yet set at the ChartModel. This may have to do with meDataRowSource member of SchXMLChartContext, need to see where it changes. ALG: It changes in SchXMLPlotAreaContext, member is mrDataRowSource, reference handed over as 12th parameter. Thus it gets changed at SchXMLChartContext before the InternalDataProvider is constructed, but is not yet set at the imported ChartModel. That's why it gets not correctly set in the InternalDataProvider. When doing this handish in this one situation, it works. Need to find the place and time to set the changed meDataRowSource at ChartModel... @Armin: You seem to be working on this bug. Can you take ownership as well? ALG: Yes, grepping... ALG: It looked like close to a solution, but it is not. The value is set in SchXMLPlotAreaContext::StartElement at the right place, but the construction of InternalDataProvider bases it's decision *not* on getting the value from the chart, but from taking a look at chart2::data::XDataSource created in DataSourceHelper::pressUsedDataIntoRectangularFormat (see DataSourceHelper::detectRangeSegmentation). At that time (we are in import) there are no ranges and the default for columns is the result. ALG: Looking for a possibility to set/receive a default value at ChartModel for the call to createInternalDataProvider, so that when no ranges are there this can be used and not simply the column default value. ALG: Finally, I have a first working solution. Class InternalDataProvider uses no longer a fixed default for m_bDataInColumns but allows handing over one in the constructor. It gets used when there is internally no data yet. It gets feded from ChartModelHelper::createInternalDataProvider which uses the UNO API calls to get the boolean property "DataRowSource" from the model data (chart2::XChartDocument -> chart::XChartDocument -> chart::XDiagram -> beans::XPropertySet). This works since it is set already at load time. I need to check this solution with some other use cases. One strange effect is that the chart data is 'flipped' from the original as if 'data series in rows' was changed to 'Data series in colums', complete with adaption of all ranges. This may be wanted, but I do not know where this is done internally. ALG: Doing some more tests. Ony charts with 'Data series in rows' should be affected (which is not the default). Created each chart type once, copy/pasted to other doc, save/load cycle, copy/paste to other app, looks good. "alg" committed SVN revision 1498356 into trunk: i120559 Corrected load for charts without RangeString bu twith local row-orie... ALG: Comitted, done. The latest build I get is AOO 4.0 r1496831, wait for revision 1498356 or higher for verification Created attachment 81039 [details]
paste the chart of banaphone on a new calc with 4.0.0_r1499347
I checked with 4.0 revision 1499347, I still see the problem when paste in a new Calc Steps: 1) Open the test document by bananaphone103 2) Right-click the chart, then Copy 3) Paste in the same document: the pasted chart is identical to the original one 4) Paste in a new Calc document: the pasted chart differs from the original one (no column data, and the legend differs from the original one ) please see attachment "paste the chart of banaphone on a new calc_4.0.0_r1499347.png" I experience the same problem in 3.4.1. I checked with 4.0 revision 1499347, I still see the problem when paste in a new Calc Steps: 1) Open the test document by bananaphone103 2) Right-click the chart, then Copy 3) Paste in the same document: the pasted chart is identical to the original one 4) Paste in a new Calc document: the pasted chart differs from the original one (no column data, and the legend differs from the original one ) please see attachment "paste the chart of banaphone on a new calc_4.0.0_r1499347.png" I experience the same problem in 3.4.1. I checked with 4.0 revision 1499347, I still see the problem when paste in a new Calc Steps: 1) Open the test document by bananaphone103 2) Right-click the chart, then Copy 3) Paste in the same document: the pasted chart is identical to the original one 4) Paste in a new Calc document: the pasted chart differs from the original one (no column data, and the legend differs from the original one ) please see attachment "paste the chart of banaphone on a new calc_4.0.0_r1499347.png" I experience the same problem in 3.4.1. ALG: @fanyuzhen: Please recheck. I also checked with rev 1499347 (the last snapshot build) german version, win7, original bugdoc. All worked well. I get the chart as expected with data and legend in a new calc, following your description. Maybe you are doing something different, e.g. hopw do you paste/copy? Use context menu? Use shortcuts? If you still can reproduce this error, give a *very* detailded step-by-step description, please. ALG: Also checked on mac with rev 1499347, works as expected. I checked it as well on Mac and everything works as expected Set the issue back to fixed, please verify |