Created attachment 137023 [details] comparison MSO 2010 and LibreOffice 6.0 Steps to reproduce: 1. Open attachment 87168 [details] from bug 67297 Observed behaviour: Left image is in front of the four images on the right. This should be the other way around. Reproduced in Version: 6.0.0.0.alpha0+ Build ID: d4daf634cd9ce8d422d49669c324a2220eba54a9 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group [Bug found by office-interoperability-tools]
Regression introduced by author Armin Le Grand <Armin.Le.Grand@cib.de> 2017-06-12 13:27:16 (GMT) committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2017-07-15 09:01:29 (GMT) commit 5868745db74ae930edb0058490076d82aaeafbe9 (patch) tree 78bea29cb44b770d9e3affef2a303d0d38722d85 parent 83535a28c57ffb59f795dd35332d6b3426071e32 (diff) emfplus: make VectorFormats Emf/Wmf/Svg work make complete turn around and internal buffering for Emf/Wmf/Svg work, including images in ODF and re-save from UI. The correct FileType has to be determined. It has shown that *.wmf exist that really contain *.emf, so this turn around will not alter the binary data, but may change the mimetype Bisected with bibisect-linux64-6.0 Adding Cc: to Armin Le Grand
The EMF+ did not change the order of imported objects, so it may have changed their visualization. The obj in the foreground 'covers' the ones in the BG. It may have not had that white covering rectangle before, but the error is the order of import. Checked again in PPT, I was wrong. The order is the same and okay, but in PPT the front object does not have that covering white filled rectangle, so a valid error and an error in object import (is it EMF+?)
Strange - extracted Bild1.emf fro the example, if opening it in draw/impress, there is no BG. Adding extracted pic
Created attachment 137067 [details] The pic extracted from test document
Dear Bartosz, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
The error is not in importing the picture itself, but the pptx-file has an element a:clrChange as child of element a:blip, which changes the color FFFFFF to transparent.
Arrangement is OK, but import of color change to transparent is missing. Changing the subject accordingly.
Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded Bug not reproducible in version 6.3.0.0.alpha0+ (x64) I think there is no bug with the left image; actually, the left image can be put behind by clicking right-click on the picture and click send backwards in the arrange, so the four images will be in front of the left image.
Still reproducible in Version: 6.4.0.0.alpha1+ Build ID: fa7f07d23de31e5f1660a643d83ca8a2e565f69c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 166788 [details] PPTX sample saved as PPT in MSO Repro 7.1+ with original PPTX. MSO saved PPT is OK.
Created attachment 166792 [details] PPTX sample - with changed background to green
*** Bug 119884 has been marked as a duplicate of this bug. ***
Created attachment 166936 [details] PPTX sample - with transparency and alpha The issue is exists on both Transparency and Alpha Channel
Solution is available here: https://gerrit.libreoffice.org/c/core/+/105258
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4a288c136c66b4dfbb75764602520d48c39fee81 tdf#113163 OOXML Fix transparency and alpha channel support It will be available in 7.1.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.
Verified in Version: 7.1.0.0.alpha1+ Build ID: 2f7b5634487ac3d27777ab12a57089e71ea5216d CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Bartosz, thanks for fixing this issue!!
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/560f8935c3b9d854128d414753f871fa38c6da2a tdf#113163 OOXML Fix transparency and alpha channel support It will be available in 7.0.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c34b9acc18a357b904afa9538777072991a1e0a6 tdf#113163: sd_import: Add unittest It will be available in 7.1.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.
Bug #119884 is marked as duplicate but still not fixed. https://bugs.documentfoundation.org/show_bug.cgi?id=119884