Description: The attached document created and edited in LibreOffice prints without difficulty in 2022.7 Professional Edition, but invoking Print either via the file menu or the toolbar always causes LibreOffice to freeze. Steps to Reproduce: 1.Open document in LibrOffice 2.Click Print icon in toolbar or use Command-P, or choose Print from the file menu 3. Actual Results: LibreOffice freezes - spinning beach ball. Expected Results: Should have opened th Print dialog to select options for printing Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: macOS 14.6.1; UI render: Skia/Raster; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 198156 [details] This is the document which causes LibreOffice to freeze on attempting to print
For me, it takes about 30 seconds are so for the native Print dialog to appear with LibreOffice 24.8.3: Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded I don't see such slowness with other files so I am guessing that the Writer code has some performance bottleneck during page layout. Is anyone seeing this slowness on Windows or Linux? Or is this a macOS-only bug?
There is a missing word in my opening sentence, which should read “ The attached document created and edited in LibreOffice prints without difficulty in NeoOfgice 2022.7”
Created attachment 198171 [details] Snapshot of time profile in the Instruments application during wait for Print dialog to appear I did a time profile using Xcode's Instruments application and the performance bottleneck appears to be in OutputDevice::RemoveTransparenciesFromMetaFile() so my original guess that the bottleneck is in Writer was wrong. Instead it is in the cross-platform vcl code. My memory is a bit hazy, but IIRC the above function combines all semi-transparent objects on a page and draw them to a single bitmap. I can't remember if I made any changes in this code for NeoOffice or if this "just worked" in LibreOffice 4.4 (the version of LibreOffice that NeoOffice is based on). When I get some time, I'll look and see if there were any changes to the above function in either NeoOffice or in LibreOffice after LibreOffice 4.4.
I have searched in gerrit for (In reply to Patrick (volunteer) from comment #4) > > When I get some time, I'll look and see if there were any changes to the > above function in either NeoOffice or in LibreOffice after LibreOffice 4.4. I have searched in gerrit for RemoveTransparenciesFromMetaFile() and there are 4 changes from 2020 and 2021. https://gerrit.libreoffice.org/c/core/+/114019 https://gerrit.libreoffice.org/c/core/+/113992 https://gerrit.libreoffice.org/c/core/+/113981 https://gerrit.libreoffice.org/c/core/+/86312
@BogdanB Thank you for the links! I started with reading through the NeoOffice code and NeoOffice skips OutputDevice::RemoveTransparenciesFromMetaFile() and draws alpha objects directly to the print graphics so I copied the NeoOffice changes into the following patch: https://gerrit.libreoffice.org/c/core/+/178818 There is still one case where OutputDevice::RemoveTransparenciesFromMetaFile() will be called: if you check both "Reduce Transparency" and "No Transparency" in the LibreOffice's print settings. Apparently on macOS OutputDevice::RemoveTransparenciesFromMetaFile() is needed to remove all transparency but not for anything else. The interesting thing to me is that Windows and Linux expect the opposite behavior: OutputDevice::RemoveTransparenciesFromMetaFile() is called when neither "Reduce Transparency" nor "No Transparency" are checked. I guess drawing semi-transparent objects on Window and Linux printers is a completely different process than on macOS.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fa3dd1c3a190fcbead9d39038a30f0fd306a1baa tdf#164354 skip unnecessary transparency removal when printing 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 (19 December 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Important 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
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/6966db05a83dc1e7ca2768d811776fcace50ecc3 tdf#164354 skip unnecessary transparency removal when printing It will be available in 25.2.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.