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.