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): gnumeric-1.2.1-1 How reproducible: Sometimes Steps to Reproduce: 1. Open my company accounts with gnumeric 2. 3. 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 encoding="UTF-8" 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!
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 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