Bug 115034 - Unsupported file format for older gnumeric file
Unsupported file format for older gnumeric file
Product: Fedora
Classification: Fedora
Component: gnumeric (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Caolan McNamara
Depends On:
  Show dependency treegraph
Reported: 2004-02-05 12:50 EST by Tethys
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: FC3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-28 10:27:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
File as produced by gnumeric under RH9 (12.52 KB, application/octet-stream)
2004-04-29 18:59 EDT, Tethys
no flags Details
File to which I manually added a UTF-8 encoding (12.53 KB, application/octet-stream)
2004-04-29 19:00 EDT, Tethys
no flags Details

  None (edit)
Description Tethys 2004-02-05 12:50:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Description of problem:
I do my company accounts with gnumeric, and have done for a few
years. After upgrading to FC1 (from RH9), however, it gives me
an error when I try and open my accounts spreadsheet, claiming
"Unsupported file format".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open my company accounts with gnumeric

Actual Results:  Error dialog box

Expected Results:  Spreadsheet opens

Additional info:

This one's a bit odd. Comparing the file to one produced by the
gnumeric shipped with FC1, I noticed that the new file has an


attribute in the initial xml tag where the old one doesn't. Sure
enough, manually editing it, and adding the attribute fixes the
problem, and it can now be opened. So far so good. But I tried to
duplicate the problem, by creating a spreadsheet with an old version
of gnumeric (gnumeric-0.67-10, from an RH7.3 box -- I no longer have
an RH9 box to test with). Sure enough, it writes the file without any
character encoding, yet gnumeric on FC1 can read it without problems.
So I went back and tried to open my company accounts with the old
version of gnumeric, only to get the same unsupported file format
error. Bizarre.

So what the actual cause is, I don't know. Perhaps vim corrected some
line endings problem, or modified a control character somewhere when
I edited it (although how would they have got there in the first
place?) Who knows.

I've marked this as high, because even though it's apparently not
easy to reproduce, it has the potential to lose a lot of important
data -- the reason I switched to gnumeric (from Wingz) was the fact
that it was an open file format, so I wouldn't risk losing access
to my old data!
Comment 1 Caolan McNamara 2004-04-29 17:54:35 EDT
Well on the bright side, when things did go wrong you were able to
edit the open format and fix the problem manually which would have
been a total crisis with Wingz :-)

I can't reproduce this myself with gnumeric-1.2.8 as in Fedora Core 2.
I tried with and without the xml identifier, and with and without
substituting dos line ends for unix line ends. And gnumeric handles
all these cases. So if that was the problem, then gnumeric-1.2.8 has
the situation resolved. If not I don't see how I can do it without an
example document, if you have such a document feel free to attach it
here (admitedly I understand you don't want to attach your company
accounts) and re-open it and we'll have some information to with...
Comment 2 Tethys 2004-04-29 18:58:33 EDT
I've stripped out the data, to leave a set of nearly blank sheets
that still exhibit the problem. Admittedly, I haven't upgraded to
FC2 yet, so I'm still on gnumeric-1.2.1.

Attached are two files. One without the encoding (as produced by
gnumeric under RH9) that gnumeric is unable to load. The other one
I've manually added the encoding to, and it opens fine.
Comment 3 Tethys 2004-04-29 18:59:32 EDT
Created attachment 99809 [details]
File as produced by gnumeric under RH9
Comment 4 Tethys 2004-04-29 19:00:35 EDT
Created attachment 99810 [details]
File to which I manually added a UTF-8 encoding
Comment 5 Caolan McNamara 2004-07-28 10:27:54 EDT
I've just pushed gnumeric 1.2.13 for FC3, in that version at least
such files missing their encodings are converted from the "locale"
encoding to correct UTF-8 on load. So this is resolvable in that
version assuming that the locale in which the document was created is
the same (or close enough) to that in which it is converted from old
to new.

If you have problems (i.e. your current locale is not the same as the
original locale) you can try running the new gnumeric from a shell where 
LANG is unset using
unset LANG
as thats a likely setting for the original documents if the case is
that the defaults don't work out of the box for converting them (this
is hopefully unnessary, though I had to do it as my locale is
en_IE.UTF-8, so the old document missing the charset was assumed to be
this locale, which it was not). Its worth trying this in your current
older version as well. 

The heuristic to assume that a document without an encoding is encoded
in the current locales encoding is as good as is possible given that
the info is missing from the older document and gnumeric needs to
guess it somehow

Note You need to log in before you can comment on or make changes to this bug.