Created attachment 193352 [details] Problem Files The 2 files attached are created with Libre Office Calc. If selected Print Preview they freeze the program. I've tried them on several computers and different versions of Libre Calc,same results. I've tried saving with different extensions also (ods, xlsx), to no avail. Why is this?
Confirm Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0020fc1167b3760d0631001689a44427b72b816e CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL threaded and with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4bb730be0909d9cf55b7a44d7e916aa5de16b9f7 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and with Version: 7.3.8.0.0+ (x64) / LibreOffice Community Build ID: e1ad83ddb2f39419fb5d7c69eba51e2b9f49c788 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Jumbo -> it's slow with jumbo sheets turned ON. Fast with Jumbo Sheets turned OFF
Seems the issue is with having merged the whole first row, not only a few cells. And at the same time having active Menu/Tools/Options/LibreOffice Calc/Print — Suppress output of empty pages. And Menu/Format/Print ranges/Edit the entire sheet. Calc try to know what are the empty pages, not data, but with the first cell in all column as part of merged range. I think really a very corner case.
@stragu Any idea what being advisable here. Jumbo sheets is the default since couple of releases. Should clicking row header really select every column from A1:XFD1. And clicking a column select every all rows A1:A1048576. Not range a typical end-user uses, IMHO. The mistake is easily made, IMHO. With serve consequences. Perf issues like here or large file size, if direct formatting being applied to a large range of cells. Approaches * fix the performance issue (profile point to mdds; Multi-Dimensional Data Structure in this case) * "blame" the end-user for using the tool wrong * Improve UX in some way the prevent selecting large ranges unintentionally. Make it a bit harder
Whatever the solution, the issue has been confirmed and we don't want it to persist. I wouldn't blame the user, I can understand why one could end up in this situation, to have some kind of "top-level heading" that looks solid for the whole width of the spreadsheet. Let's see if developers can give an opinion, and tag a "perf" to ping anyone interested. Repro in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1344e6261a1d856c71eca1e0cc29215a586bf335 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
The issue occured by a friend of mine. I'm her 'Helpdesk'. The strange thing is that 'Softmaker Freeoffice' has no problem with these files.....
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3819e4f6f70ee60fc5c805f0d33c0062a396918c tdf#160399 speed up print preview It will be available in 24.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6931a596350086d52ba32bf8a84cb36fbfdb34d6 tdf#160399 speed up print preview It will be available in 24.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.
Thanks for the patch List of observations A) It's loading faster now, however still a lag +/- 10 seconds B) A single press on + or - is already slow (same 10 seconds). It freezes when using the scale slider of the print preview. C) The render print preview simply stops on macOS (at least) when switching tasks (goes to idle). Process continuing when LibreOffice has focus again; so you're forced to actively wait D) Delete row 1 takes 22 seconds; but this surely a different bug based on instruments perf profile Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aef28c23adc87b8e26eacb56c7dbcf652e907fb9 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e1e48bba55ff68397d514ab3771850678312f348 tdf#160399 speed up print preview It will be available in 24.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2ad14abcf790002ac6fe09afbc5a2cae46f62085 tdf#160399 speed up print preview It will be available in 24.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/8f53eb5dc5cc7f90a2b134c5b5ad66988bcc9842 tdf#160399 speed up print preview It will be available in 24.2.3. 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.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/02b100e8ecbe47bd8d70d81dbefcb24be0501b8b tdf#160399 speed up print preview It will be available in 24.2.3. 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.
@Stéphane Guillou Would you mind to test this? It's still slow for me regardless all the effort put into it on Windows - similar as described in comment 8 - when using "Deelnemers en Plaatsnummers Fout" (I haven't retested it on mac) Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 748561425774fa40ab685fed80d113f7e8301158 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded