Created attachment 83566 [details] html file with a table with xls extension I used version 3.5.7 on my mac (and Ubuntu 12.04) and i could open the attached XLS file just fine. Its an html file with a table inside which has the extension xls. This versions shows a regular table inside Calc. After an update on version 4.1.0, i get an "general read output error" when trying to open the same. Sure, this is not a valid xls file, but still this looks like a bug/regression to me. LibreOffice should at least handle the file like an html file if it doesnt want to make the convert step anymore.
Reproducible with LO 4.1.0.3 under Win7x64. Not reproducible with LO 4.1.0.2 (it opens the test file in Writer). To reproduce, the html file must have extension .xls Most probably related to Bug 67617.
*** Bug 68269 has been marked as a duplicate of this bug. ***
This now seems to happen with any file that has the extension .xls but has HTML content. @Kohei: In SfxBaseModel::load() the resulting filter name in aFilterName is "calc8_template" (?? how that?) and then in SfxMedium::GetStorage() the pImp->xStorage = ... fails in OStorageFactory::createInstanceWithArguments() because StorageFormat is ZipFormat and after CheckPackageSignature_Impl() fails io::IOException() is thrown.
Similar as mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=67617#c3 this error is triggered by d1fc3fce16172d7d619b6826de44528030ab36f8 fdo#64448: Don't get type name from incorrect filter. However, reverting that the here attached file opens in Writer instead of Calc.
Created attachment 84272 [details] another .xls testcase with only a <table> fragment that opens differently BUT, reverting d1fc3fce16172d7d619b6826de44528030ab36f8 makes this file, containing only a <table>, open fine in Calc.
As there are piles of generated HTML files with .xls extension in the wild I'd rather revert http://cgit.freedesktop.org/libreoffice/core/commit/?id=d1fc3fce16172d7d619b6826de44528030ab36f8 http://cgit.freedesktop.org/libreoffice/core/commit/?id=fa965d8b1743d786ea07d887f883ab9af9b6652e&h=libreoffice-4-1 also for 4-1-1, and reopen bug 64448 for the corner case of a file without extension instead.
ok.. talked to Kohei and reverting is a bad option.
I have a fix for this, but this is a major change. And you know as well as I do that every major change runs the risk of introducing regressions... Having said that, what I did was essentially to remove all the previously accumulated hacks, which made this detection code so hard to debug and maintain. So, even if my change introduces another brand-new problem, it will be much easier to debug. So, IMO it's worth the risk.
I'll take it.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e69aa9572bb2206313cd2aa7edd13da91460f2c4 fdo#67699: Remove a whole bunch of old hacks. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Backport request for 4.1 on gerrit: https://gerrit.libreoffice.org/#/c/5518/
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=904ef99d87af1bfefe43f6a84f04f019bd082754 fdo#67699: Don't forget to set filter name to the descriptor. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac9cee0d909ba580a4128f34b675e9f58794ea97&h=libreoffice-4-1 fdo#67699: Remove a whole bunch of old hacks. It will be available in LibreOffice 4.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Please merge this too. https://gerrit.libreoffice.org/#/c/5520/
fixed.
*** Bug 67617 has been marked as a duplicate of this bug. ***
*** Bug 68837 has been marked as a duplicate of this bug. ***
*** Bug 67902 has been marked as a duplicate of this bug. ***
*** Bug 68941 has been marked as a duplicate of this bug. ***
*** Bug 69032 has been marked as a duplicate of this bug. ***
*** Bug 68826 has been marked as a duplicate of this bug. ***
*** Bug 69163 has been marked as a duplicate of this bug. ***
Just to mention a workaround until 4.1.2 is out: You could rename the file to .html extension and in the file open dialog explicitly select the "HTML Document (Calc)" file type somewhere in the middle of that list after the Microsoft Excel types. Note that if you don't select the file type an attempt is made to open the file in Writer instead.
Created attachment 85546 [details] Result open file like html Calc
Hello, i tried open like you suggested me. But LO Calc opens it like xml code. See attach "Result open file like html Calc" (In reply to comment #23) > Just to mention a workaround until 4.1.2 is out: > > You could rename the file to .html extension and in the file open dialog > explicitly select the "HTML Document (Calc)" file type somewhere in the > middle of that list after the Microsoft Excel types. Note that if you don't > select the file type an attempt is made to open the file in Writer instead. (In reply to comment #23) > Just to mention a workaround until 4.1.2 is out: > > You could rename the file to .html extension and in the file open dialog > explicitly select the "HTML Document (Calc)" file type somewhere in the > middle of that list after the Microsoft Excel types. Note that if you don't > select the file type an attempt is made to open the file in Writer instead.
Then that file is not an HTML but an XML file and of course opening it explicitly as HTML does not produce the results you expect.
*** Bug 69263 has been marked as a duplicate of this bug. ***
*** Bug 69677 has been marked as a duplicate of this bug. ***
*** Bug 69031 has been marked as a duplicate of this bug. ***
*** Bug 67478 has been marked as a duplicate of this bug. ***
*** Bug 61546 has been marked as a duplicate of this bug. ***
*** Bug 65980 has been marked as a duplicate of this bug. ***