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
- 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
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
Author: Caolán McNamara <firstname.lastname@example.org>
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 220.127.116.11)]" 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:
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)
- 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: 18.104.22.168.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?
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 22.214.171.124, 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 126.96.36.199, I suspect this bug is now, at the very least, out of date.
@Michael: Sounds like a reasonable approach. Again, as of 188.8.131.52, 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)