GNOME Bugzilla – Bug 304480
Loading of xls extention file with html content not imported "correctly"
Last modified: 2005-08-15 08:49:51 UTC
Version details: 1.4.2 - ubuntu Distribution/Version: ubuntu - hoary Create a html table of data in a file, or save an excel file as html. rename to .xls. load into gnumeric. The data is simply loaded as text. In other spreadsheets (Excel, OO.o) this is interpreted as spreadsheet data (a better version of CSV), and even functions (i.e. =A1*100) in HTML table cells are used correctly, and html formatting (<b> <i> <u>) are used. This would be the correct interpretation of this file type, as many web development scripts use this method to export data to Excel, and gnumeric should likely do the same. It's one reason I can't use gnumeric over OO.o, which I'd like to drop sometime soon!
Created attachment 46533 [details] Sample file for testing Have attached a file which is referred to to help reproducing this case.
The attached file is not a valid html file. It looks like a text file that happens to use tags that resemble html table tags.
I should have pointed out that the html importer will load that file just fine. (Select the html file type before clicking okay!) I assume you would like gnumeric to automatically recognize this as html. Since it does not have an html or htm extension and the content is not valid html either, I really don't think that that would make sense. (The file contains "<table" so lets guess that it may be broken html...)
The html importer goes to great efforts to make sense of incomplete html we receive on the clipboard. So I think we should try to handle this as well. As we do, when the extension is html In order to do the right thing when the file doesn't have the extension "html", we'd have to add probing to the html importer. Currently, it doesn't probe. The trick is to avoid intrdoducing false positives.
Created attachment 49187 [details] [review] Patch to add html probing OK. Here's a patch. Not sure we want to apply it. The problem with probing (sniffing) is that it will sometimes be wrong. And the user has to fix the probing function to get around the problem. Without probing, all she has to do is rename the file.
Can I suggest that the reason why this is worth probing is that many web-based system do export of data to an "XLS" file, which is really this html table data with an XLS extension. PhpMyAdmin is an example of this, but there are many less technical examples. Most libraries for export use this mechanism. This means that gnumeric can not be used to automatically open the file when it is downloaded, as this isn't opened correctly. To have to introduce 2 extra steps (save as.., rename, load in gnumeric), means you loose that ease of use which MS Excel provides. This is the sort of action that none-technical users will want to have, and could well be a barrier for adoption of gnumeric because it would appear that these "XLS" files are not compatible with it, when they are.
There is a new report on this: 311879. I've summarized the issues under the new report, and labeling this one a duplicat. This way, we can focus on the issue, not the arguing. *** This bug has been marked as a duplicate of 311879 ***