Created attachment 113502 [details]
The problem source file
When exporting sertain document (it is attached) to PDF or printing this document using
in printer settings I get black squares instead of images.
If printing with "Printer Language=PostScript" images are OK.
On print preview images are OK.
Tested with Export to pdf.
Only reproducible on Linux, even 3.5.0.
Not reproducible with 3.3.0, but we can't bibisect older than 3.5.
Win 7 Pro 64-bit, LibO Version: 126.96.36.199
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Ubuntu 14.10 64-bit Version: 188.8.131.52.alpha0+
Build ID: 6b3aa0fe4094e87290bd33a30bd6cd99ee78ce38
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-02-16_21:52:18
Build ID: 40m0(Build:3)
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
(In reply to Beluga from comment #1)
> Tested with Export to pdf.
> Only reproducible on Linux, even 3.5.0.
> Not reproducible with 3.3.0, but we can't bibisect older than 3.5.
Whiteboard -> notBibisectable
I am getting exactly the same problem with another image.
LibreOffice 184.108.40.206, build ID 40m0(Build:2), locale cs_CZ
Linux Mint 17 64-bit
Migrating Whiteboard tags to Keywords: (notBibisectable)
Replacing keyword 'notBibisectable' by 'preBibisect' as this bug is outside the bibisect range
Another example, this time in Windows: attachment 76865 [details] from Bug 38619 now prints with black square instead of WMF. So I change Linux to All.
As in Bug 77525, workaround is:
1. Right click on the image and select "Compress Graphic"
2. In the Compress Graphic dialogue click "Calculate"
As in Bug 103833, I ask: should this be done automatically on fileopen?
This should be tested with and without OpenGL set in Tools-Options-LO-View (restart LO after change).
After driver reinstallation for AMD Radeon 6450, I have OpenGL blacklisted and I can't reproduce this, only if I force OpenGL.
(In reply to Jan Lachnitt from comment #3)
> I am getting exactly the same problem with another image.
> LibreOffice 220.127.116.11, build ID 40m0(Build:2), locale cs_CZ
> Linux Mint 17 64-bit
Could you please post that as a test document, or possibly extract the image and post it. Thus far we only have the one set of problem PNG images from the document attached in comment 0 above.
Would be helpful to narrow the types of images that cause this problem.
@Jan Lachnitt, the NEEDINFO is to you, if you would please and then set back to NEW. Thanks!
Created attachment 131025 [details]
Test image is attached, simply insert it in a document and export as PDF. No matter if HW acceleration or OpenGL is enabled or not, the image renders as a black rectangle in the PDF file. However, if OpenGL is enabled, it renders as a black rectangle even in LO!
LO 5.1.4 (build 1:5.1.4-0ubuntu1) on 64-bit Linux Mint 18 Cinnamon. PDF viewer: Xreader 1.0.8.
(In reply to Jan Lachnitt from comment #10)
> Created attachment 131025 [details]
Thank you for posting. Your image confirms our issues is of handling "bilevel" PNG as in bug 103833
Closing this as duplicate of that but will list your attachment there.
*** This bug has been marked as a duplicate of bug 103833 ***
IMHO, Bug 103833 should be marked as a duplicate of this bug, because this one was reported earlier. Moreover, I don't understand how PDF export or printing is related to OpenGL rendering. However, I am not a LO developer, so you decide.
(In reply to Jan Lachnitt from comment #12)
> IMHO, Bug 103833 should be marked as a duplicate of this bug, because this
> one was reported earlier. Moreover, I don't understand how PDF export or
> printing is related to OpenGL rendering. However, I am not a LO developer,
> so you decide.
Doing the QA admin for clear duplicates we generally will use the earliest instance.
Here though, the PDF export and the OpengGL rendering are crossing paths. This initially was about the mishandling for PDF export--but the root cause in the VCL source will most likely be the same. The newer bug in this instance was more on point, the "bilevel" PNG having been split from other image handling issues.
Either way--thank you for contributing.