GNOME Bugzilla – Bug 128524
gnumeric produces .xls files that cannot be opened by the french version of XL
Last modified: 2009-08-15 18:40:50 UTC
step to reproduce the bug: - open a new sheet - enter numbers in several cells - save as xls file - try to open the file with XL => XL crahes ! I have verified this bug on two different boxes with XL2k and XL-XP. I will provide such an example XLS file. On the same windows box, OOo-1.1 is able to open this file.
Created attachment 22094 [details] The xls file created by gnumeric and showing the problem
that file opens smoothly for me with 2k, and XP. Are you sure its the right example ?
Sorry, but I confirm this bug a another box using WinXP and XL-XP. Perhaps it is linked to my french locale (I use WinXP french and XL-XP french). When opened with XL-XP, XL closes two times, and finally it is able to repair the file. I will attach this repaired file. Perhaps you could compare it with the original file produced by gnumeric to deduce the problem ?
Created attachment 22428 [details] The .xls file when it is repaired by XL-XP
I'll take a shot in the dark. Try editing plugins/excel/ms-excel-write.c:excel_write_WRITEACCESS Change the call to g_locale_to_utf8 (g_get_real_name () ...) into g_strdup ("FOO"); Then resave things. Lets see if it just doesn't like multibyte characters in that record.
This excel bug is really strange. XL was able to read this test file two times this morning, and now it is not able anymore. I have tried your patch. I don't know if I have understood correctly. I have change line 3971 : gchar *utf8_name = g_locale_to_utf8 (g_get_real_name (), -1, NULL, NULL, NULL); by: gchar *utf8_name = g_strdup ("FOO"); It does not help: the bug is still there. When opening this test file by XL2k, I obtain the following error message (sorry, it is in french...): EXCEL a causé une défaillance de page dans le module <inconnu> à 0084:00199601. Registres : EAX=0062fe28 CS=0177 EIP=00199601 EFLGS=00016246 EBX=0062fe28 SS=017f ESP=00530034 EBP=00530054 ECX=005300d8 DS=017f ESI=81583a48 FS=2b57 EDX=9ff76855 ES=017f EDI=00530100 GS=0000 Octets à CS : EIP : État de la pile : 9ff76849 00530100 0062fe28 0053011c 005300d8 0053020c 9ff76855 0062fe28 005300e8 9ff87fe9 00530100 0062fe28 0053011c 005300d8 00199601 005302c4 I don't know if it helps you. Another indication: saving in XL-95 file format, I have no problem to read the file. Thanks for your help. Frédéric
I am untable to reproduce this. Could you have a look in File->Properties and see if anything listed there is not ASCII?
So much for that guess. I'd hoped it was something as simple as XL not liking unicode in that record. I'd like some confirmation that its locale related. Can you trying moving temporarilly into the stock US english domain on a windows test machine ? Also jsut as a safe guard. Please double check that the file which crashes XL is the attached file.
I have check that all in File->Properties is in ASCII. The problem does not come from here. I have verified that the problem occurs only with the french version of XL/Windows. On an english version, it does not show. I have also made another interesting test. When creating a simple xls file with all cells being empty, XL can open it. But if a enter a simple number in one cell, e.g. "1" in A1, XL cannot open the file. It is perhaps an excel bug. But it is a serious problem because it means that you cannot send xls files produced by gnumeric to (at least) french people using XL.
Hmm, this gets us closer. 1) It's specific to XL in french (Please give details of exactly how you set french in windows there are several knobs) 2) It is XL97 specific 3) It requires some data, not necessarily strings 4) It is not part of the document metadata or the WRITEACCESS record
I think I have found useful information on this strange bug ! Several cases: 1) all cells are empty => OK 2) cell A1 contain "A" => OK (same with cell A2 or A3) 3) cell A1 contain "1" => not OK (same with cell A2 or A3) 4) cell A1 contain "A" and cell A3 contain "1" => OK 5) etc. The problem seems to occur only when there are only numeric content in the cells and no text content. If a file shows the problems, as soon as I add a text in a cell somewhere, the problem disappears. Concerning my french settings, what do you mean by "there are several knobs" ? I have not really seted the language to french, but used the default settings of my install from a french CD of Windows/Office. I have tried to set the settings to US, but the problem still happens.
If you select an english locale under windows does the workbook load ? If so, how did you select an english locale ?
No, I have tried to choose american in the "regional parameters" in windows 98, but it did not change anything. BTW, I have found another way to produce this bug. If a workbook can be loaded by XL french, and if I add a "freezed pane" in this workbook, it cannot be loaded anymore.
Created attachment 22691 [details] [review] Creates an SST receord even when there are no strings
I'll take another stab in the dark and guess that it is related to there being no strings. It looks like XL always generates the string table record even if there are no strings. See if this helps. Please file the frozen pane seperately and in more detail.
Hope this helps: The first .xls file breaks Excel 97 (Spanish version) The second .xls file works without problems It's a Windows 98 system with Microsoft Office 97, both Spanish versions.
Created attachment 22693 [details] new version of the original sample generated with the patch
Same error
Created attachment 22695 [details] fix placement and content of country record in biff8
This one works here
Created attachment 22702 [details] [review] The patch that produced the working file (against 1.2.3)
If you can confirm this works, I'll skip announcing 1.2.3, and release 1.2.4 with this patch instead.
Same conclusion than Carlos for me: the file that you sent 2003-12-24 15:18 does not work, but the next one that you sent 2003-12-24 16:30 does work. I will test in more details version 1.2.4 next week when I will have a normal internet connexion.
Fixed in cvs and in 1.2.4.
*** Bug 127210 has been marked as a duplicate of this bug. ***