Description: FILEOPEN ODT: Order of footnotes jumbled until save & reload Steps to Reproduce: 1. Open attachment 159138 [details] 2. Scroll to page 2. You see footnote number 78, followed by 129. 3. Save 4. Reload -> now number 78 is followed by 79 Actual Results: The order of footnotes is off, until save & reload Expected Results: Should open in proper order Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 37e3455a13ab5741104bf41d05a80e60a4612682 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Confirm in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4e6ab75c1a907398d24768d19cf097a4892d374c CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded works in Version: 6.2.0.0.alpha1+ Build ID: a20a2d7e0d28658f2d9089da076961a599833a28 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: cs-CZ (cs_CZ.UTF-8); UI-Language: en-US Calc: threaded
This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-6.3. I'm not sure if bisect is correct, because during bisectin LO crashed frequently. Adding Cc: to Michael Stahl and Caolán McNamara ; Could you possibly take a look at this one? Thanks 1690e8a6ab8671518553632e2aa37f125267d0cc is the first bad commit commit 1690e8a6ab8671518553632e2aa37f125267d0cc Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon May 13 00:08:40 2019 +0200 source c5338e3ad116dbde0aed801f459173231716efa3 https://gerrit.libreoffice.org/c/core/+/72198 72198: crashtesting: frequent nulldef at end of SwTextFrame::ValidateFrame 9c2fdbe6281a258ac2607f4ef618340bf5511c87 is the first bad commit commit 9c2fdbe6281a258ac2607f4ef618340bf5511c87 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu May 9 12:32:12 2019 +0200 source cc5916cd314a27b0cc99560ab887480026630a95 https://gerrit.libreoffice.org/c/core/+/98925 98925: sw: layout: fix missing invalidation of text frames in tables |
seems to be fixed. although these pathological numbers of footnotes in tables probably still aren't going to be very reliable... see other docs like the ones in the commit message... commit c303981cfd95ce1c3881366023d5495ae2edce97 Author: Michael Stahl <michael.stahl@allotropia.de> AuthorDate: Wed Aug 23 15:50:59 2023 +0200 Commit: Michael Stahl <michael.stahl@allotropia.de> CommitDate: Thu Aug 24 12:43:25 2023 +0200 tdf#156724 sw: layout: fix tables not splitting due to footnotes differently Revert commit 610c6f02b11b4b4c555a78b0feb2a1eb35159e39 and and 61a78a523a6131ff98b5d846368e5626fe58d99c instead do the opposite: never calc content frames in FormatLayout(). There were a few cases where documents looked worse with the fix, such as the somewhat pathological tdf120139-1.odt and tdf124474-1.odt, but typically these went from a bad layout to a worse layout, e.g. --convert-to pdf tdf120139-1.odt went from 11 minutes to 33 minutes (dbgutil) with twice as many more half-empty pages. Worse is that the previous fix appears to prevent tdf#128437 from working. It should also be less risky to never calc content frames in FormatLayout(), because with IsPaintLocked() check that used to be done led to doing it only for pages which were visible when loading the document, so any regressions with this new approach would appear on few pages at the start of the document, instead of many pages at the end. Note that without the previous commit, this would cause * CppunitTest_sw_core_layout CPPUNIT_TEST_NAME="testTablePrintAreaLeft" to fail * tdf#137523 SwLayoutWriter3 testTdf137523 to fail, *only* on the last text frame This also appears to fix tdf#125749. Change-Id: I3d72f8e9d2b89aa3738e554308fd9dce12e92238 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155988 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>