Version: svn OS: Linux The bug was introduced with commit 43b0a39eb91. The commit breaks saving embedded objects like e.g. charts... the RowRepeatStorage does not take anchored shapes into account like the code before did (the loop is using tableContext.rowHasCellAnchoredShapes and compareRows) The problem is that we would need to introduce lot of additional code into Tables if we try to keep the RowRepeatStorage in sync (think of moving a shape around during editing). Reproducible: Didn't try Steps to Reproduce: 1. Load attached ODS into Tables and see that a chart is displayed. 2. Save the just opened ODS file. 3. Reopen the just saved ODS file and note that the chart is gone. Actual Results: chart is lost after roundtrip. Expected Results: Show chart after roundtrip.
Created attachment 66266 [details] ODS file that loses the chart after loading+saving roundtrip.
Setting to severity "critical" and very height priority cause the bug has the effect that data is lost.
The bug is fixed now. There where actually two bugs independent of each other present here that are both fixed now. 1) commit ecac0d03d9 reverts commit 43b0a39eb91 and fixes chart lost after loading+saving ODS file. 2) commit ed8b06dcbd fixes embedded objects are not saved if they are after the last row with content.
Git commit ee2dcfa593089cef64e6a7fcfdde9bd98991fd55 by Sebastian Sauer. Committed on 02/12/2011 at 11:18. Pushed by sebsauer into branch 'master'. Optimize saving to ODF. This combines the commits ecac0d03d90c and the idea from commit 43b0a39eb91 together to; 1) keep the to-cell anchored shape handling intact and working as expected. 2) improve the saving-speed by some tons of factors by using the RowRepeatStorage to compress identical rows together.