GNOME Bugzilla – Bug 661958
To save as an Excel 2007 Format(xlsx) file, Gnumeric always loses respondence.
Last modified: 2011-10-18 02:22:30 UTC
1. open gnumeric main application; 2. create a new blank file with 1048576 rows and 16384 columns; 3. goto the last range ("XFD1048576"), input something , like a character "A", and then save it as an Excel 2007 Format(xlsx) file, named "Book1.xlsx"; 4. gnumeric will lose respondence at once. If we operate in Microsoft Excel 2007 Pro or 2010 Pro Plus, this process gos well and quickly, Excel never loses respondence. I almost know this won't be a BUG, but I think it must be a problem needed fixxed. In total, gnumeric is an excellent application, especially free and open.
Would you be able to attach the file Microsoft Excel 2007 Pro or 2010 Pro Plus creates? And I would definitely consider this a bug.
Hmm, in excel_sheet_extent we are calling sheet_get_extent (sheet, FALSE); which sets extent falsely to (gdb) p *extent $3 = {start = {col = 0, row = 0}, end = {col = 16383, row = 1048575}} so we end up writing lots of (empty) rows and columns. (Note that this affects not only saving too xlsx but probably also many other exporters using sheet_get_extent.)
Hmm, in sheet_get_extent we have: closure.range.start.col = gnm_sheet_get_max_cols (sheet) - 2; closure.range.start.row = gnm_sheet_get_max_rows (sheet) - 2; closure.range.end.col = 0; closure.range.end.row = 0; then we decrease the start and increase the end as we see content. THis behaves correctly and we end up with (gdb) p closure.range $2 = {start = {col = 16382, row = 1048574}, end = {col = 16383, row = 1048575}} but then we have if (closure.range.start.col >= gnm_sheet_get_max_cols (sheet) - 2) closure.range.start.col = 0; if (closure.range.start.row >= gnm_sheet_get_max_rows (sheet) - 2) closure.range.start.row = 0; if (closure.range.end.col < 0) closure.range.end.col = 0; if (closure.range.end.row < 0) closure.range.end.row = 0; In the given case, teh first two tests re true and so we change teh extent. Why???
Note that the analysis above shows that if you add content in, say XFB1048574, then saving as an xlsx file is virtually instantaneous.
I have fixed the sheet_get_extent. Note that the problem was also triggered on a print-preview of the above described file. There are still two issues: 1) We really should not be using sheet_get_extent since it only considers visible content, ie. invisible content may not be exported to xlsx if it is outside the visible content range. 2) A file with content in only A1 and XFD1048576 still takes (close to) forever to be exported. (How long does Excel take to export this?)
Issue 1 of comment #5 is fixed. To address issue 2 I first need to see the file Excel is generating in this case.
Issue 2 is bug #662058. *** This bug has been marked as a duplicate of bug 662058 ***