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.