<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - When calling LibreOffice in server mode to update the TOC of a large document, the page numbers in the TOC are wrong"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=121799">121799</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>When calling LibreOffice in server mode to update the TOC of a large document, the page numbers in the TOC are wrong
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>5.1 all versions
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>sdk
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>gaetan.delannay@geezteem.com
</td>
</tr></table>
<p>
<div>
<pre>Description:
Context: I am the developer of appy.pod, a Python library using LibreOffice in
server mode via UNO (<a href="http://appyframework.org/pod.html">http://appyframework.org/pod.html</a>). 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 <a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - When calling LibreOffice in server mode via UNO, the produced ODT document may have, in meta.xml, a meta:page-count="1" for a document containing 2 pages."
href="show_bug.cgi?id=121796">bug #121796</a> 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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>