Created attachment 106751 [details] Drawing that gets corrupted on roundtrip Impress corrupts both the file and the resulting image when you save slides with drawings as PPTX. Steps to reproduce the bug: 1. Open SampleArtwork.pptx in Impress 2. Save as .pptx 3. Open in PowerPoint,OneDrive, or Impress 4. Compare the documents. This bug was observed on LibreOffice v4.4 under Windows.
Created attachment 106752 [details] Roundtrip generated with 4.4
Created attachment 106753 [details] Powerpoint Error message and comparison
I confirm issue under Win7x64 using recent 4.4.0.0 alpha, 4.3.1.2 with same results as in screenshot at least is better than 4.2.6.2 which shows a grey rectangle in place of the image, so some progress from 4.2.x has been achieved. changed version field to 4.3.1.2 to reflect current state of corruption
by the way, no drawing corruption saving as .odp
Created attachment 108039 [details] oox drawing object corruption on LO 4331 export to OOXML and reopen
Created attachment 114095 [details] In LO 4.5 PowerPoint graphics are now grey boxes In LO 4.5, this issue has gotten worse. Instead of distorting the graphics, it now replaces them with grey boxes. We should bibisect this regression.
So the fact that it used to work better is a regression, but of course the fact that it didn't used to work at all isn't - that's been true all the way back to LO 3.3.0, and OOo didn't support pptx at all. So let's call this report a regression for now, and if we get to the state where the regression part is fixed but the image is as imperfect as before, we can consider opening a new bug to deal with that part.
The regression part started in the 4.5 dbgutil bibisect repo at 2015-02-07: source-hash-3159f59e2c620de14d9570b69a802554a3968af8 It seems pretty likely that's going to be the below commit. Addinc Cc: to timar74@gmail.com; Could you possibly take a look at this one? Thanks commit b1751e6ed0fd6d6d26141e4405df92520e3c04cd Author: Andras Timar <andras.timar@collabora.com> Date: Thu Feb 5 22:36:24 2015 +0100 bnc#637947 improve DrawingML export of custom shapes
(In reply to Matthew Francis from comment #8) > commit b1751e6ed0fd6d6d26141e4405df92520e3c04cd > Author: Andras Timar <andras.timar@collabora.com> > Date: Thu Feb 5 22:36:24 2015 +0100 > > bnc#637947 improve DrawingML export of custom shapes This commit is in LibreOffice 4.5 only. It cannot cause problems in LibreOffice 4.4.
OK, I'll do this the other way round then and raise a new bug
The recent regression has been split onto bug 90338 Setting this one back to "not a regression"
Created attachment 114460 [details] Another example of skewed/warped shape on round-trip
(In reply to Luke from comment #12) > Created attachment 114460 [details] > Another example of skewed/warped shape on round-trip This is a different bug, so opened a new bug for it: bug 91429. Let's keep this bug clean. In this bug we need to solve https://bugs.documentfoundation.org/attachment.cgi?id=106753 (in LibreOffice 4.4, because 5.0 is borken in a different way).
I started to work on this on the Cambridge Hackfest. Here are my findings: 1. 4.4 export: the problem is that the shape is put into a PolyPolygon, which contains only one Polygon. The WritePolyPolygon function in DrawingML export code uses the first point of each Polygon as a MoveTo command. In our case we have distinct shapes. We cannot model this shape as single Polygon where only the first point is mapped to MoveTo. 2. 5.0 export: it uses the GetLineGeometry() function, which uses the custom shape engine to convert the shape into a B2DPolyPolygon. In this case we loose size information, all polygons are fit to the bounding box, thus we get the green rectangle. I think we should get rid of PolyPolygon representation of shape, we loose information. Rather, we should export the shape directly from the XShape object. This approach seems to be working well, but I still have issues. For example what to write to w and h attributes to a:path element, when the shape does not have SubViewSize property.
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=481c185e327cb83ffcb29657d5a354eae2c4a5f3 tdf#90338 tdf#84254 DrawingML export fix It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andras, Awesome job! All the Office 2013 SmartArt that was failing before is now round-tripping perfectly. This is a huge interoperability improvement and should probably be added to the release notes. https://wiki.documentfoundation.org/WikiAction/history/ReleaseNotes/5.0 Thanks! Verified fixed on Version: 5.1.0.0.alpha1+ Build ID: be01d68420086fc36ecf26b5f597ba7c6b29b369
before adding it to 5.0 release notes it has to be backported to 5.0.x branch. actually the fix is just in the 5.1.x codeline. @Andras any plans to do this?
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fa10fa7ea7026de7d998776201747afda0ca6b2&h=libreoffice-5-0 tdf#90338 tdf#84254 DrawingML export fix It will be available in 5.0.0.0.beta2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.