[Libreoffice-bugs] [Bug 121799] New: When calling LibreOffice in server mode to update the TOC of a large document, the page numbers in the TOC are wrong

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Thu Nov 29 11:03:58 UTC 2018


https://bugs.documentfoundation.org/show_bug.cgi?id=121799

            Bug ID: 121799
           Summary: When calling LibreOffice in server mode to update the
                    TOC of a large document, the page numbers in the TOC
                    are wrong
           Product: LibreOffice
           Version: 5.1 all versions
          Hardware: All
                OS: Linux (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: sdk
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: gaetan.delannay at geezteem.com

Description:
Context: I am the developer of appy.pod, a Python library using LibreOffice in
server mode via UNO (http://appyframework.org/pod.html). appy.pod allows to
define "ODT templates" being ODT documents misusing fields and notes by filling
them with Python code. Such a template is pre-processed by appy.pod, and the
result, a "pure" ODT document, is then sent to LibreOffice via UNO to apply
some changes, like recomputing the table of contents and indexes, optimizing
tables columns widths, resolving sections tied to other ODT documents, etc.

A large ODT document (between 100 and 300 pages) is loaded by LibreOffice via
UNO. Then, appy.pod asks via UNO to update the table of contents, then to save
the result on disk.

The table of contents contains wrong page numbers. For instance, if the
document is made of 130 pages, the table of contents will be complete, but page
numbers besides titles will range from 1 to 80.

Steps to Reproduce:
1. Create a pod template with appy.pod, containing a table of contents.
2. Call appy.pod Renderer to create a large file based on this template
(between 100 and 300 pages)
3. Ask LibreOffice via UNO to update the table of contents
4. Ask LibreOffice to save the result on disk.

Actual Results:
Within the table of contents, sometimes, the page numbers besides the titles
are wrong.

Expected Results:
Within the table of contents, the page numbers besides the titles should
correspond to the actual pages where titles lie.


Reproducible: Sometimes


User Profile Reset: No



Additional Info:
It seems that LibreOffice, when loading an ODT document, be it via UNO or the
graphical user interface (GUI), does not load it at once, completely. I suppose
this is a feature allowing the user to start manipulating the partially loaded
document, while the remaining is loaded in the background. Indeed, I observed
that, when loading a large document via the GUI, the page counter (in the
bottom left corner) indicates a wrong number of pages. After a while, this
counter increments itself until it reaches the correct page number.

This behaviour has been observed on LibreOffice 5.1 and
6.1.3~rc2-0ubuntu0.18.04.2.

I suppose that this mechanism may be responsible for producing wrong page
numbers, as explained hereafter, and could maybe explain bug #121796 also
reported by myself.

1. LibreOffice loads the document via UNO, but partially (let's say, the first
80 pages)
2. The UNO command for updating the table of contents is executed at this
moment: the table of contents contains wrong numbers, from 1 to 80.
3. After a while, the remaining of the document is loaded and saved to disk,
but includes a table of contents containing wrong page numbers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20181129/e77ece95/attachment.html>


More information about the Libreoffice-bugs mailing list