As reported on Ask.LO: ----- asked 2012-06-09 02:54:33 +0200 updated 2012-06-09 02:58:18 +0200 Whenever I save LibreOffice documents as .doc, .xls, .docx, .xlsx (these are the only ones I've tried), Microsoft Office 2007/2010 can't open them. They are seen as corrupted document files and I'm asked by MS Office to use its open-and-repair function, which fails nonetheless. In fact, MS Office is able to repair and open .odt and .ods documents, unlike its aforementioned seemingly native formats. If I may, what's the point of being able to "Save as..." if the respective formats can't be read by their native suites (i.e., MS Word, MS Excel etc.)? I'm currently using the latest LibreOffice (v 3.5.3.2) in Ubuntu 12.04 LTS. I've tried this on multiple Ubuntu (11.10/12.04) and Windows (7) computers. Thanks for the help, in advance. ----- Hoping that someone has this particular version of LO *and* a Windows7 machine for testing :-)
Here's the URL for the question: http://ask.libreoffice.org/question/3198/libreoffice-created-doc-xls-docx-xlsx-wont-open/
Hi Qubit. This is annoying indeed. Might it be possible to attach such a corrupt file to see what has been going wrong? Ideally as simple as possible. Without a test file, it might be impossible to guess what's going wrong here.
(In reply to comment #2) > Might it be possible to attach such a > corrupt file to see what has been going wrong? @Sebastian -- Sorry, I don't have an example file that we can use to troubleshoot this problem. I created this bug in response to a question on the Ask.LO site and never got an attached file from the OP. It's been a couple months since the last update from OP, so unless you want to try pinging the user again, I think it's probably fine to mark as No Repro and close it out.
Created attachment 66679 [details] corrupted Excel (new format xlsx) created from original ODS with libreoffice 3.6 latest release FRENCH excel a rencontré un contenu illisible dans ...voulez-vous récupere le contenu de ce dossier.... APRES Correction enregistremnt supprimes : plage nommée dans la partie /xl/workbook.xml(classeur) <?xml version="1.0" encoding="UTF-8" standalone="true"?> -<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><logFileName>error055600_01.xml</logFileName><summary>Des erreurs ont été détectées dans le fichier « \\cbinfo\paul\Les emmerdes de cricri\Bug LibreOffice 3.6 WIN7-FR.xlsx »</summary>-<removedRecords summary="Liste des enregistrements supprimés ci-dessous :"><removedRecord>Enregistrements supprimés: Plage nommée dans la partie /xl/workbook.xml (Classeur)</removedRecord></removedRecords></recoveryLog>
3.6.0.4 (Build ID: 932b512) Checked both on Linux X64 and WIN 7 X64 corrupted xlxs (new office 2010) from export generated. XLS (old office 2007 Format) is OK
Same error still with Release 3.6.1 installed today 10.9.2012 WIN 7 X64
It looks very similar to my bug https://bugs.freedesktop.org/show_bug.cgi?id=50090
Hi, I reproduce this bug in this version (and some of the previous). I attach the file corrupted, and the diagnostic from Excel. I use Spanish language pack.
Created attachment 70758 [details] File generated with LibreOffice 3.6.3, that I cannot open in Excel 2010 File generated with LibreOffice 3.6.3, that I cannot open in Excel 2010
Created attachment 70760 [details] Diagnose / error message when try to open the file in Excel 2010
In my case, it seems it fail whenever I use conditional formats.
xlsx files created in Excel 2010; opened and then saved again in LO 3.6.4 (Windows7 32bit) are corrupted. Will open again in LO or Excel 2010 but loose all sheet tabs in workbook and also loose alpha column headings. Excel 2010 also one workbook shows several graphics boxes created by LO (why???) over some of the cells in the one remaining worksheet. Maybe other data corruption, but these are the most obvious. Easy to reproduce with any .xlsx file. Files created in older .xls in Excel are ok when modified in LO, so problem seems to be in new "compressed" xlsx (docx?) formats.
Hmm... a couple of things we can do to try to squish this bug: 1) Test the bug using LO 4 beta builds. I'm not expecting any miracles, but it's a relatively fast check with big payoffs if it fixes the problem. 2) Track down what, precisely, is changing in these files. There are a couple of XLSX files attached to this bug, but both of them demonstrate LO output. What we need are some small xlsx files saved in Excel, and then re-saved in LO so that we can do a side-by-side diff of the output. 3) Reproduce the attached error message, and include the relevant lines (per the referenced line and column) so that we know what input is causing Excel to choke. My Spanish is pretty weak, so if there's a way to get that error message in English, that would help me better understand the nuances of the archive error. Thanks!
This bug is assigned, without anybody in the ASSIGNED TO. Therefore restore it to NEW. @Qubit: thanks for the catch. Kind regards, Joren
Error still occurs on New LibreOffice R 4.0.3
I've got the same problem with docx-files. I opened a WORD-file (docx-format) in LibreOffice Writer 4.0.4 (dutch). I edited it and saved as a -docx file. But opening the file in Word2010 (dutch) results in an error message. Het Office Open XML-bestand XX kan niet worden geopend omdat er problemen met de inhoud zijn. Details: Ongeldig gekwalificeerd teken voor een naam. Locatie: onderdeel:word/styles.xml, regel: 2, kolom 2603 In English: The Office Open XML file XX can not be opened because there are problems with the contents. Details: Invalid qualified sign for a name. Location: part: word / styles.xml, line 2, column 2603 When I try to recover the document content, it says the file cannot be opened with Microsoft Word. What can be wrong?
A workaround: convert the .docx-file to .doc (e.g. with zamzar.com). After doing that you can open the .doc file in MS WORD without any errors.
Noticed that in Spanish LibreOffice incorrectely confuses the decimal character (in Spanish a comma) with the list separator character causing errors in formulas. This happens when saving the file to .xlsx but not when saving to .xls For example saving a file with this formula: =redondear(F2*1,21;2) (which in English is =round(F2*1.21,2) ) saves as: =redondear(F2*1;21;2) So the decimal character ',' is confused with the list separator character ';' This also happens in 4.1.1.2
The bug is still present in version: (in spanish) Versión: 4.1.2.3 Id. de compilación: 40b2d7fde7e8d2d7bc5a449dc65df4d08a7dd38 It is quite a blocker. I have to juggle with .xls format to share files with coworkers.
I can confirm that any ODS file that was created before LO Version 4.2.0.4 (Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 - Windows Version) has issues and can't be properly exported to MS Office .xlsx format, it will end as a corrupted file. All new ods document created with the current version 4.2.0.4 will be save correctly as a Microsoft Excel 2007/2010/2013 XML (.xlsx.) The document will open correctly in Microsoft Office. As a workaround for ods files that where created before 4.2.0.4 that can't be exported you will need to copy the content to a new file. You can easily accomplish this by right clicking the sheet in the affected document select Move/Copy.. sheet from the content menu then selecting Copy in the dialog box and new document in the Location Combo Box. The new file generated can be save as a ODS file that can export properly to MS Excel 2007/2010 format.
(In reply to comment #21) > I can confirm that any ODS file that was created before LO Version 4.2.0.4 > (Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 - Windows Version) has > issues and can't be properly exported to MS Office .xlsx format, it will end > as a corrupted file. When you say 'corrupted file', do you mean that the file will not open with any program (i.e. neither MS-Office nor LibreOffice), or just that the file will not open with MS-Office?
Created attachment 97364 [details] LibreOffice-generated .docx that freezes my MS Office 2010 I have just got a file generated by LibreOffice/4.2.2.1 on Linux which completely freezes my MS Office 2010 on Windows 7 to the point that the process has to be manually killed. Attached.
Can someone please attach a ods file that when saved as xls and/or xlsx it causes problems with Microsoft Office? This bug is really cluttered with lots of "me too" but not a lot of information that helps us diagnose the problem. I am setting to NEEDINFO - what we need: 1. An ods file (yes ods, not xlsx) that when saved as xls/xlsx it causes problems in Excel 2. Also please test with 4.4.3 or newer (Version 5 would be fine) Once these steps are taken - please set the bug back to NEW and I'll see what I can do in terms of triaging it fully.
I can confirm that this bug has been resolved with version 4.4.0.3. The version that I can confirm this bug occurs is version 4.2.8. A corrupt XLSX saved by 4.2.8, open that in 4.4.0.3 and re-save, will fix the problem. Note that both LO 4.2.8 and 4.4.0.3 can read those corrupt files without issue. However, 4.2.8 saved them in a way that's unreadable by native MSOffice. There are already sample corrupt files in this bug report's attachments. As additional info, the corrupt files are also unreadable by R's read.xlsx function. Some data scientists might be confused by this behavior and think it's R's fault while it's actually LO's fault.
Closing as WFM then as 4.2 is end of life (not receiving any additional patches) and last comment says it's fixed in 4.4. Thanks!
Unfortunately Ubuntu 14.04 LTS is still using the end-of-lived 4.2.8 :(
For Ubuntu users, check out https://launchpad.net/~libreoffice/+archive/ubuntu/ppa
I spoke too soon. Even 4.4.4.3 still exhibits this problem, however it requires a more complex, multi-thousand rows (16000 did it in my case) to trigger the problem. v4.4.4.3's corruption exhibits this behavior: 1. After saving a problematic workbook as XLSX, reopening the file in LO 4.4.4.3 will seem as there's no problem. But several cells in the workbook are *emptied silently* ! No warnings. This is a very destructive and dangerous behavior, because can result in (unknowingly) data-loss. 2. After saving a problematic workbook as XLSX, opening the file in Excel 2013 will trigger a warning: "We found a problem with some content in 'application_2015-07-10.xlsx'. Do you want us to try to recover as much as we can? If you trust the source of this workbook, click Yes." After clicking Yes, Excel will display the file and lots of cells are emptied. The diagnostics messages from Excel 2013 are as follows: Removed Part: /xl/sharedStrings.xml part with XML error. (Strings) Illegal xml character. Line 2, column 113479. Removed Records: Cell information from /xl/worksheets/sheet1.xml part The XML log is: (same info as human-readable messages above) <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><logFileName>error011640_01.xml</logFileName><summary>Errors were detected in file 'D:\Downloads\ppdb\applicant_2015-07-10.xlsx'</summary><removedParts summary="Following is a list of removed parts:"><removedPart>Removed Part: /xl/sharedStrings.xml part with XML error. (Strings) Illegal xml character. Line 2, column 113479.</removedPart></removedParts><removedRecords summary="Following is a list of removed records:"><removedRecord>Removed Records: Cell information from /xl/worksheets/sheet1.xml part</removedRecord></removedRecords></recoveryLog> Unfortunately my 16000 row file is private, so will need another test case for v4.4.4.3.
Please attach the document - we need a test case that we can test. Marking as NEEDINFO - once you attach set to UNCONFIRMED - NOT REOPENED. Thanks
As Comment 25 says, the original issues have been resolved. I suggest this be closed as WFM. I propose that Hendy - or another reported - open a new bug with a (anonymized) test case.
(In reply to Timur from comment #31) > As Comment 25 says, the original issues have been resolved. I suggest this > be closed as WFM. > I propose that Hendy - or another reported - open a new bug with a > (anonymized) test case. Sounds plausible... (In reply to Hendy Irawan from comment #29) > I spoke too soon. Even 4.4.4.3 still exhibits this problem, however it > requires a more complex, multi-thousand rows (16000 did it in my case) to > trigger the problem. ...the question is: Does the new document exhibit the same problem? (If not, then the devs will definitely appreciate us creating a new bug and just adding a mention of this bug in the new report)
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Sat, 10 Sep 2016 16:48:27 +0200
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20161010