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