Red Hat Bugzilla – Bug 115034
Unsupported file format for older gnumeric file
Last modified: 2007-11-30 17:10:36 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):
Steps to Reproduce:
1. Open my company accounts with gnumeric
Actual Results: Error dialog box
Expected Results: Spreadsheet opens
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
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!
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...
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.
Created attachment 99809 [details]
File as produced by gnumeric under RH9
Created attachment 99810 [details]
File to which I manually added a UTF-8 encoding
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
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
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