Bug 68810 - VIEWING: WMF image is black / dark in Linux
Summary: VIEWING: WMF image is black / dark in Linux
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.0.5 target:7.1.2
Keywords: filter:doc, preBibisect, regression
: 127728 (view as bug list)
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2013-09-01 10:57 UTC by mattia.b89
Modified: 2021-02-16 11:10 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
doc file (47.00 KB, application/msword)
2013-09-01 10:57 UTC, mattia.b89
Details
screenshot of libreoffice on linux (199.63 KB, image/png)
2013-09-01 10:59 UTC, mattia.b89
Details
screenshot of libreoffice on xp (95.85 KB, image/png)
2013-09-01 10:59 UTC, mattia.b89
Details
screenshot of word on xp (55.70 KB, image/png)
2013-09-01 11:01 UTC, mattia.b89
Details
image's option shows it (213.92 KB, image/png)
2019-02-17 11:16 UTC, mattia.b89
Details
exported PDF (66.64 KB, application/pdf)
2019-02-17 11:16 UTC, mattia.b89
Details
screenshot of LO 3.5 in Win8.1 (68.19 KB, image/jpeg)
2020-01-13 16:08 UTC, Timur
Details
Screenshot, LO 7.1, Linux (229.40 KB, image/png)
2020-11-18 03:52 UTC, Aron Budea
Details
How it looks in LibreOffice 7.2 master (281.07 KB, image/png)
2021-02-15 17:40 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mattia.b89 2013-09-01 10:57:15 UTC
Created attachment 85002 [details]
doc file

libreoffice-4.1.1 on linux-x86_64 can't show some images correctly
and are replaced by black rectangles in a .doc file

with libreoffice-4.0.1.2 on windows xp-32 bit I can see some content but not the "true" image

with office word 2003 on windows xp-32 bit the image is shown (I hope at least) correctly

I attach the .doc file and three screenshots which show you what I have just said
Comment 1 mattia.b89 2013-09-01 10:59:04 UTC
Created attachment 85003 [details]
screenshot of libreoffice on linux
Comment 2 mattia.b89 2013-09-01 10:59:52 UTC
Created attachment 85005 [details]
screenshot of libreoffice on xp
Comment 3 mattia.b89 2013-09-01 11:01:53 UTC
Created attachment 85006 [details]
screenshot of word on xp
Comment 4 tommy27 2013-09-01 20:31:19 UTC
I see black rectangle with LibO 4.1.1 final under Win7 64bit

which format is that image? can you upload it separately?
how did you insert it in the .doc file? linked? embedded?
Comment 5 mattia.b89 2013-09-02 12:23:58 UTC
unfortunately I haven't created this doc. It's a university file, so I can't give you any further information, at least, which you tell me because I can't contact who created the doc

I know it's not the best way to report an issue but it's better than nothing....
Comment 6 tommy27 2013-09-07 12:38:09 UTC
same issue (black image) even with 4.2 alpha Sept.3 build.

treid to extract image from document and open in external sofwares...
it's a WMF file but the extracted version is all black...

it seems that it's corrupted by LibO not only uncorrectly showed
Comment 7 tommy27 2013-09-07 13:54:52 UTC Comment hidden (obsolete)
Comment 8 Bartosz 2018-04-10 20:58:54 UTC
The problem is still exists in LibreOffice 5.4 and LibreOffice 6.1 master
Comment 9 mattia.b89 2019-02-17 11:15:01 UTC
Bug still here with,
 Version: 6.2.0.3
 Build ID: 6.2.0-3
 CPU threads: 4; OS: Linux 4.20; UI render: default; VCL: gtk3; 
 Locale: it-IT (en_GB.UTF-8); UI-Language: en-GB
 Calc: threaded

Anyway, a tiny improvement happens:

1- if you double-click on the image (the black box) and go to "image" tab, there is the image's preview correctly rendered (except for the width/height ratio).
.screenshot attached below.

2- if you export the .doc file as PDF, you will have a table (the image itself is a table) but with black text on black background. Hence, if you select the table content you can read it!
.PDF attached below.
Comment 10 mattia.b89 2019-02-17 11:16:04 UTC
Created attachment 149344 [details]
image's option shows it
Comment 11 mattia.b89 2019-02-17 11:16:28 UTC
Created attachment 149345 [details]
exported PDF
Comment 12 mattia.b89 2019-09-08 14:58:28 UTC
The issue is still here

Version: 6.3.1.2
Build ID: 6.3.1-1
CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: it-IT (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded

BUT, interesting fact, if I INVERT TWICE the image (Format -> Image -> Filter -> Invert) the image appears!
Comment 13 Timur 2019-12-02 18:01:42 UTC
*** Bug 127728 has been marked as a duplicate of this bug. ***
Comment 14 Timur 2019-12-02 18:05:18 UTC
LO 3.5 opened fine. In LO 3.6 image was visible but dark. LO 4.0 is wrong.
Later and still black in master LO 6.5+ in Windows.
Regression. I'll put from 3.6 where worsened.
Same issue with DOC attachment 154396 [details] from bug 127728.
Comment 15 Aron Budea 2020-01-12 10:18:23 UTC
For me the images are black in both samples in 3.5.0.3, 3.6.0.4 and at oldest commit of bibisect-43all (d6cde02) / Ubuntu 19.10.
Images show up correctly in LO 3.4.0.1.
Comment 16 Timur 2020-01-13 09:41:15 UTC Comment hidden (obsolete)
Comment 17 Aron Budea 2020-01-13 09:46:32 UTC
(In reply to Timur from comment #16)
> Xisco, just to make sure:can Releases repository be used for LO 3.5?
> When I wrote that 3.5 opened fine, I guess it was 3.5 beta.
What do the version number + build id in the About box say?
Comment 18 Timur 2020-01-13 16:08:17 UTC
Created attachment 157128 [details]
screenshot of LO 3.5 in Win8.1

Image is seen OK in Windows 8.1 with:
LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 19 Aron Budea 2020-01-13 16:43:28 UTC
(In reply to Timur from comment #18)
> Created attachment 157128 [details]
> screenshot of LO 3.5 in Win8.1
I can confirm that in Windows the image is there in 3.5.0.3, and looks darkened, but still there in 4.0.0.3 (these are the versions I could test with quickly).
Comment 20 Bartosz 2020-11-17 23:18:36 UTC
I cannot reproduce it on:

Version: 7.0.3.1
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 8; OS: Mac OS X 10.15.7; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 21 Aron Budea 2020-11-18 03:52:10 UTC
Created attachment 167381 [details]
Screenshot, LO 7.1, Linux

I checked this in a bit more detail. On Windows, with default rendering, this has been fixed since 6.0.0.3. With OpenGL rendering, it was still pitch black until the switch to Skia in 7.0 (can't check with Skia/Vulkan now, it looks fine in Skia/Raster in a current master build).

On Linux, it still doesn't look correct in the latest master bibisect repo build, it changed from pitch black to visible, but dark in the center between 6.4 and 7.0 (see screenshot). I'm inclined to keep this bug report open, but it could be split as a Linux-specific issue to a separate bug report as well.

Note that the text placement in the table is still off, often too high, and the "Δh" looks weird, too. This issue definitely deserves its own bug report.
Comment 22 Timur 2020-11-18 10:50:31 UTC
Based on previous comment, I set New for Linux. 
I'm not in favor of splitting until something is done or resolved. 
I cannot test now, but Linux needs to be tested for all: GEN, SKIA, GTK3..
Comment 23 Aron Budea 2020-11-19 06:50:19 UTC
(In reply to Aron Budea from comment #21)
> On Linux, it still doesn't look correct in the latest master bibisect repo
> build, it changed from pitch black to visible, but dark in the center
> between 6.4 and 7.0 (see screenshot).
The change occurred in two steps, first the rectangle turned white with the following commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=828504974d70111e4a35b31d579cf42fe660a660
author		Armin Le Grand (Collabora) <armin.le.grand@me.com>	2020-02-21 16:58:17 +0100
committer	Armin Le Grand <Armin.Le.Grand@me.com>	2020-02-21 20:16:59 +0100

"tdf#130768 speedup huge pixel graphics Cairo"

Probably the above commit made the actual change, but there was a bug in it, which was fixed in the following commit, resulting in the look in attachment 167381 [details].

https://cgit.freedesktop.org/libreoffice/core/commit/?id=5f58ffce789c15e3849bceb9fe4844d838e9c40e
author		Armin Le Grand <Armin.Le.Grand@me.com>	2020-02-27 17:21:16 +0100
committer	Armin Le Grand <Armin.Le.Grand@me.com>	2020-02-27 19:24:46 +0100

"tdf#130951 Use the correct OutputDevice"

Based on the commits, and the experience in Windows it seems more of an issue related to graphics stack rather than the handling of the file format.

Re-adding bibisectRequest for a reverse bibisect in Windows in 6.0, default rendering to see what fixed the issue there.
Comment 24 Aron Budea 2020-11-21 02:51:54 UTC
(In reply to Aron Budea from comment #21)
> I checked this in a bit more detail. On Windows, with default rendering,
> this has been fixed since 6.0.0.3.
In Windows, with default rendering, this started working in the following range (LO failed to start in between):
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=68fda058972a6fbb38b797f50575b84f4cb3fab1..ebd0f06d87d7db3015a29c4f6f895db6ac998c38
two emf-related commits: "emfplus: cut over to new EMF+ renderer" and "sw: Use primitive renderer for graphics"
Comment 25 Xisco Faulí 2021-02-15 17:39:53 UTC
Issue fixed by
https://git.libreoffice.org/core/commit/27a4aea50a9efa5c839b0ae2de1f9f14a7782f11

@Luboš Luňák, thanks for fixing this issue.

Closing as VERIFIED FIXED
Comment 26 Xisco Faulí 2021-02-15 17:40:39 UTC
Created attachment 169770 [details]
How it looks in LibreOffice 7.2 master