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.
The print dialog opens at the expected speed. But the double-sided print setting appears to be being ignored. (Bug https://bugs.documentfoundation.org/show_bug.cgi?id=163126 is still present, but that was to be expected.)
(In reply to James R from comment #10) > The print dialog opens at the expected speed. But the double-sided print > setting appears to be being ignored. (Bug > https://bugs.documentfoundation.org/show_bug.cgi?id=163126 is still present, > but that was to be expected.) That is pretty strange that double-sided printing is ignored. I assume that double-sided is a post-processing step done by your printer's print driver (although I think some print drivers are bundled with macOS). My understanding of macOS printing is there a pipeline of steps and each step is handled by separate LibreOffice, macOS, or print driver code: 1. LibreOffice requests macOS to start a print job. 2. macOS creates a temporary PDF and LibreOffice adds the document's contents to the PDF. Note: this is the step where my fix for this bug was implemented. We are now adding content to the PDF faster. 3. macOS displays the native print dialog and displays the PDF in the sidepane on the left. 4. If you then change any of the print settings (except those in the "LibreOffice" section), macOS does some post processing on the PDF. For example, changing Layout > Pages per Sheet causes macOS to immediately post-process the PDF and update the sidebar on the left. 5. Finally, if you actually send the output to a printer, post processing is done by the print driver for things like double-sided since PDF has no concept of double-sided. PDF is just a list of pages. Unfortunately, my print driver (I only have the RWTS "print to PDF file" printer) does not support double-sided so macOS hides that print dialog section when I print. So does double-sided work in NeoOffice if you use the same print dialog settings as in LibreOffice? If so, then maybe there is some hope that the bug is in the LibreOffice code. Of course, then the bigger mystery is how is LibreOffice able to influence a print driver post processing step.
FWIW, I tested opening the problematic file in Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 2f5e75ed134cfd0224e03411ca9d7d81f319c91b CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded The print dialog opens nearly instantaneously for me. Double-sided printing also works for me (my printer at home is a HP Pagewide Pro 477dw MFP), although the printed output appears cut off across the A4 page (presumably this the brochure format issue bug 163126?), even if I choose the short edge double sided option, Brochure option ticked. The print preview in the macOS print dialog shows the correct representation, and if I save to PDF from this dialog, I get the intended brochure layout, so there appears to be something wrong with the way LibreOffice processes the instructions. I'll add my comments to bug 163126.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/797ab1fa1f9bf97fd2560d6c2feeafd04b735351 tdf#164354 skip unnecessary transparency removal when printing It will be available in 24.8.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.
I have now tested the latest build (libreoffice-24-8/MacOSX-x86_64@tb92-TDF/2025-01-09_04.27.52/) and brochure printing is now working correctly. Thank you very much. The only oddity is that when the print dialog comes up, if I click the Brochure checkbox to toggle it either off or on, the print dialog simply closes. If i reinvoke the Print command the dialog reappears with the correct new brochure setting which I have just applied.
I'm sorry my previous comment has been posted against the wrong bug. I will repost it to Bug 163126 where it belongs