Description: Official LibreOffice package 24.2.5 installed from LibreOffice Fresh PPA: When creating text in an alphabetical index entry that is longer than the index column width, the text flows through the margin into the page area - or right off the page instead of wrapping to the next line. Steps to Reproduce: 1. Create alphabetic index 2. Create a long index name and/or enough individual index links to fill the index entry 3. Update the index Actual Results: Index entry text flows through the index column margin without wrapping. Example ( # is column margin): #Jarrell, John (son of James 'The Elder')165,# 172 see attachment Expected Results: Text should wrap at the margin. #Jarrell, John (son of James 'The Elder')165,# 172 see attachment Reproducible: Always User Profile Reset: No Additional Info: The problem does not occur in 24.2.4 or previous releases - text flows/wraps properly to next line. This is being reported on a Linux Mint 21.3 (Ubuntu 22.04) system, but problem is also confirmed on Windows 7 and Ubuntu 24.04. Downgrading from LibreOffice 24.2.5 to 24.2.4 resolves the regression, but downgrading IS NOT EASY when using the LibreOffice Fresh PPA! The PPA code must be entirely removed and replaced by a manual install.
Created attachment 195412 [details] 24.2.5 index entry overflows column margin without wrap
Created attachment 195413 [details] 24.2.4 index entry text correctly wraps to next line
Please attach test file. Thank you.
Due to Intellectual Property concerns, I can not give you the entire 330+ page book in progress. Instead I tried creating small new files with multiple index entries on both 24.2.4 and 24.2.5 systems. All my test files work correctly on 24.2.5 - line wrap occurs. My guess, then, is there is a contamination in the book file that previous LO releases ignored but 24.2.5 either can not handle or misinterprets as "no wrap". You might argue this is not a LO problem, nonetheless erroneous output is created when there is/was no change to the input data, and the only change is the LO code handing the file. The book file was first created in LO over 4 years ago - many releases ago. No errors have appeared until 24.2.5. I do not know how to investigate where the problem is in the index handling. I will also mention the problem seems to occur only in the alphabetical index. Overlap lines in the Table of Figures do wrap correctly! Is there any way to look for a corruption in the specific index entries? I will try to regenerate a new full book file in 24.2.5 by copying segments and testing as I go. There is a LOT of formatting to deal with. This may take a week or more. Any advice is welcome.
Finally got clearance from IP concerns to submit a 10 page sample of the book which generates the error in 24.2.5. See attached test file. Also see attached image showing what *I* see when I run it. The error is for "Jarrell, John (son of James 'The Elder') I looked though all the changelog entries for 24.2.5 and found one that sounds close to the problem. Bug 158658 - FILEOPEN DOCX/DOC/RTF Tabs closing header paragraph are wrapped and not flowing outside the page area. The change was made to allow flow through the margins. Is this problem a side effect of that change? (alphabetical index is not mentioned in that change.)
Created attachment 195463 [details] test odt to reproduce the stated error
Created attachment 195464 [details] image of error in test file as seen in my system
Just confirmaton that this bug is also manifesting itself in Fedora 40, in: libreoffice* 24.2.5.2-2.fc40
I should also say that the bug is reliably reproducable even when I re-create a table from scratch, so it is not simply about corruption from previous releases.
Could confirm the buggy behavior with Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded See row 6 on the right in index: Jarrell, John (son of James 'The Elder') 5, 7, 8 '8' appears in right border of the page. Same buggy behavior in LO 24.8.0.1 on the same system. Works well in Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
bibisection with windows 10 seem to point to commit commit: 10d753b8aadb50ec4309551b97d4cf2163ea3e3d author: Michael Stahl <michael.stahl@allotropia.de> Date: Thu Jun 13 2024 12:59 commit mesage: tdf#158658 sw: text formatting: try to make TabOverMargin more crazy ... to better match Word's formatting; this commit is not based on a complete diagnosis of Word's compatibility-mode tab-in-margin formatting disorders.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0633189fabe85f73062ff2ce67b5f40af7d3f504 tdf#162121 sw: fix tab stop position in columned ToX It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
there are 2 problems: 1. the existing document is formatted differently if TabOverMargins is enabled 2. when the index is updated, the end tab stops in the index are created with a wrong (in the right margin) position if the index content is not directly in the document body, such as in this case where the index has columns problem 2 is really the root cause and is fixed on master. problem 1 is ... sort of intentional because that's what Word does, or rather Word does it even worse which you can test by exporting the ODT to "Word 2007" (compatibilityMode 12) DOCX. so to get the correct layout in such a document you have to "Update" the index.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/6df31a319ac591b885e5dcff1c90433f4481c8fa tdf#162121 sw: fix tab stop position in columned ToX It will be available in 24.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/aa4f45f07331f02343b021f118e64252f3bf515e tdf#162121 sw: fix tab stop position in columned ToX It will be available in 24.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
"Affected users are encouraged to test the fix and report feedback." I do not know how to verify that the committed code is or is not in a particular daily, but the 24.2.6 daily dated 2024-08-17 (5 days after Comment 15 says it will be available in 24 to 48 hours) DOES NOT FIX THE PROBLEM in the test file. See the result in attachment "LO24.2.6 test result.jpg" The daily that was tested is: /daily/libreoffice-24-2/Linux-rpm_deb-x86_64@tb99-TDF/2024-08-17_02.49.01/ Also tested the 24.8.0 daily dated 2024-08-18. Same result. Not fixed. Michael Stahl - did you run against the test file "text.overflow.test.file.odt"?
Created attachment 195891 [details] test result of 24.2.6 daily - problem not fixed
did you try to do "Tools->Update->Update All" ? this is needed to replace the wrongly positioned tab stops which are now formatted in a more Word-compatible way with correctly positioned tab stops.
Ah, I see in Comment 13: "so to get the correct layout in such a document you have to "Update" the index." You mean update AFTER the index is created when the file is opened. Sorry, I thought the code would process when the index is first built during file open. "Update index" and "Tools>Update>Update All" do reformat it correctly. The problem IS FIXED. (Please ensure any documentation on this clearly states: update after creation.) Sincere thank you for your work. Sam