Created attachment 115267 [details] ODT document containing a WMF image exhibiting the bug In the attached ODT document, the WMF image is not rendered correctly in LibreOffice 4.4.2: black squares hide most of its contents. It looks like the transparent background of some elements is incorrectly drawn in black. This is a regression introduced between LO 4.0.0, where the image is rendered correctly, and 4.1.5, where the current situation was already present. This happens on both Mac OS X and Linux. It also affects .docx documents. I've tried setting EMF_PLUS_DISABLE=1, with no effect.
I can confirm with Version: 5.0.0.0.alpha1+ Build ID: 59adad74084e9281887e3f78a225794f37b784d7 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-29_12:40:39 no problem in LibreOffice 3.5.0 Build ID: d6cde02, regression
This appears to have begun at the below commit. Adding Cc: to caolanm@redhat.com; Could you possibly take a look at this one? Thanks commit 0752c18df9a975ffa182a4a7bc86e0bcadd58aec Author: Armin Le Grand <alg@apache.org> AuthorDate: Fri Jul 27 14:01:18 2012 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Sun May 12 16:59:28 2013 +0100 Resolves: #i119450# Added EMR_ALPHABLEND case to EnhWMFReader to correct visualisations Patch by: Jianyuan Li Review by: alg(cherry picked from commit 1ea8c3a924d518043c5d3d1427cd40cf500c8b21) Conflicts: svtools/source/filter/wmf/enhwmf.cxx Change-Id: If1436cc58ba48048777571e74511f4fc97d2bef3
Ah, I was precisely starting to do the bibisect. :-) Thanks!
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Armin, maybe you're interested? commit 0752c18df9a975ffa182a4a7bc86e0bcadd58aec Author: Armin Le Grand <alg@apache.org> AuthorDate: Fri Jul 27 14:01:18 2012 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Sun May 12 16:59:28 2013 +0100 Resolves: #i119450# Added EMR_ALPHABLEND case to EnhWMFReader
Quick check: The bitmaps with the WMF are imported correctly. Painting these adds them to a Metafile twice with RasterOp's R2_XORPEN and R2_COPYPEN, see WinMtfOutput::ResolveBitmapActions. This may be problematic - we are not good with xor stuff ;-( Need to check deeper...
Indeed, RasterOp ROP_XOR makes problems. Looks as if it is not correctly handled throughout the paint layer. It is converted to primtive (InvertPrimitive2D which is a grouping primitive), but the masking buffers and evtl. the paint to DirectDraw on Win may not use it, checking...
Just checked, already happens in LO4.4.7.1, saw that this is the case since 2013, I thought this is more current. Checked LO4.0.6.2, looks good there (just by ignoring these actions and not handling them, what do they do then...?)
Very strange - teh isolated wmf shows the diagram, but with shadow. When looking at the read Bitmaps these are all-black, 24bit, no alpha. Independent from painting, there may be something wrong with DIB import.
Found that indeed for EMR_ALPHABLEND the MS docu at https://msdn.microsoft.com/en-us/library/cc230613.aspx defines alpha possibilities for the to-be-loaded bitmap which the implementation of EMR_ALPHABLEND does not support. It creates a temp file to be able to use ReadDIB which itself is not capable of reading alpha. This means that the whole old patch is not complete and only works when BLENDFUNCTION AlphaFormat is 0x00 and SrcConstantAlpha is 0xff (which means to copy the bitmap). I checked with the bugdoc and it contains alpha data which is not read. Adding stuff to read it is not easy (best chance is to create a temp file to use ReadDIBV5 I would guess).
Can read bitmaps with alpha now, but their usage in WinMtfOutput::ImplDrawBitmap modifies tham due to mbComplexClip being set. That sets them full black again since only mask is used, no alpha support.
Had to check/adapt the display pipeline to not lose the imported Mask/Alpha information. Adapted WinMtfOutput::ImplDrawBitmap to take Alpha into account when blending against complex clip regions. The display chain imports WMF as Metafile, that gets converted to Primitives. If WMF import would create Primitives in the 1st place blendigs like that would be more simple (could be expressed as clipping/Mask) and more original data could be preserved.
1st version put to gerrit
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f12c93703b676b1b3839caaf2c21788e5d68477 tdf#91017 Enhance WMF import of EMR_ALPHABLEND action It will be available in 5.2.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.
Thanks! How likely is this to be backported to 5.1.x?
Also now shows the missing shadows of the graphic...
Can someone comment on backporting? Technically should be no problem, +1 from my side.
Typically its up to who ever fixes it to decide if to backport or not (and to do the mechanics of it). In this case I did it myself and submitted to gerrit as https://gerrit.libreoffice.org/#/c/22053/ (gerrit then adds the original author on CC by default)
*** Bug 91093 has been marked as a duplicate of this bug. ***
Thanks Caolan!
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bc257df73af5fdaf973c8229a743a3ea0ce06a67&h=libreoffice-5-1 tdf#91017 Enhance WMF import of EMR_ALPHABLEND action It will be available in 5.1.1. 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.
verified. Version: 5.4.0.0.alpha0+ Build ID: febc116 the wmf image is rendered correctly without any black squares.