After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 661958 - To save as an Excel 2007 Format(xlsx) file, Gnumeric always loses respondence.
To save as an Excel 2007 Format(xlsx) file, Gnumeric always loses respondence.
Status: RESOLVED DUPLICATE of bug 662058
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
1.10.x
Other All
: Normal normal
: ---
Assigned To: Andreas J. Guelzow
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-10-17 02:51 UTC by wharfzhang
Modified: 2011-10-18 02:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description wharfzhang 2011-10-17 02:51:27 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.
Comment 1 Andreas J. Guelzow 2011-10-17 03:33:21 UTC
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.
Comment 2 Andreas J. Guelzow 2011-10-17 04:08:16 UTC
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.)
Comment 3 Andreas J. Guelzow 2011-10-17 04:13:47 UTC
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???
Comment 4 Andreas J. Guelzow 2011-10-17 04:19:13 UTC
Note that the analysis above shows that if you add content in, say XFB1048574, then saving as an xlsx file is virtually instantaneous.
Comment 5 Andreas J. Guelzow 2011-10-17 14:50:36 UTC
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?)
Comment 6 Andreas J. Guelzow 2011-10-17 20:04:46 UTC
Issue 1 of comment #5 is fixed. To address issue 2 I first need to see the file Excel is generating in this case.
Comment 7 Andreas J. Guelzow 2011-10-18 02:22:30 UTC
Issue 2 is bug #662058.

*** This bug has been marked as a duplicate of bug 662058 ***