Open attachment https://bugs.documentfoundation.org/attachment.cgi?id=144104 "Demo-Hayden-Management-minimum.docx" from bug 81522. Save a copy of the file to docx format. Open the saved file in Word. Error: Word finds content that it cannot read and is not able to open the file. I see the error in master from 8.Jul, it was OK with a build 3 days ago. Good at least till 72541a46aa26194b751785cd56185c8d3db0c9e9 Broken likely in or before 7e7a871bcd4f923b015a7e040969335696b434c6 The problem is in part word/charts/chart1.xml. At end of the file is an element c:externalData. That should not be there.
For the record, I can't open the original DOCX in Word 2013, either.
I can't open the attachment 144104 [details] in my Word 2019 either. docProps/app.xml says <Application>LibreOfficeDev/6.2.0.0.alpha0$Linux_X86_64 LibreOffice_project/d977e02ec6350115c39f03d588539e8bd423a1c3</Application> Saving the original attachment 81684 [details] from bug 81522 with yesterdays nightly and opening it in Word does not give an error.
@Regina Henschel: The attachment 144104 [details] you have mentioned does not open in MS Word. As a result we can not reproduce this FILESAVE issue. Could you please double-check and clarify?
Open attachment 144104 [details] in LibreOffice. It opens in LibreOffice without problems. Then save it. If a docx file opens in LibreOffice, then I expect, that LibreOffice saves it so to docx format, that the saved file is valid, regardless of the state of the original file.
For me, the bug behaviour exists in commit 36939127391f2275cad5a676cf073cfa998c9982, i.e. the exact one commit just before the commit 72541a46aa26194b751785cd56185c8d3db0c9e9 you claimed to be "good". Also I tested and it was the same at least in my 7.1 bibisect repo. (P.S. I used MSO 2010 to open the saved docx file in a VM. LibreOffice is in Fedora 34 host machine) Regina Henschel: Could you give a try to bibisect this with a bibisect repo on master branch? https://bibisect.libreoffice.org/win64-7.3 (for Windows)
You are right. I do not find a version, where saving produces a valid file. I have removed keywords.
(In reply to Regina Henschel from comment #4) > If a docx file opens in LibreOffice, then I expect, that LibreOffice saves > it so to docx format, that the saved file is valid, regardless of the state > of the original file. I wouldn't necessarily agree. LO has grabbags to round-trip stuff it doesn't understand. So I tried to avoid that by saving as ODT first, and then exporting that as DOCX. It didn't open either (in MS Word 2003).
The saved file opens without any complaints in office.com. I tried both with master and with 7e7a871bcd4f923b015a7e040969335696b434c6 from 7.3. Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a345952daf3238066ecb1a9c67bb6a3640a6299a CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 31 January 2023
The element <c:externalData> has the attribute r:id="rId1". The chart1.xml.rels file in the _rels folder connects this resource reference to Target="../embeddings/Microsoft_Excel_Worksheet1.xlsx". The 'embeddings' folder exists, but the Microsoft_Excel_Worksheet1.xlsx file is an empty file. Is "office.com" the online version of Microsoft Office? It might be that the online version simple drops a not usable reference. But Microsoft Office 365 can still not open the file and neither can it 'repair' the file. If I save the file to odt, then I get in the <style:chart-properties> element an attribute loext:external-data="word/embeddings/Microsoft_Excel_Worksheet1.xlsx". That makes no sense there, because a 'word' folder does not exists in the package. The chart itself is based on the internal table. Generating the docx file from this odt file still produces the error, that Microsoft Office 365 cannot open it. Only when I go the way over ODF 1.3 strict so that the attribute loext:external-data is not written, the generated docx file will open in Word. LibreOffice should detect, that the link goes to inside the package and that the xlsx file does not exist in the package, and then do not write a <c:externalData> element.
(In reply to Regina Henschel from comment #9) > The element <c:externalData> has the attribute r:id="rId1". The > chart1.xml.rels file in the _rels folder connects this resource reference to > Target="../embeddings/Microsoft_Excel_Worksheet1.xlsx". The 'embeddings' > folder exists, but the Microsoft_Excel_Worksheet1.xlsx file is an empty file. > > Is "office.com" the online version of Microsoft Office? It might be that the > online version simple drops a not usable reference. But Microsoft Office 365 > can still not open the file and neither can it 'repair' the file. Yes, it is the online version. Interesting to hear about the different result. Sometimes the online version does repair files, but it always says so.