Created attachment 196563 [details] A testdoc from commit 92a407b7f90a98704a238c5ffa3a3491eaf3263a Using the testdoc from bug 143222 (attached), run this command: soffice --convert-to pptx --outdir /some/directory tdf143222.pptx The resulting file, since commit bff76421e234df7246a7f49c71a11432f86e09d1, has only 22 KB (previously, it was 38 KB), and opening it in PowerPoint gives a warning about a problem in content, trying to repair which shows an empty slide. Impress opens a slide with an OLE icon, instead of the spreadsheet.
(In reply to Mike Kaganski from comment #0) > Created attachment 196563 [details] > A testdoc from commit 92a407b7f90a98704a238c5ffa3a3491eaf3263a > > Using the testdoc from bug 143222 (attached), run this command: > > soffice --convert-to pptx --outdir /some/directory tdf143222.pptx > > The resulting file, since commit bff76421e234df7246a7f49c71a11432f86e09d1, > has only 22 KB (previously, it was 38 KB), and opening it in PowerPoint > gives a warning about a problem in content, trying to repair which shows an > empty slide. Impress opens a slide with an OLE icon, instead of the > spreadsheet. Hi Mike, I am not sure that this problem caused by this commit: bff76421e234df7246a7f49c71a11432f86e09d1 I could reproduce it with on older version, which is not contain that patch: Version: 7.5.6.1 (X86_64) / LibreOffice Community Build ID: d92328d010e47316d095845b495bd12dbbe434af CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL threaded As I saw with the convert-to we are not exporting the image.wmf and its content in the slide1.xml, but we export it with a normal save as.
Ah! I confused myself, I'm sorry. I tested files converted interactively, converted with command line, and in the end, I bisected paying attention to the file size ... so it all got messed up. Let me start over. It has never worked properly. I came across it when my change started to fail the unit test for bug 143222, the "Check export of embedded worksheet in slide" part. When I investigated it, it turned out that even before my change, it only passed because GetGraphic used to never return nullptr (because EmbeddedObjectRef::GetReplacement made sure to emplace() an empty graphic unconditionally). And then I messed up with the bisection. The problem of not exporting the replacement graphic is reproduced also in 7.3 bibisect repo for commit 92a407b7f90a98704a238c5ffa3a3491eaf3263a, which fixed bug 143222.
https://gerrit.libreoffice.org/c/core/+/173761
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/275aebc5085cd4b0fd3d045ef1ec65c99e1d5b56 tdf#163064: pic element is required here, after all It will be available in 25.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/47a10b6dba1f748f66ff5bd9e012c796acb83dd9 tdf#163064: pic element is required here, after all It will be available in 24.8.2. 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.