Description: I need to process a .xls (2003) generated document but librecalc is not able to open it. This must be fixed and regarded as a major flaw. The only work-around I have found is to open it in microsoft excel and save it as a .xlsx (2007). In excel I get a question if I would like to open it and when I press Open, no problems. I have installed libreoffice 25.2.x on a windows 10 client. I suspect the serious limitation affects any platform where libreoffice us installed. Steps to Reproduce: 1. Unzip attached document using say winrar or winzip 2. Start librecalc and open the .xls file 3. Shows a blanc document (empty cells) and no other import format options.... Actual Results: 1. unzips the attachment 2. 3. Shows a blanc document (empty cells) and no other options.... (a fault) Expected Results: Expected to show content of document of course Reproducible: Always User Profile Reset: No Additional Info: General problem...
Created attachment 199717 [details] Unzip and open the attached .xls file I am not able to view/edit this file and not save as a .xlsx (2007) as I want to
Created attachment 199718 [details] The same file saved as .xlsx in microsoft excel This is the workaround and hence I am forced to have microsoft excel installed. Must be fixed
1. This is not an XLS, it's an XML (MS Excel 2003 XML) format. Trying to open the file in MS Excel already gives a warning about extension-to-content mismatch. Given this file format, which is used very rarely, and is a failed experiment of MS (intermediate between XLS and OOXML) that they abandoned immediately, this is not "a major flaw" nor "serious limitation" by any measure. 2. I repro the lack of content, using Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: ru-RU (en_US); UI: en-GB Calc: CL threaded
This XML document is INVALID: all "&" characters in cells in it aren't properly XML-encoded (they all must be in the entity form "&" - but they are used there as plain "&"). That Excel tolerates this invalid document is not an appealing reason for Calc to do the same. The proper fix is to find the broken *generating* software (I doubt that it was Excel itself), and fix it. Also, there doesn't seem to be any sizeable amount of such invalid documents in the wild - this seems to be the first report about this problem ever (is it created using some new library, or even using some home-made exporter? If so, that definitely needs a proper fix on the generating side). See also bug 68742 and bug 150023, where we eventually fixed reading some much less severe invalid XML.