GNOME Bugzilla – Bug 634135
Hang or taking-way-too-long on ods save
Last modified: 2010-11-06 04:52:14 UTC
Extracted from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602257 1. gnumeric foo.ods 2. File->Save ***time passes***
Created attachment 173926 [details] foo.ods
1 million formatted rows will take a while:
+ Trace 224523
If I recall correctly then at some time we combined all the empty rows but run into problems with the formatting. What we should really do is figure out whether rows are identical in style _and_ content without having to look at each of them.
Strange,when this file was saved the first time we knew that there was no content in the last 983039 rows and that they were all of the same style and we wrote in odf_write_styled_empty_rows: <table:table-row table:style-name="AROW-2" table:number-rows-repeated="983039"> <table:table-cell table:number-columns-repeated="1024" table:style-name="ACE-0x818b2d8"/> </table:table-row> When we open it and save it the second time we are trying to save all those rows one-by-one in odf_write_content_rows. So the problem could as well be in the opening of this file.
When saving the issue lies with: extent = sheet_get_extent (sheet, FALSE); ... style_extent = extent; sheet_style_get_extent (sheet, &style_extent, col_styles); while extent is reasonable: (gdb) p extent $1 = {start = {col = 0, row = 0}, end = {col = 11, row = 2050}} style_extent becomes to large although the common style should be stashed in col_styles: (gdb) p style_extent $2 = {start = {col = 0, row = 0}, end = {col = 1023, row = 1048575}}
This in fact wasn't the problem. We are only calling sheet_style_get_extent to get the col_styles. We incorrectly and unnecessarily tried to handle hidden and collapsed rows separately. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.