[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