Created attachment 203551 [details] forum-mso-de-38427.ppt Open and save the attached file, forum-mso-de-38427.ppt, to PPTX and try opening it in PowerPoint, it will fail. Interestingly, when converting using convert-to with a command something like the following, the result is OK: soffice.exe --convert-to pptx forum-mso-de-38427.ppt The meaningful difference between the files is in '_rels/.rels' after unzipping, where the convert-to result has this: <Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officedocument/2006/relationships/metadata/core-properties" Target="docProps/core.xml"/> While after saving from the UI as PowerPoint 2007-365 (*.pptx) format, it has the following: <Relationship Id="rId1" Type="http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties" Target="docProps/core.xml"/> When saving using the UI, there's another format, Office Open XML Presentation (*.pptx), this also produces a working file, and the relationship type URI is the same as in the convert-to case. What's interesting is that PowerPoint also exports this part like the "bad" PowerPoint 2007-365 (*.pptx) format from the UI, and of course it's able to read the file back, which means there must be other relevant differences: <Relationship Id="rId2" Type="http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties" Target="docProps/core.xml"/> Observed with LO 26.2.0.0.alpha0+ (8ea8e254a3151f5390f3a10ff156fcaf8e7c5d5c) / Windows. In latest of 5.2 Windows bibisect repo the export is OK, in 5.3 there is a likely unrelated change, causing validity issues (caught by OOXML-Validator), and when that disappears in 6.2, the file remains invalid (though OOXML-Validator shows no validity issues). Probably not worth chasing, and instead best to investigate this independently. Since exporting most presentations to PPTX is OK in Impress, it might be interesting what detail of this presentation matters. Based on the initial observation (UI vs. --convert-to), bug 165180 might be relevant. Attaching PPTX exported by PowerPoint 2013 for reference, both the regular, transitional and strict ones.
Created attachment 203552 [details] PPTX exported from PowerPoint (transitional)
Created attachment 203553 [details] PPTX exported from PowerPoint (strict)
The problem is with core.xml's <cp:lastPrinted>31132-09-09T07:06:52Z</cp:lastPrinted> Apparently MS has built-in obsolescence. It won't be able to read files created after the year 9999 (and refuses to read presentations created in the middle ages - before the year 1700).
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/63bac9055e2e81e238af885c289e99b733d86d7a tdf#169072 ms export: valid date years are 1601 - 9999 It will be available in 26.2.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.
Works well in LO 26.2.0.0.alpha0+ (63bac9055e2e81e238af885c289e99b733d86d7a) / Windows. Thanks for fixing, Justin!
Btw, based on this part of the commit message, does it mean "PowerPoint 2007-365 (*.pptx)" format via the UI is actually saving in the old version of the OOXML format? "This applies to all docx files, and ECMA_376_1ST_EDITION (2007) versions of the other formats."
(In reply to Aron Budea from comment #6) > Btw, based on this part of the commit message, does it mean "PowerPoint > 2007-365 (*.pptx)" format via the UI is actually saving in the old version > of the OOXML format? Yes, IIUC. AFAIC, this is identical to what mstahl fixed for docx. What we label as 2007-365 is actually just the 2007 version, and what we label as "Office Open XML Presentation" is better described as "PowerPoint 2010-365". I believe the same thing is true for Calc. Of course, all of that would need to be rigorously verified. And also of course, NOBODY ever saves as "Office Open XML", so likely all kinds of disaster will strike when someone "fixes" this (like what happened with docx).
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/4e472c35a83d5c3c89948811bdd8fcac5e335d85 tdf#169072 ms export: valid date years are 1601 - 9999 It will be available in 25.8.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.
OK - this is rather humorous. I believe the only reason this worked for "non-ECMA 1st edition" is because MS Office was ignoring the core.xml (round-tripping it as core0.xml). So the only reason it worked is because it wasn't parsed. I need to revisit this when the patches related to bug 165180 land.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef5846a1ea802f580508984baa6dc76d3d9d617f tdf#169072 ms export: valid date years are 1601 - 9999 #2 It will be available in 26.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/8634c0870ac4f4c16c8a00fbacf2592af2a9a70a tdf#169072 ms export: valid date years are 1601 - 9999 #2 It will be available in 26.2.0.0.beta2. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/877eedc73c0349b39b07e19e01fa2dca422448c8 tdf#169072 ms export: valid date years are 1601 - 9999 #2 It will be available in 25.8.5. 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.