GNOME Bugzilla – Bug 733771
Incorrect values in excel_write_DIMENSION
Last modified: 2014-07-27 20:55:32 UTC
According to MS-XLS (section 2.4.90 Dimensions http://msdn.microsoft.com/en-us/library/dd947086.aspx): > rwMac (4 bytes): An unsigned integer that specifies the zero-based index of the row after the last row in the sheet that contains a used cell > colMac (2 bytes): An unsigned integer that specifies the zero-based index of the column after the last column in the sheet that contains a used cell. The code has a few lines like: GSF_LE_SET_GUINT32 (data + 4, esheet->max_row-1); GSF_LE_SET_GUINT16 (data + 10, esheet->max_col-1); GSF_LE_SET_GUINT16 (data + 4, esheet->max_row-1); GSF_LE_SET_GUINT16 (data + 10, esheet->max_col-1); If I understand the sheet structure correctly, shouldn't the actual max_row and max_col values be written?
"rwMac (4 bytes): An unsigned integer that specifies the zero-based index of the row after the last row in the sheet that contains a used cell" seems to be an awful definition. The equivalent: "rwMac (4 bytes): An unsigned integer that specifies the one-based index of the last row in the sheet that contains a used cell" would be much simpler. That does make me wonder whether the documentation is in fact correct...
I tested against Excel 2010 / 2011 / 2013 saving as BIFF8 (Excel 97-2004) and BIFF5 (Excel 5.0/95), and in all six cases the documentation is correct. The wording makes some sense if you think about it in terms of the underlying C code: uint32_t R; for(R = rwMic; R < rwMac; ++R) { ... } Mixing 0-indexed and 1-indexed would be even more confusing
The question to ask is: if we put "x" into a single cell, say B12, and save to xls, do we end up with proper a DIMENSION record? What do we produce? What does Excel produce?
Created attachment 281815 [details] GNUMERIC sample
Created attachment 281816 [details] Excel 2013 sample
I have included two attachments. In both cases, I set the cell A4=x. The Excel sample was generated by excel 2013 and the gnumeric sample was generated by Gnumeric 1.12.17 (the latest version available for windows on the download page) Excel sets rwMac = 4, colMac = 1 (consistent with the spec) but Gnumeric sets rwMac = 3, colMac = 0. This particular problem (single column) is interesting because of another line in the spec: > If this value is 0x00000000, no cells on the sheet are used cells. A strict interpretation of the spec would lead you to conclude that the sheet should be treated as empty (although clearly Excel is robust to this corruption) Related issue: https://github.com/SheetJS/js-xls/issues/47
Ok, we'll drop the -1.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. I am pretty sure Excel ignores this record. We basically do, except for cut and paste in xls format.