Description: I insert an png-image in a Writer file with big transparent (alpha channel Gimp) borders. Then I right-click on it and choose /line wrap/contour from the context-menu. Now LibreOffice used to understand that the 100% transparent borders could be overwritten with text. But it doesn't understand that no more. All images stay rectangular the way the were in the first place. Then I start the "contour editor" and start autocontour. That also does nothing. Steps to Reproduce: 1. try to contour wrap 2. LO doesn't guess contour at first site no more 3. Contour editor auto function also broken Actual Results: All images keep their original rectangular contour. In other words contour wrap does nothing Expected Results: Libreoffice tries to guess contour to wrap. This used to work fine. In all other cases the contour editor could help but the "auto" function of that seems to be totally broken Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: nl-NL (nl_NL.UTF-8); UI: nl-NL Ubuntu package version: 4:24.2.4~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-35-generic (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 Manufacturer: Dell Inc. Product Name: Latitude 5480
Created attachment 194634 [details] to the autocontour function is rectangular I selected an elips in this image in Gimp. Then I inverted the selection and removed the border. I added an alpha channel layer and saved it as png. Contour wrap sees the image as rectangular.
I tried on a Windows machine with a recent version of LibreOffice. It behaved the same as my linux machine. No autocontour function.
Created attachment 194638 [details] image with 100% transparent border. Text wrap contour activated. This is a screenshot of LO with an inserted image with 100% transparent border and 0% transparent center. LO sees this image as rectangular. Years ago I also worked with this functionality and then LO behaved as expected and wrapped the text around the ellipse.
Thanks for the report, I can see that regression. In LO 7.6, using Wrap > Edit contour > Autocontour allows wrapping around the oval area. Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded It does not work anymore in: Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
I can also reproduce this on macOS in my local master build: Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 68e7413b5f9ce4abd2a4e23bf27cfc335e52f03f CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded I am curious if a bibisect points to the switch from transparency to alpha in bitmaps that was added in 24.2.
(In reply to Patrick Luby (volunteer) from comment #5) > I am curious if a bibisect points to the switch from transparency to alpha > in bitmaps that was added in 24.2. Did a git bisect and looks like that is the cause: 81994cb2b8b32453a92bcb011830fcb884f22ff3 is the first bad commit commit 81994cb2b8b32453a92bcb011830fcb884f22ff3 Author: Noel Grandin <noelgrandin@gmail.com> Date: Fri Apr 16 20:33:10 2021 +0200 I am guessing that somewhere in the LibreOffice code, the pixels in the image are examined and the transparent pixels identified (i.e. create an alpha mask). But the transparency values are now flipped so the existing code sees the opaque image area as transparent and the transparent image area as opaque. I don't know where the code is so I will see if can locate the code that handle's finding the image's transparent area. I'll post again when I have more news.
(In reply to Patrick Luby (volunteer) from comment #6) > (In reply to Patrick Luby (volunteer) from comment #5) > > I am curious if a bibisect points to the switch from transparency to alpha > > in bitmaps that was added in 24.2. > > Did a git bisect and looks like that is the cause: > 81994cb2b8b32453a92bcb011830fcb884f22ff3 Confirmed that it started with 81994cb2b8b32453a92bcb011830fcb884f22ff3 (build [c21a1c45e2403119c90af25cdb5350f978d5c93b] in linux-64-24.2 bibisect repo). Thanks for looking into it, Patrick.
(In reply to Patrick Luby (volunteer) from comment #6) > I am guessing that somewhere in the LibreOffice code, the pixels in the > image are examined and the transparent pixels identified (i.e. create an > alpha mask). But the transparency values are now flipped so the existing > code sees the opaque image area as transparent and the transparent image > area as opaque. I think that I have found the code and I have submitted the following patch: https://gerrit.libreoffice.org/c/core/+/169654
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1ac602f6ccd75f3b79d6c7a9d40e64677dd5741a tdf#161498 use COL_ALPHA_OPAQUE for finding opaque pixels It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have committed a fix this bug. The fix should be in tomorrow's (28 June 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/8590499c1f382244155624cd3f712d0894faaa2b tdf#161498 use COL_ALPHA_OPAQUE for finding opaque pixels It will be available in 24.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 195030 [details] contour function imho completely working as expected The contour function is now working as expected. But scrolling in the document of the screenshot really goes slow. And that doesn't change when I not use the contour function. (I hope the qt6 vcl plugin will be in master soon!)
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/bed03b80139322dc361291eed76345acc8be9e5c tdf#161498 use COL_ALPHA_OPAQUE for finding opaque pixels It will be available in 24.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to pieter kristensen from comment #12) > Created attachment 195030 [details] > contour function imho completely working as expected > > The contour function is now working as expected. But scrolling in the > document of the screenshot really goes slow. And that doesn't change when I > not use the contour function. > (I hope the qt6 vcl plugin will be in master soon!) I don't see this. On macOS when scrolling using the trackpad or dragging the scrollbar through the wrapped image. So that sounds like a separate, Linux-only bug. But I am not a Linux developer so I don't know.
(In reply to Patrick Luby (volunteer) from comment #14) > (In reply to pieter kristensen from comment #12) > > Created attachment 195030 [details] > > contour function imho completely working as expected > > > > The contour function is now working as expected. But scrolling in the > > document of the screenshot really goes slow. And that doesn't change when I > > not use the contour function. > > (I hope the qt6 vcl plugin will be in master soon!) > > I don't see this. On macOS when scrolling using the trackpad or dragging the > scrollbar through the wrapped image. So that sounds like a separate, > Linux-only bug. But I am not a Linux developer so I don't know. Thank you for your reply. LibreOffice is great!