Bug 82874 - [WMF] FILEOPEN: Background imported incorrectly
Summary: [WMF] FILEOPEN: Background imported incorrectly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: filter:wmf
Keywords:
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2014-08-20 15:33 UTC by caselli.stefano
Modified: 2023-05-31 05:25 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
word document showing the bug (42.03 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-08-20 15:33 UTC, caselli.stefano
Details
wmf image from the document (675.49 KB, image/x-wmf)
2014-08-21 14:35 UTC, Alexandr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description caselli.stefano 2014-08-20 15:33:31 UTC
Created attachment 104990 [details]
word document showing the bug

Hi,
I have a document in DOCX format that is imported incorrectly: the image is corrupted. Example attached.
Thanks.
Comment 1 Alexandr 2014-08-21 14:35:54 UTC
Created attachment 105048 [details]
wmf image from the document

Thank you for reporting the bug.
I reproduce it with LibreOffice 3.5.4, 4.2.6, 4.3.1.1, 4.4 on Debian and OpenOffice.org 3.3.0 on Win 2003.
As far as I understand, the issue is not with docx import, but with wmf. I extracted the image from the document and opened it with LibreOffice draw with the same result.
Comment 2 QA Administrators 2015-10-14 19:58:18 UTC Comment hidden (obsolete)
Comment 3 caselli.stefano 2015-10-18 10:05:27 UTC
bug still present on 5.0.2.2 using Windows 7 x64
Comment 4 caselli.stefano 2016-08-05 12:45:34 UTC
bug still present on 5.2.0.4
Comment 5 Xisco Faulí 2017-10-03 15:05:56 UTC
In

Version: 6.0.0.0.alpha0+
Build ID: 34e8fd7e99489e9f50a512b07c6f3923b358b4d3
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

the image is correctly imported but the background is incorrect, as it's orange.
Comment 6 QA Administrators 2018-10-04 02:55:59 UTC Comment hidden (obsolete)
Comment 7 caselli.stefano 2018-10-11 05:46:50 UTC
bug is still present in 6.1.1.2
Comment 8 QA Administrators 2019-10-12 02:46:07 UTC Comment hidden (obsolete)
Comment 9 caselli.stefano 2019-10-12 05:39:14 UTC
bug is still present on version 6.3.2.2
Comment 10 caselli.stefano 2020-08-10 06:37:32 UTC
bug still present in version 7.0.0.3
Comment 11 caselli.stefano 2021-02-10 06:52:31 UTC
bug still present in version 7.1
Comment 12 Valek Filippov 2021-05-24 15:23:23 UTC
There are two problems with this WMF.

1. Top and front "sides" are not filled properly, because ExcClipRect record is not working as it should. It could be related to "inverted" coordinates of the excluding rectangle. (Simple samples attached to tdf#142037)

2. Right "side" is filled by applying two DibStretchBlt records (210 and 211 counting from 0 in the file).
It looks like LO doesn't like ROP values used in it, which is 0xee0086 and 0x8800c6.
Removing the first (smaller) bitmap and changing ROP of the second one to 0xcc0020 shows expected "filling with orange gradient".
Comment 13 Valek Filippov 2021-05-30 17:18:03 UTC
0x8800C6 is SRCAND
0xEE0086 is SRCPAINT

https://docs.microsoft.com/en-us/previous-versions/aa932106(v=msdn.10)?redirectedfrom=MSDN
Comment 14 QA Administrators 2023-05-31 03:16:49 UTC Comment hidden (obsolete)
Comment 15 caselli.stefano 2023-05-31 05:25:55 UTC
The bug is still present.
Tested in version:

Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: it-IT (it_IT); UI: it-IT
Calc: CL threaded