| Summary: | 1bpp non-B&W PNG images are mishandled on Linux in all vcl "backends" ("plugins") | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | How can I remove my account? <tml> |
| Component: | graphics stack | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aron.budea, ilmari.lauhakangas, vsfoote, xiscofauli |
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=103833 https://bugs.documentfoundation.org/show_bug.cgi?id=115863 https://bugs.documentfoundation.org/show_bug.cgi?id=115297 |
||
| Whiteboard: | target:6.0.0 target:5.4.4 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: | bug doc | ||
|
Description
How can I remove my account?
2017-11-18 16:24:51 UTC
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.) |