Description: I am a .NET developer and I currently work on a reporting project that involves extracting data from M. Office files and convert them in a new ODF format as ODT and ODS using IndependentSoft ODF API. I've completed a test file from simple txt to ODT. The initial text file include a table formed of 55 columns and 4000-5000 rows. I'm extracting just some specific columns from there and do some processing background (concatenate some columns) and the final output is an ODT of no more than 700 kb. The issue is when I open the file with LibreOffice it takes around 6 seconds to open but freezes(can't scroll) until fully loads the table (around 8-10 minutes). But when same file is open with M. Word or ODTViewer is only takes just a couple of seconds and is loading smoothly in background while I can scroll and is fully responsive I found that the issue is on styling the document. As per data population there is no problem. So I thought there could be some style to override or some patch, dll to include on my project Steps to Reproduce: 1. ODT developed in .NET and IndependentSoft API 2. Take 6 seconds to open but Not Respondint until fully loaded 8-10 minutes 3. Every time when I open with LO Writer is the same issue Actual Results: The opening time is huge Expected Results: Normal opening time (few seconds) Reproducible: Always User Profile Reset: No Additional Info: If I save a copy in M. Word still as ODT extension it triples in size but open in normal time in LO Writer
Created attachment 161832 [details] The ODT created in .NET with IndependentSoft ODF API
Did you give a try to 6.4.4? Indeed even if 6.3.6 is slow, 6.3 branch is EOL (see https://wiki.documentfoundation.org/ReleasePlan/6.3) so it won't be a 6.3.7 version.
I killed LibreOffice after real 6m56,595s user 6m53,482s sys 0m2,790s Version: 7.1.0.0.alpha0+ Build ID: 0de191e1d201d691c2196cf1aef412a98affb66f CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
@Regina, if you have a moment, could you please doublecheck the document attached ?
Also reproducible in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Created attachment 164158 [details] Document opened with Word 365 and resaved in ODF format The validator shows three error. 1) root: The file 'mimetype' shall not be compressed in the ODF package 'LO 133856 newDOC.odt'! 2) manifest.xml: element "manifest:manifest" is missing "version" attribute 3) content.xml: element "office:document-content" is missing "version" attribute Error 2) exists in the resaved document too and is ignored by LibreOffice. Errors 1) and 3) are removed by Word. The resaved file opens in LibreOffice. The file has one table with 7 columns and 4470 rows ! That results in one table covering 338 pages. There is indeed a problem with such large tables. First opening does not get the correct number of pages. Switching to Web view and back to Normal view brings the correct number. Word opens it quickly, but that is misleading. It prepares the first page to show it to the user and you will see delay when scrolling through the document. I don't now for sure, but I think, LibreOffice first goes through all pages and then presents it to the user. So there are three problems: LibreOffice should be more tolerant with packing errors and version attribute errors. We should re-think about the opening process, and consider showing preliminary results to the user. LibreOffice needs better performance with large tables. Bug 132206, bug 126788 and bug 125171 might be related. [I have not yet tried to open the original file, that will follow.]
Opening lasts 13 min here, tested with Version: 7.0.0.2 (x64) Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL It has 317 pages. Switching to Web view is quick but switching back to Normal view has performance problems too. Therefore I suspect the algorithm for calculating page breaks in tables.
Dear Remus, 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
Repro 25.8+. Not sure this can be easily resolved, due to explained reasons and the way that LO processes the full file, while Word first shows the 1st page.