Created attachment 97116 [details] Reproducer document Create at two shapes in PowerPoint, add a shadow effect to the first one, copy the slide (right click -> copy) and paste (ctrl-v) into Impress. The clipboard uses the EMF+ format, and due to incorrect handling of the EmfPlusRecordTypeSetClipPath command, the second shape is missing. I'm attaching a bit more complex example which has the same problem.
Created attachment 97121 [details] Minimal reproducer LO only shows the red shape, while there is also a green one in the document.
Created attachment 97122 [details] How it should look like.
Created attachment 97123 [details] How it looks like on master (bad)
Created attachment 97124 [details] How it looks like on master (bad, second try)
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c2af50eb6df396c957890a6b912b8f3185893551 fdo#77229 EMF+ rendering: improve EmfPlusSetClipPath's CombineModeExclude case 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2574c41e755bf2287e3db756b5aeafb2d133cada&h=libreoffice-4-2 fdo#77229 EMF+ rendering: improve EmfPlusSetClipPath's CombineModeExclude case It will be available in LibreOffice 4.2.4. 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3d90aa384d82cbd0dd9f60d5576dbdca9ec1e53 fdo#77229 testcase 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b1108fb4107d1a009acf468a1771214928516c4&h=libreoffice-4-1 fdo#77229 EMF+ rendering: improve EmfPlusSetClipPath's CombineModeExclude case It will be available in LibreOffice 4.1.7. 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.
Hi Miklos, when I build the master on Ubuntu 13.10 x86-64, I get an unit test failure on the test testFdo77229 : [build CUT] cppcanvas_emfplus emfplus.cxx:85:Assertion Test name: Test::testFdo77229 equality assertion failed - Expected: 65024 - Actual : 130560 I get this failure for a complete rebuild : make distclean -> ./autogen.sh -> make. No such problem when building LO 4.2.5.0.0+ but perhaps it is because the testcase is for master only. Best regards. JBF
Right -- the testcase is only on master. Workaround is to 'unset DISPLAY' before 'make', so the test won't be executed. If you want to solve it, then someone on that Ubuntu version should find out why the resulting EMF+ rendering has different colors than expected. I assume the issue is Ubuntu-specific, given that the test otherwise works fine on both Fedora and openSUSE tinderboxes, as far as I see. ;-)
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-1-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=af8d6c6e58d18758c2544fc71c076ae537285c48&h=libreoffice-4-1-6 fdo#77229 EMF+ rendering: improve EmfPlusSetClipPath's CombineModeExclude case It will be available already in LibreOffice 4.1.6. 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.
@Miklos, same issue on OpenSuse for me.
Created attachment 103138 [details] Build log Build log including unit test failure on openSUSE
Created attachment 103139 [details] CPPCANVAS_DEBUG_EMFPLUS_DUMP_TO rendering on a fail machine
Test works with other coordinates on my computer (141, 140) and with some others on jbfaure's one (142, 140). Any idea how to deal with that ?
Correction, also works with 142 on mine, @Miklos, does it works on yours with 142 ? If it is, I will use 142 for now.
Interesting: it seems that something solved for me the unit-test issue for version 4.3.1.0.0+ build ID:23b4b764ade82cf3a5835a7b7f35fb5e45cd6cc9. Could be possible that the commit "bnc#881024 Don't world transform font size in WMF/EMF import" http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3&id=93a77d07fa49cad9d836699a48777e0e8ff170b4 fixed that? Best regards. JBF
Not for me, same problem still there on master.
Arnaud Versini committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8124418d7add872924b6c04258260d3c88678dc0 Use better coordinates for unit test of fdo#77229 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.
Guys sometimes, when I compile LibO it complains about this unit-test: emfplus.cxx:85:Assertion Test name: Test::testFdo77229 equality assertion failed - Expected: 65024 - Actual : 130560 I compiled git master with tag 'libreoffice-4-3-branch-point' on Gentoo x86_64. In cppcanvas/qa/extras/emfplus/emfplus.cxx (at commit c3d90aa384d82cbd0dd9f60d5576dbdca9ec1e53) we have: void Test::testFdo77229() { Bitmap aBitmap = load("fdo77229.emf"); Bitmap::ScopedReadAccess pAccess(aBitmap); // The green star was missing. CPPUNIT_ASSERT_EQUAL(sal_uInt32(0x00fe00), Color(pAccess->GetPixel(140, 140)).GetColor()); } As far I can understand: 65024 = 0x00fe00 130560 = 0x01fe00 According to libemf 1.0.4-r1 (http://libemf.sourceforge.net/, printemf), the file contains only 0x00ff00 color, not above. If I open this file in standard MS Windows XP SP3 Image and Fax Viewer and save the image in linux-friendly format (GIF, PNG, JPEG, TIFF, BMP) and load resulting file in GIMP the Color Picker Tool and Color Tool report red (0x00ff00) filling of a star. So there is something wrong with Unit-test or EMF-file import.
>If I open this file in standard MS Windows XP SP3 Image and Fax Viewer and save the image in linux-friendly format (GIF, PNG, JPEG, TIFF, BMP) and load resulting file in GIMP the Color Picker Tool and Color Tool report red (0x00ff00) filling of a star. Of course I mean *green* filling of sun.
(In reply to comment #20) > Guys sometimes, when I compile LibO it complains about this unit-test: > > emfplus.cxx:85:Assertion > Test name: Test::testFdo77229 > equality assertion failed > - Expected: 65024 > - Actual : 130560 > > I compiled git master with tag 'libreoffice-4-3-branch-point' on Gentoo > x86_64. Please, could you build the current branch 4.3 and check if you still encounter this issue? The commit from comment #19 has been pushed to the master only, but I do not encounter the issue on 4.3 branch anymore (cf. comment #9). Best regards. JBF
JBF, today on fresh mind I have compiled: * master (@57dcc9f3e9a7d2ebc86cf444729a7a08820418a1 - http://cgit.freedesktop.org/libreoffice/core/commit/?id=57dcc9f3e9a7d2ebc86cf444729a7a08820418a1) - no error * libreoffice-4.3 (@cddfd33a3bea009394ec2b5c1cb94d09d8c40b23 - http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3&id=cddfd33a3bea009394ec2b5c1cb94d09d8c40b23) - no error But I still think that there is something wrong in color resolution. If I import this file to LibreOffice Draw and use gcolor2 it reports #00ff00 for green star, the thumbnails inside ODG archive ( Thumbnails/thumbnail.png ) has mostly #00ff00 color (checked in GIMP).
Are we sure that this is correct? When I open it in oletoy, it's very definitely meant to be #00ff00 (green). There is some anti-aliasing, but that's not at position (140, 142)... and actually (140, 140) is the same as (140, 142). Is the test wrong?
Bug 96676 logged - this is definitely broken again.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e49aa9303f047d7610b2b8334404db120d7bc8db tdf#77229 tdf#113635 EMF+ Add support for Clip Union, Exclude and Complement It will be available in 6.0.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.