[Libreoffice-bugs] [Bug 138907] End of Document page field is not updated initially when specific document is opened

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Fri Dec 25 11:05:25 UTC 2020


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

Justin L <jluth at mail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86-64 (AMD64)              |All
            Version|5.2.5.1 release             |5.1.0.3 release
           Severity|normal                      |minor
            Summary|Wrong page numbers in       |End of Document page field
                   |footer when document is     |is not updated initially
                   |opened                      |when specific document is
                   |                            |opened
                 OS|Windows (All)               |All

--- Comment #8 from Justin L <jluth at mail.com> ---
The second issue is "of 1". However, that is not the normal "Page Count"
variable that one would expect to be used in this case. It is some "End of
Document" marker.

This was fixed in LO 4.4 - so that it immediately showed "of 2" with
commit cd94a84b89c476760ad74bf088a5d6f8ba4ce209
Author: Oliver-Rainer Wittmann on Fri Jun 13 20:32:14 2014 +0200    
        125044: - use field's content cache on <SwTxtFld> construction only    
        ... for clipboard documents

        - assure invalidation and updates on code to update fields


It was broken again in LO 5.1 (for which on Linux I only have the ability to
bibisect to a one day range) by one of these
https://cgit.freedesktop.org/libreoffice/core/log/?id=22355042a6fc7aecf3caab69b3fa3be1430b697f&qt=range&q=a3050f632517137f809d76662170726b518f043a..5a61d7f049a81d6e747d9d097f364ae45f58697b

Perhaps a Windows person can verify with their bibisect, but I highly suspect
author    Ashod Nakashian on 2015-07-15 07:46:01 +0000
commit  b0fde7a912ff3aa370496802f20895b1158b072c
> tdf#38837 Reduce power consumption by minimizing idle timers
> Both the document statistics- and state-manager have their
> own modified flags. There is a cyclic dependency between the
> the two in that updating the document's statistics also marks
> the document as modified. Of course when a document is edited
> the statistics modified flag is set to trigger an update.
> 
> To avoid a perpetual cycle, the statistics manager resets the
> document's modified state to that before setting the new
> statistics. However, this doesn't reset the statistics
> modified flag, which was set when the document was modified
> by setting the new statistics. Hence, the statistics thinks
> there are modifications in the document when there isn't.
> 
> This patch is to make DocumentStateManager::ResetModified()
> symmetrical to DocumentStateManager::SetModified() by
> reseting the modified flag of the statistics manager.
> 
> The idle CPU drops to nil on unmodified documents after this.
> However, for modified documents the statistics is recalculated
> perpetually until the document is saved. This will need a
> different patch to fix.

That makes sense with what we are seeing. Any modification causes the End of
Document field to update itself. For example, printing or exporting to PDF also
update the field. So I'd say this part is a rather minor irritant.

Also, it is hard to reproduce. Adding a third page "fixes" the problem.

-- 
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/20201225/f8817dff/attachment.htm>


More information about the Libreoffice-bugs mailing list