Description: It seems that in PDF export, when JPG compression is enabled, objects with linear transparency are masked in the opposite way than they should be. Steps to Reproduce: 1. Open attached sample Draw file. 2. Export it to PDF with default settings. Result shuld be as attached file "Opacity test, exported with lossless compression" 3. Export again with JPG-compression enabled. Result shuld be as attached file: "Opacity test, exported with JPG-compression". See the inverted result. Actual Results: Currently the linear transparency in opposite. Expected Results: The desired result is what you see when editing the drawing. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded
Created attachment 197988 [details] Test file
Created attachment 197989 [details] Good export
Created attachment 197990 [details] Wrong export
Reproducible Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0f3f3710280d2476425bb86bc2e065e3e7a82952 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Latest version that works on the ones I have installed. Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 16; OS: Windows 10.0 Build 26100; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
bibisected with win64-24.2 first bad commit source 462f1c43cc97eb5c13343f285516702aa0c47a8d I didn't reproduce it below because it involves skia. Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL threaded Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded I don't know if it's on a Mac.
Could someone add Patrick here on CC list? commit 462f1c43cc97eb5c13343f285516702aa0c47a8d [log] author Patrick Luby <plubius@neooffice.org> Wed Aug 23 17:22:55 2023 -0400 committer Patrick Luby <plubius@neooffice.org> Thu Aug 24 15:14:43 2023 +0200 tree e0897d553d6547b9ff8809afaf099e31e3854022 parent edf922a05be1d9626164e9f07c2ed1826d039d95 [diff] tdf#156866 use mSize instead of mPixelSize for inverted surface Commit 5baac4e53128d3c0fc73b9918dc9a9c2777ace08 switched to setting the surface size to mPixelsSize in an attempt to avoid downscaling mImage but since it causes tdf#156866, revert back to setting the surface size to mSize. Also, in release builds, tdf#156629 and tdf#156630 reappear in many cases because a BitmapInfoAccess is in a debug block. So, instead of relying on other code to a create a BitmapInfoAccess instance, create one here to force the alpha mask to handle any pending scaling and make the alpha mask immutable. Change-Id: If9f0dfb7b9a82cf7a3e402965ceffd42eace4c82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156022 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Patrick Luby <plubius@neooffice.org>
Created attachment 198759 [details] Opacity test, exported on macOS with JPG-compression Reproducible on macOS with Version: 24.8.4.2 (AARCH64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 8; OS: macOS 15.2; UI render: default; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Interestingly, on my Mac, the 'Wrong Export' Attachment provided by Gellért Gyuris displays the green 'OK' area when viewed with Preview.app but the red 'wrong' area with Acrobat Reader. I'm attaching the 'wrong' version I've just generated by enabling jpeg compression. This bug may explain why inserted pdf images sometime don't survive pdf export with compression on.
Sorry, clicked 'Save' too soon... The 'wrong' pdf generated on my Mac, when viewed on my Mac, displays the red 'Wrong' area when viewed with preview but the green 'OK' area when viewed with Acrobat Reader. This is the reverse of the behaviour I see with Gellért Gyuris's original 'Wrong Export' demo file, which seems to have been generated on Windows.
I have uploaded a fix for this bug in the following patch: https://gerrit.libreoffice.org/c/core/+/180746 Once it passes the automated tests, I will commit it and I will post instructions for testing this fix.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5e03f4d40c14cc79b1f3f790955196a31eec5d3c tdf#164223 invert alpha mask for JPEG images It will be available in 25.8.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 for this bug. The fix should be in tomorrow's (25 January 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app