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 128524 - gnumeric produces .xls files that cannot be opened by the french version of XL
gnumeric produces .xls files that cannot be opened by the french version of XL
Status: VERIFIED INCOMPLETE
Product: Gnumeric
Classification: Applications
Component: import/export MS Excel (tm)
1.2.x
Other Linux
: Normal major
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 127210 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-12-04 15:57 UTC by Frederic Parrenin
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The xls file created by gnumeric and showing the problem (6.50 KB, application/msexcel)
2003-12-04 15:58 UTC, Frederic Parrenin
  Details
The .xls file when it is repaired by XL-XP (13.50 KB, application/msexcel)
2003-12-14 11:16 UTC, Frederic Parrenin
  Details
Creates an SST receord even when there are no strings (1.54 KB, patch)
2003-12-24 17:14 UTC, Jody Goldberg
none Details | Review
new version of the original sample generated with the patch (8.00 KB, application/octet-stream)
2003-12-24 20:18 UTC, Jody Goldberg
  Details
fix placement and content of country record in biff8 (16.00 KB, application/octet-stream)
2003-12-24 21:30 UTC, Jody Goldberg
  Details
The patch that produced the working file (against 1.2.3) (3.17 KB, patch)
2003-12-25 03:30 UTC, Jody Goldberg
none Details | Review

Description Frederic Parrenin 2003-12-04 15:57:59 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.
Comment 1 Frederic Parrenin 2003-12-04 15:58:49 UTC
Created attachment 22094 [details]
The xls file created by gnumeric and showing the problem
Comment 2 Jody Goldberg 2003-12-14 05:29:47 UTC
that file opens smoothly for me with 2k, and XP.
Are you sure its the right example ?
Comment 3 Frederic Parrenin 2003-12-14 11:13:12 UTC
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 ?
Comment 4 Frederic Parrenin 2003-12-14 11:16:05 UTC
Created attachment 22428 [details]
The .xls file when it is repaired by XL-XP
Comment 5 Jody Goldberg 2003-12-15 06:45:49 UTC
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.
Comment 6 Frederic Parrenin 2003-12-15 11:16:26 UTC
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
Comment 7 Morten Welinder 2003-12-15 17:38:19 UTC
I am untable to reproduce this.

Could you have a look in File->Properties and see if anything listed
there is not ASCII?
Comment 8 Jody Goldberg 2003-12-15 18:15:44 UTC
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.
Comment 9 Frederic Parrenin 2003-12-15 18:22:05 UTC
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.
Comment 10 Jody Goldberg 2003-12-15 18:34:44 UTC
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
Comment 11 Frederic Parrenin 2003-12-15 19:35:44 UTC
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.
Comment 12 Jody Goldberg 2003-12-22 03:50:42 UTC
If you select an english locale under windows does the workbook load ?
If so, how did you select an english locale ?
Comment 13 Frederic Parrenin 2003-12-24 09:52:21 UTC
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.
Comment 14 Jody Goldberg 2003-12-24 17:14:45 UTC
Created attachment 22691 [details] [review]
Creates an SST receord even when there are no strings
Comment 15 Jody Goldberg 2003-12-24 17:16:01 UTC
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.
Comment 16 Carlos Perelló Marín 2003-12-24 20:15:53 UTC
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.
Comment 17 Jody Goldberg 2003-12-24 20:18:32 UTC
Created attachment 22693 [details]
new version of the original sample generated with the patch
Comment 18 Carlos Perelló Marín 2003-12-24 20:50:12 UTC
Same error
Comment 19 Jody Goldberg 2003-12-24 21:30:27 UTC
Created attachment 22695 [details]
fix placement and content of country record in biff8
Comment 20 Carlos Perelló Marín 2003-12-24 21:53:23 UTC
This one works here
Comment 21 Jody Goldberg 2003-12-25 03:30:10 UTC
Created attachment 22702 [details] [review]
The patch that produced the working file (against 1.2.3)
Comment 22 Jody Goldberg 2003-12-25 03:30:56 UTC
If you can confirm this works, I'll skip announcing 1.2.3, and release 1.2.4 with this patch instead.
Comment 23 Frederic Parrenin 2003-12-30 11:24:34 UTC
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.
Comment 24 Morten Welinder 2004-01-02 20:36:47 UTC
Fixed in cvs and in 1.2.4.
Comment 25 Frederic Parrenin 2004-02-25 11:10:21 UTC
*** Bug 127210 has been marked as a duplicate of this bug. ***