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
Created attachment 85003 [details] screenshot of libreoffice on linux
Created attachment 85005 [details] screenshot of libreoffice on xp
Created attachment 85006 [details] screenshot of word on xp
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?
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....
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
I think that you faced a WMF issue like the ones described in Bug 39327. *** This bug has been marked as a duplicate of bug 39327 ***
The problem is still exists in LibreOffice 5.4 and LibreOffice 6.1 master
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.
Created attachment 149344 [details] image's option shows it
Created attachment 149345 [details] exported PDF
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!
*** Bug 127728 has been marked as a duplicate of this bug. ***
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.
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.
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.
(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?
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
(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).
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
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.
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..
(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.
(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"
Issue fixed by https://git.libreoffice.org/core/commit/27a4aea50a9efa5c839b0ae2de1f9f14a7782f11 @Luboš Luňák, thanks for fixing this issue. Closing as VERIFIED FIXED
Created attachment 169770 [details] How it looks in LibreOffice 7.2 master