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.

The test case: we create, with appy.pod, a master POD template made of hundreds of sub-documents (=sections linked to sub-ODT documents, that will be resolved via UNO to produce a concatenated unique result). Before concatenating the overall result, every sub-document is first created on disk, based on the same POD template. LibreOffice is then called repeatedly via UNO, for every sub-document, to update it. LibreOffice creates on disk the updated versions.

The problem: among the hundreds of ODT files produced by LibreOffice, in some of them, although the number of pages is equal to 2, the attribute meta:page-count="1" in meta.xml indicates "1".

Steps to Reproduce:
0. It is quite tricky to reproduce :-)
1. Create a POD template made of 1 page
2. Call the appy.pod Renderer to create hundreds of ODT documents based on this template. Use the option "forceOoCall" to True to force LibreOffice to load and update every produced ODT document.
3. Unzip every ODT result and check the value of field meta:page-count in meta.xml.

Actual Results:
On some ODT documents, "meta:page-count" is 1 but the document is made of 2 pages

Expected Results:
The attribute "meta:page-count" should reflect the correct number of pages


Reproducible: Sometimes


User Profile Reset: No



Additional Info: