Bug 41013 - Incorrect pagination when document initially loaded
Summary: Incorrect pagination when document initially loaded
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Keywords: perf, regression
Depends on:
Reported: 2011-09-19 10:02 UTC by Kevin Hunter
Modified: 2015-12-15 11:05 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Word produced docx creates pagination issues in LO. (118.54 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2011-09-19 10:02 UTC, Kevin Hunter

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Hunter 2011-09-19 10:02:49 UTC
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

Will include pertinent git information in first comment.
Comment 1 Kevin Hunter 2011-09-19 10:03:27 UTC
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
Comment 2 Rainer Bielefeld Retired 2011-09-20 02:31:51 UTC
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]" 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.
Comment 3 Björn Michaelsen 2011-12-23 12:40:33 UTC
[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
Comment 4 Kevin Hunter 2011-12-24 12:04:00 UTC
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.
Comment 5 Kevin Hunter 2011-12-24 12:04:57 UTC
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)
Comment 6 Christina Rossmanith 2012-01-21 13:45:55 UTC
LibreOffice 3.5.0rc1 
Build-ID: b6c8ba5-8c0b455-0b5e650-d7f0dd3-b100c87

- 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
Comment 7 s-joyemusequna 2012-11-29 12:34:53 UTC
This problem is present in DOCX and RTF files, but not in DOC and ODT files, starting with LibO 3.5.x.
Comment 8 Jorendc 2013-05-29 21:47:24 UTC
I can not reproduce this behavior using Linux Mint 15 x64 with LibreOffice Version:
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,
Comment 9 Michael Stahl (allotropia) 2013-08-29 22:05:23 UTC
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.
Comment 10 Kevin Hunter 2013-08-30 11:39:47 UTC
@Jorendc: Apologies, I apparently lost this email in my stack and never checked back.  As of, 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, I suspect this bug is now, at the very least, out of date.

@Michael: Sounds like a reasonable approach.  Again, as of, 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).
Comment 11 Kevin Hunter 2013-08-30 11:59:13 UTC
@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 ...
Comment 12 Robinson Tryon (qubit) 2015-12-15 11:05:12 UTC
Migrating Whiteboard tags to Keywords: (perf)