Created attachment 143960 [details] File produced by PowerPoint The attached document contains a simple WordArt without transformation or special effects like glow or shadow. Open the file and save it with new name. Open the saved file in PowerPoint. It wants to repair it, but "repair" does not work and PowerPoint cannot open the file. The file was produced be PowerPoint 365, Version 1807. There was no problem with open and save with Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: de-DE (en_US); Calc: CL It fails with Version: 6.1.0.2 (x64) Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: de-DE (en_US); Calc: CL
Created attachment 143961 [details] File saved by LibreOffice 6102
Created attachment 143962 [details] File saved by LibreOffice 6042
If you unpack the corrupted file and open the part presentation.xml, you will see an end-tag </p:presentation> with content after it. At the end of the part presentation.xml you see an end-tag </p:defaultTextStyle> which has no start-tag. The file is indeed corrupt.
The error only occurs, if the file was saved in OOXML strict by PowerPoint. The faulty "presentation.xml" looks as if the new exported elements are written on top of the original file, so that there is a leftover from the original file starting around column 667 in line 2.
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=8f79f22a8d4b1c2d209c55cd618c24428960088f author Ashod Nakashian <ashod.nakashian@collabora.co.uk> 2018-03-06 22:43:34 -0500 committer Jan Holesovsky <kendy@collabora.com> 2018-03-08 12:40:19 +0100 commit 8f79f22a8d4b1c2d209c55cd618c24428960088f (patch) tree 0447e43cdca126688699ffd76665c130247b7384 parent 4de1c0223ceb76556ff1c20000b4ea95bfc1d2a0 (diff) oox: preserve the ContentType of custom files Generic logic to preserve custom files with their correct ContentType. Standard default file extensions with respective ContentType preserved in [Content_Types].xml. Bisected with: bibisect-linux64-6.1 Adding Cc: to Ashod Nakashian
(In reply to Xisco Faulí from comment #5) > Regression introduced by: > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=8f79f22a8d4b1c2d209c55cd618c24428960088f > Thanks Xisco for chasing this. Can you provide more info please? I'm not sure what 'strict mode' is or how to set it (in fact I don't have MSO). Also, can you provide an example of the output you describe in the previous comment regarding the leftover please? Perhaps a screenshot between expected and actual? Also, how common is this issue? Thanks
(In reply to Ashod Nakashian from comment #6) > Can you provide more info please? I'm not sure what 'strict mode' is or how > to set it (in fact I don't have MSO). The pptx format is specified in ISO/IEC 29500. But Microsoft might add some extensions to that format (e.g. for compatibility to old ppt format), which are not specified and are not handled by the extension mechanism provided in the specification. In MSO you can decide whether to use these extensions or to save to 'strict' format. The specification describes the conformance classes in §2.1 of part 1. The file presentation.xml has in element <p:presentation> the attribute 'conformance="strict"'. The other attribute value would be 'transitional', which is the default in case the attribute is missing. Also, can you provide an example of > the output you describe in the previous comment regarding the leftover > please? Perhaps a screenshot between expected and actual? It is nothing about 'screen', but about the files. The pptx format is a simple zip-container. So unpack the three attached files. Then open the file 'presentation.xml' from subfolder 'ppt' in a text editor and compare theme. > > Also, how common is this issue? I don't know. A private user will usually not use the 'strict' format, because it is not the default format. I don't know whether there exists enterprises or authorities that force the use of 'strict' format.
The source of this bug is that when the code is checking for custom XMLs, it checks the content of "xmlns" attributes, and if they're not "http://schemas.openxmlformats.org", they're treated as a custom XML, and the content is supposed to be preserved. This doesn't go well when the XML is also part of the file format. In this PPTX file those attributes have this prefix instead: "http://purl.oclc.org/ooxml/drawingml/main" (purl.oclc.org is a URL shortener) I assume XMLs that have override entries in "[Content_Types].xml" should never be treated as possible custom XMLs.
Dear Regina Henschel, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The problem still exists in Version: 6.4.0.0.alpha1+ (x64) Build ID: 7c6226bee72805db7f0e567ca9f06c786a7d0da2 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (en_US); UI-Language: en-US Calc: threaded
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9be543a27ab18427a1c4e66a70cc49b0332b6aa1 tdf#119087 Don't treat OOXML strict namespace as custom XML It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/68f75fe0701fcf9b92c5f1b5fd5eeb9268297494 tdf#119087 Don't treat OOXML strict namespace as custom XML It will be available in 6.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.0.0.0.alpha0+ Build ID: cf36fe5eb41910c26d58fb25e54ccf2e0ee01365 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded @Samuel, thanks for fixing this issue!