Description: While editing a large document, often extremely minor changes will cause footnotes to appear as if they are overlapping, or to lose their formatting (double spacing). By highlighting them and choosing 'Update style' (or by editing and undoing the edit). I've not been able to determine exactly what changes made cause this. Steps to Reproduce: 1. I have not been able to consistently reproduce the issue. 2. 3. Actual Results: Minor changes made in a document cause footnotes to appear with improper formatting. Expected Results: Footnote styles should be updated/enforced if they are caused to move by other edits. Reproducible: Sometimes User Profile Reset: Yes Additional Info:
Created attachment 143314 [details] Screenshot of issue This is how the error presents. Note 136 has lost its double spacing, being directly above 137. Note 138 has shifted partially out of the range of the page. A second screenshot will demonstrate how they look after selecting each and choosing 'Update style' to reinforce the style rules for footnotes.
Created attachment 143315 [details] Screenshot of expected result This is how the footnote should look. There was space at the bottom of the page to accommodate the longer footnote. There is now the appropriate space between 136 and 137. Additionally 138 is no longer cut off.
We need an example document. Hopefully you can produce a minimal example. Please attach an example document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
I will attempt to reproduce it in a smaller document. In the meantime I will provide the original, but it is 95 pages with 232 footnotes. I had not seen this occur in earlier versions of the same document that were shorter.
Created attachment 143565 [details] Document exhibiting the issue This is the document that exhibited the strange footnote behavior.
Does the style change occur upon saving & reloading or while editing? I did some edits on page 53 (47), saved & reloaded, but the spacing did not change. Arch Linux 64-bit Version: 6.2.0.0.alpha0+ Build ID: 860a9daf2b45942a4b10ff22d36aa3fe29be19f4 CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on July 14th 2018 Arch Linux 64-bit Version: 6.0.5.2 Build ID: 6.0.5-1 CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group
Almost invariably on opening the document, at least one footnote will be impacted. I just tested now opening and closing the document multiple times and see that (at least) footnotes 68, 87, 97 and many more are cut off (same issue as footnote 138 in the previously uploaded screenshot). I'll upload another screenshot to demonstrate.
Created attachment 143584 [details] Screenshot of issue from attached document The previous screenshots were from a different revision of the document than the one uploaded for testing.
(In reply to Donald Haase from comment #7) > Almost invariably on opening the document, at least one footnote will be > impacted. > > I just tested now opening and closing the document multiple times and see > that (at least) footnotes 68, 87, 97 and many more are cut off (same issue > as footnote 138 in the previously uploaded screenshot). I'll upload another > screenshot to demonstrate. Thanks. I bibisected with Linux 44max repo against the file opening situation and got this blamed commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=60d34e1c840d2c317bb7d0a5b14f4602c22b3fcc coverity#735517 Logically dead code its possible that this was the original intent, maybe While testing, I always jumped to page 27 by finding the string deuterocanonical and observed if footnote 68 was cropped. The code the commit touched has since 2014 seen further renovations, so I skipped trying to revert it to the original state. Adding Cc: to Caolán McNamara
I guess we can put it back to its historic state
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cee296066ab780217395201ab84c2150c8840d25 Resolves: tdf#118545 restore to historic logic It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
backport to 6-1 in gerrit
Verified in Version: 6.2.0.0.alpha0+ Build ID: 95b00f1bfa341003af23e150d316d943d47909cf CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Caolán, Thanks for fixing this!!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7cca3ff7d0c2d1bf6e47fa69c4edb939e51d098c&h=libreoffice-6-1 Resolves: tdf#118545 restore to historic logic It will be available in 6.1.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b26718458b46e23e2d644b1580565d30f3df8871&h=libreoffice-6-0 Resolves: tdf#118545 restore to historic logic It will be available in 6.0.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.