Created attachment 51359 [details] Word produced docx creates pagination issues in LO. I'm not entirely sure how to describe this bug, but I think these symptoms are all related to pagination. I'm also not sure if it's even a bug as opposed to an issue of pagination between office suites. I thought reporting was the better part of valor. This example document initially loads with LO displaying 11 pages in the status bar, while it should display 18. Note that it is a DocX format and was produced with Word 2007. (I don't know if the file is "correct" or not, but OpenOffice 3.2 opens it at 11 pages as well, but almost instantly updates to 18 pages.) - When I individually scroll through the pages via the PgDn key on my keyboard, LO updates its count to 16, then 18 pages (the last being correct.) - If I reload the document, the apparent internal notion resets to 11 pages (as noted via the status bar). - If I hit Ctrl+End to go the end of the document, LO reduces its internal notion of the document to 10 pages, then slowly updates to 18, while also jumping to the actual page 10, instead of leaving me at the final page. - If I print while the status bar indicates that there are only 11 pages, then only the first 11 pages of the document are printed out (to paper). (I noted this behavior with an earlier git checkout. If I'm quick enough, I can repeat these results currently. Otherwise, the pagination update after 20+ seconds seems to correct the issue.) - Anything that forces an actual pagination corrects the page count: export as pdf, print preview. - If I wait long enough (20+ seconds), LO updates the pagination. Will include pertinent git information in first comment.
This symptom is against the master branch of the core-git repository: ----- $ git branch; echo =====; git log -1 * master ===== commit 2c17f1196394a7fd56fe0d807146c110c5ae741a Author: Caolán McNamara <caolanm@redhat.com> Date: Mon Sep 19 11:23:03 2011 +0100 despite its name, it appears not to be a gui app $ hash -r ; \ gcc --version | head -1 ; \ g++ --version | head -1 gcc (GCC) 4.6.1 g++ (GCC) 4.6.1 $ uname -a Linux hani 2.6.35-30-generic #59-Ubuntu SMP Tue Aug 30 19:00:03 UTC 2011 x86_64 GNU/Linux -----
I would be glad if I only would have a pagination issue, most of my LibOs crash when I try to open the sample document. "LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 3.3.3.1)]" opens the sample, shows 11 pages for a moment, counts up and reaches 18 pages after few seconds. So this issue would be a regression. Other libO versions that do not crash show only 6 or 7 pages, page number will not be updated, it seems contents is crippled.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I believe this to still be an issue, but need someone else to confirm this. > Other libO versions that do not crash show only 6 or 7 pages, page number will > not be updated, it seems contents is crippled. I cannot confirm or deny this, but will point out that MS Word appears to read this file just fine, and print correctly as well.
Sorry, forgot to mention that I've checked with a LO 3.5 beta build: $ git log -1 --format=oneline 7dfc54c7337f77be8e258a218df741c330904f73 support libebook-1.2.so.12 (evolution 3.2)
LibreOffice 3.5.0rc1 Build-ID: b6c8ba5-8c0b455-0b5e650-d7f0dd3-b100c87 Linux - when opening the test document LibO shows 11 pages and after a little moment (~10 sec) the number is updated to 18 automatically - hitting Ctrl-End shows the last page and it is page 18 - if I try to print during the short period of 11 pages being shown "Neuformatierung..." (Reformatting) appears in the status bar and the print dialog correctly shows 18 pages
This problem is present in DOCX and RTF files, but not in DOC and ODT files, starting with LibO 3.5.x.
I can not reproduce this behavior using Linux Mint 15 x64 with LibreOffice Version: 4.2.0.0.alpha0+ Build ID: c7da99f37197fb1446af07f17ba33978f15e7f6 Opening the sample document result indeed in 11 pages, at first. When I wait about 8 seconds longer, pagenumber is counting up until 18 (takes 12 seconds from initially loading until 18 pages)... Looks to me this behavior is improved. @Kevin: can you confirm that? Kind regards, Joren
cannot reproduce a performance problem as serious as the description implies. generally Writer will layout the document lazily in an idle handler (unless it is really small) so the incorrect page count directly after loading is expected. but i cannot see a big difference in the time until the page count converges between versions, OOo 3.3 and LO 3.4.6 took maybe 5 seconds and LO 3.6.7 maybe 6 and LO 4.0.x and master maybe 8 (but the latter (4.x) are dbgutil versions without opt whereas the previous ones are release builds so i guess that is expected). alas it appears rendering of the included graphics has regressed, i'll file separate bugs about that.
@Jorendc: Apologies, I apparently lost this email in my stack and never checked back. As of 4.0.2.2, I note what Michael just described: pagination starts at 11, and the updates in a background thread to the correct 18 pages over the course of ~5 seconds. As master is a good bit further along that 4.0.2.2, I suspect this bug is now, at the very least, out of date. @Michael: Sounds like a reasonable approach. Again, as of 4.0.2.2, the graphic is not complete, but I think I already have a bug about that. See Bug #41068 "partially displayed embedded image" (that references this bug's attachment).
@Michael: And as I work my through email, I see you've already included it here. Sigh. Here's to completing one's email stack before responding ...
Migrating Whiteboard tags to Keywords: (perf) [NinjaEdit]