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 127734 - bad import of this .slk file: change of cell position
bad import of this .slk file: change of cell position
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2003-11-23 15:25 UTC by Frederic Parrenin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The .slk file showing the problem (6.01 KB, text/spreadsheet)
2003-11-23 15:27 UTC, Frederic Parrenin
Details
How the .slk file looks like for me in gnumeric (after scrolling down the window) (44.66 KB, image/png)
2003-12-16 09:19 UTC, Frederic Parrenin
Details

Description Frederic Parrenin 2003-11-23 15:25:07 UTC
When importing the .slk file I will attach, the line number 101 is strange:
-C101 has gone to A101
-A101 does not exist anymore
(with respect to an import of the same file in XL2k)
Comment 1 Frederic Parrenin 2003-11-23 15:27:01 UTC
Created attachment 21720 [details]
The .slk file showing the problem
Comment 2 Jody Goldberg 2003-12-16 08:06:55 UTC
Content appears in the expected places for me.
What locale are you doing this in ?
Can you try 'C' to see if that changes anything ?
Comment 3 Frederic Parrenin 2003-12-16 09:18:45 UTC
I am using french env variables(LC_NUMERIC,LANG,LANGUAGE, ...)
Does that answer your question ?
How do you set the locale to 'C' ?

Are you sure content is in the expected places for you ?
What is the content of cell A101 ?
If it is -81.16, the import is wrong (-81.16 should be the content of
cell C101).
I will attach a screenshot showing how it looks like for me.
Comment 4 Frederic Parrenin 2003-12-16 09:19:39 UTC
Created attachment 22479 [details]
How the .slk file looks like for me in gnumeric (after scrolling down the window)
Comment 5 Jody Goldberg 2003-12-17 02:10:20 UTC
I can't replicate that.
Althouggh autosizing of columns does seem to have some problems which
I'll look at.

what is the exact setting for LC_ALL that you use ?
I tried LC_ALL fr_FR and things looked fine.
Comment 6 Frederic Parrenin 2003-12-17 09:05:33 UTC
Very strange.

The output of 'env' command line has no LC_ALL setting for me by default.
There are:
LC_PAPER, LC_ADDRESS, LC_MONETARY, LC_NUMERIC, LC_TELEPHONE,
LC_MESSAGES, LC_IDENTIFICATION, LC_COLLATE, LC_MEASUREMENT, LC_CTYPE,
LC_TIME, LC_NAME,
all are =fr_FR, but there is no LC_ALL.
I have tried with LC_ALL=en_US, but it does not change the problem.

I suspect this problem to come from a character coding issue. Mandrake
has a strange way to code "." I had a similar bug with OpenOffice.
Perhaps I could ask gnumeric packager (Frederic Crozat) to look at
this issue.

BTW, the column sizing issue was reported to bug 127736.
Comment 7 Frederic Parrenin 2003-12-17 09:25:06 UTC
Another information on this bug:

A) It seems it happens only if the number of the line is greater or
equal to 100. 
If I open the file in excel, suppress several lines until the
non-empty lines are <100, and save the file, it opens without problem
in gnumeric.
If I do the same but in adding new lines instead of suppressing them,
the problem still shows.

B) It is related to the decimal separator of the number "-81.16" If I
manually edit the file, supress ".16", and save the file, the problem
disappears. If I re-edit the file, re-add ".16" and save the file, the
problem re-shows.
Comment 8 Jody Goldberg 2003-12-18 00:38:20 UTC
Grief.  This was a much larger issue than expected.  It was actually a memory
overrun problem that happended to require a different decimal seperator.  I've
ended up basicly rewriting the sylk importer to use some of the more modern
features in gnumeric.
Comment 9 Frederic Parrenin 2003-12-18 09:01:21 UTC
Re-opening bug to mark it as fixed.
Comment 10 Frederic Parrenin 2003-12-18 09:02:08 UTC
Marking this bug as fixed.