Bug 91017 - [Regression] Black squares hide content of WMF image
Summary: [Regression] Black squares hide content of WMF image
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.1.5.3 release
Hardware: Other All
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:5.2.0 target:5.1.1
Keywords: bibisected, bisected, regression
: 91093 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-05-02 12:47 UTC by Milan Bouchet-Valat
Modified: 2017-03-03 13:27 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT document containing a WMF image exhibiting the bug (68.77 KB, application/vnd.oasis.opendocument.text)
2015-05-02 12:47 UTC, Milan Bouchet-Valat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Bouchet-Valat 2015-05-02 12:47:54 UTC
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.
Comment 1 raal 2015-05-03 07:04:45 UTC
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
Comment 2 Matthew Francis 2015-05-04 06:54:37 UTC
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
Comment 3 Milan Bouchet-Valat 2015-05-04 07:51:20 UTC
Ah, I was precisely starting to do the bibisect. :-) Thanks!
Comment 4 Robinson Tryon (qubit) 2015-12-13 11:13:09 UTC Comment hidden (obsolete)
Comment 5 raal 2016-01-15 14:13:05 UTC
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
Comment 6 Armin Le Grand 2016-01-20 17:33:32 UTC
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...
Comment 7 Armin Le Grand 2016-01-21 10:56:18 UTC
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...
Comment 8 Armin Le Grand 2016-01-21 11:11:56 UTC
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...?)
Comment 9 Armin Le Grand 2016-01-21 12:46:25 UTC
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.
Comment 10 Armin Le Grand 2016-01-21 13:50:30 UTC
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).
Comment 11 Armin Le Grand 2016-01-22 08:24:59 UTC
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.
Comment 12 Armin Le Grand 2016-01-22 10:52:36 UTC
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.
Comment 13 Armin Le Grand 2016-01-25 08:56:28 UTC
1st version put to gerrit
Comment 14 Commit Notification 2016-01-29 12:04:33 UTC
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.
Comment 15 Milan Bouchet-Valat 2016-01-29 12:54:33 UTC
Thanks! How likely is this to be backported to 5.1.x?
Comment 16 Armin Le Grand 2016-01-29 13:18:46 UTC
Also now shows the missing shadows of the graphic...
Comment 17 Armin Le Grand 2016-02-02 13:22:39 UTC
Can someone comment on backporting? Technically should be no problem, +1 from my side.
Comment 18 Caolán McNamara 2016-02-02 15:44:43 UTC
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)
Comment 19 Andras Timar 2016-02-02 21:58:06 UTC
*** Bug 91093 has been marked as a duplicate of this bug. ***
Comment 20 Armin Le Grand 2016-02-03 13:19:35 UTC
Thanks Caolan!
Comment 21 Commit Notification 2016-02-05 08:56:45 UTC
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.
Comment 22 vihsa 2017-03-01 01:01:41 UTC
verified. Version: 5.4.0.0.alpha0+
Build ID: febc116

the wmf image is rendered correctly without any black squares.