Description: Open attached document on Windows, it shows up in Writer correctly: An empty page with an image that has some grey text on white background. That the image has text is irrelevant, it could be any image, the relevant detail is that the image (a PNG file) is one bit per pixel, i.e. two colours. but not black and white, but grey and white. On Linux, depending on which VCL "backend" (of "plugin" as they also are called) is used, it either doesn't show at all, the text shows up as black and the background as white, or even the text as black and the background as grey. Not even funny. Steps to Reproduce: . Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0.1 Safari/604.3.5
Created attachment 137842 [details] bug doc
Seems to work correctly on macOS, too.
kde4, gtk2, gen: doesn't show anything. gtk3: black text on grey bg Arch Linux 64-bit Version: 6.0.0.0.alpha1+ Build ID: 121303615054568c204def97872343d2014af4a0 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 17th 2017
I spent a day trying to understand what goes wrong. Added tons of debugging printouts to the relevant places in VCL. No cigar. I think it will be much easier to just add a workaround: When loading this kind of PNG images into LO, convert them into normal 24bpp non-palettized ones... (with each pixel then being either of the two in the original image's palette). LO is not some image manipulation software that would need to be able store any esoteric "mode" image exactly internally. This kind of PNG images are presumably fairly rare. And anyway, in this day, images with higher colour depth than 8 bits, or even "HDR" images, are gaining in importance and use, and LO doesn't handle such either. Converting to a normal full-colour image will take more space, sure, but that is outweighed by the benefit of fixing the problem.
Also, storing all images internally in LO as either 24bpp full-colour of 8bpp full-greyscale is where many developers want to go anyway. Death to palettized images!
There have been issues with Windows handling as well, though the bilevel PNG of the bug doc here does render to canvas and export to PDF with 5.4.3 Windows build. Some other examples in the bug 103833 see also and dupes.
I wrote: > I think it will be much easier to just add a workaround ... but of course, it wasn't "easy". Not sure if I will bother trying that approach any more. Just need to debug the actual issue harder. Next week.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=66dbd4da3afcadb1393daf9be9cecff71b86509a tdf#113918: Workaround: Load 1bpp indexed PNG as 8bpp indexed Bitmap It will be available in 6.0.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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a53f646df5d295ed5ab21fa1ac467694160cf1f&h=libreoffice-5-4 tdf#113918: Workaround: Load 1bpp indexed PNG as 8bpp indexed Bitmap It will be available in 5.4.4. 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.
A polite ping to Tor Lillqvist: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
I would say so, yes.
(Even if I did not actually fix the problem, but instead implement a workaround... No doubt some day somebody will complain that the workaround wastes memory (as it does). So sue me.)