Newly created Libre Writer file could not be opened 1) I saved from PSPPire (stat progam) a factor analysis - dont worry sensitive info is deleted. -Note that I do many factor analysis, and writer opened ALL these documents without any problem. 2) This particular file is refused to be opened (it is halted) by libre writer - I do not know why - weird characters dont play a role - in that place existed text that i deleted - even with text could not be opened (halted). Due to the size of attachment, please download from here: Available ~1 Month. Elsewhere to upload it? https://ufile.io/3mlqtj7f Note: Either experimental features on or off, nothing changed, same behaviour.
Note: (is it a bug?) The smae file in Calc requires 122.4kb while in Writer 2.0MB!!!!
It doesn't "halt"; it opens OK, and then it "freezes" for quite a significant time, before it finally gets normally responsive - after it had layed out the three tables in the middle, each having 50+ columns, 100+ rows, and the first row in each having a *long* text in the last column. Given the size of the page (A4), the size of the text (12 pt), and the number of columns, thie indeed makes the first row *quite tall* (almost the whole page area). Add here the fact that the three tables *repeat the first row* at every page, and you get the tables spanning hundreds of pages, where each page has the "header" taking almost all the page, and a single "data row". I don't know if it's possible to do something reasonable with such a corner case. However, if a performance improvement could be done - it would be definitely nice.
Created attachment 174896 [details] The file by link from description
So, I opened the file in Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL 1. LO opens file so fast 2. LO took 100% of one CPU core during around 1 minute and I had delays while tried scroll the document 3. Afer 1 minute I could scroll it fast and smooth but still had 100% loading of one CPU core I see different number of pages in 7.2 (314) and in 7.3 (294) and I don't know where is more correct Julien, could you please create a flamegraph for first minute after opening the file? May be Noel (or someone) will do else one miracle =)
Created attachment 174897 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today + gen rendering. I waited for 1 or 2 minutes from the moment I start opening the file (I had previously opened Writer).
No repro, when I had to wait, it was just a few seconds. Version: 7.1.0.0.alpha1+ (x64) Build ID: 738bcf5e9a8c443d60c29c3a8068e8c16c72638a CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: df3b95a39472e18ea8acdaae447b7176e37a9256 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded But, I also see a big difference in the number of pages. Version 7.1.0 - 210 pages Version 7.3.0 - 314 pages Version 24.2.0 - 219 pages
With master sources updated today or with LO Debian package 7.5.5 with gen rendering (to avoid accessibility part), it's still very slow for me when scrolling and still 100% CPU.
Dear elias estatistics, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
LO is detecting the file as broken (reported here bug id=153364). Unzipped, zipped, fixed. odt file open to my new machine instantly. HOWEVER, even in this machine, with ssd, when tabing windows, and returning to writer file, it is not "loading" (unrensponsive). CPU: 12-core AMD Ryzen 9 5900X (-MT MCP-) speed/min/max: 3693/550/4951 MHz Kernel: 6.12.38+deb13-amd64 x86_64 Up: 11m Mem: 3.7/31.27 GiB (11.8%) Storage: 11.87 TiB (34.5% used) Procs: 490 Shell: Bash inxi: 3.3.38 linux, trixie, Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 24; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Debian package version: 4:25.2.3-2 Calc: threaded
Note that ebook viewer open it instantly but with bad formatting (overlapping text).
You asked if something better can be done? YES! When i made font from 12 to 4 size, it occupied from 294 pages to only 6 pages. If you can make an algorithm, that it can detect that multipage tables (>3-4 pages) can cover significantly less writer pages with smaller font, then you can ask the user if he/she would like to do this eg. do you like to make font smaller (from 12 to 4) in order document to open faster for only large multipage tables? You may give users the option to auto enable maybe. In order to keep relative formatting, if exists, you must create an algorithm that will increase/decrease fonts relatively eg. if table has fonts for heading 20 and for cells 12, you may use 8 decreased points eg. 12 and 4. Then, if user like to have the original font size, he/she may transform them back with a single option. Or maybe you can apply this filter without caring for relative formatting, or only if it is detected that large multipage tables have a single font size.