<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - ODT file developed in .NET take 8-10 minutes to open in LO Writer as compared to Word just take few seconds" href="https://bugs.documentfoundation.org/show_bug.cgi?id=133856#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - ODT file developed in .NET take 8-10 minutes to open in LO Writer as compared to Word just take few seconds" href="https://bugs.documentfoundation.org/show_bug.cgi?id=133856">bug 133856</a> from <a class="email" href="mailto:rb.henschel@t-online.de" title="Regina Henschel <rb.henschel@t-online.de>"> Regina Henschel</a> <pre>Created <a href="http://bugs.documentfoundation.org/attachment.cgi?id=164158" name="attach_164158" title="Document opened with Word 365 and resaved in ODF format">attachment 164158</a> <a href="http://bugs.documentfoundation.org/attachment.cgi?id=164158&action=edit" title="Document opened with Word 365 and resaved in ODF format">[details]</a> 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. <a class="bz_bug_link bz_status_NEW " title="NEW - Slow selecting a large multi-page table" href="show_bug.cgi?id=132206">Bug 132206</a>, <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - FILEOPEN: ODT big performance drop for big table from 6.1 to 6.2 to 6.3" href="show_bug.cgi?id=126788">bug 126788</a> and <a class="bz_bug_link bz_status_NEW " title="NEW - Writer FILEOPEN, FORMATTING, VIEWING: very slow, hanging when opening files with complex tables" href="show_bug.cgi?id=125171">bug 125171</a> might be related. [I have not yet tried to open the original file, that will follow.]</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>