It is somewhat common to create a pen-and-ink writeable "form" by turning on underlining and holding the space bar to create a "line". That broke for at least one document in 24.2.0 with commit 853e13f9146e83b959bc53152ec103470d55fb4f Author: Mike Kaganski on Fri Dec 29 14:22:23 2023 +0600 tdf#57187: make sure to put trailing blanks to hole portion in narrow lines Steps to reproduce 1.) Open underscores.docx (attachment 162677 [details]) from bug 134541 Notice there there are no "lines" on the page. It should look like attachment 163012 [details]: Comparison MSO 2010 and LibreOffice 7.1
This needs underlining of the hole portions... it must be doable; in the end, the hole portions already show space indication in the "show formatting marks" mode. Possibly something similar to how tab portions allow "fill" characters.
In my opinion, this new broken behavior is just putting light to a historically broken behavior. I believe it's the same bug that I was about to report. Sorry for just dumping my report here. Please let me know if you'd rather have me report it as a separate bug. :) Steps to reproduce: * New Writer document * Ctrl+u to enable underline character style * Hold spacebar until you have inserted more characters than will fit within page margins Expected results: The cursor should insert space characters styled with underlining, to leave a line across the first line of the document. When the cursor reaches the page margin, it should wrap and begin inserting space characters on the next line. It should continue to wrap as more space characters are inserted to subsequent lines. Actual results (LO 24.8.4.2): The cursor properly inserts space characters styled with underlining, leaving a line across the first line of the document. When the cursor reaches the page margin, it does NOT wrap and continues off the side of the document. ALL previously visible underlined spaces between the right margin and the last non-space character (or first character) become invisible. New invisible space characters are inserted infinitely as the cursor disappears off the right side of the screen. The buggy document the user previously created using underlined spaces that disappear off the side of the page now has a document that looks as broken as it really is behind the scenes. Actual results (LO 7.5 and earlier): The cursor properly inserts space characters styled with underlining, leaving a line across the first line of the document. When the cursor reaches the page margin, it does NOT wrap and continues off the side of the document. It stops leaving visible underlined space characters at the margin, but new invisible space characters are inserted infinitely as the cursor disappears off the right side of the screen. The user is left with a pretty looking visible line that ends at the page margin. I also tested LO 4.2.6 and it still inserts invisible characters forever and doesn't wrap, but it keeps the cursor at the page margin and doesn't hide the line like in LO 24.8.4.
(In reply to tmacalp from comment #2) 1. Comment 2 is unrelated to this bug. 2. Comment 2 is not a bug. The behavior implemented in Writer is defined in Unicode Standard Annex #14 [1], which explicitly specifies, that "when the last character measured for fit is before the space character, any number of space characters are kept together invisibly on the previous line and the first non-space character starts the next line". [1] https://www.unicode.org/reports/tr14/#SP
(In reply to Mike Kaganski from comment #3) > (In reply to tmacalp from comment #2) > > 1. Comment 2 is unrelated to this bug. After testing the attached documents, you're correct that my described behavior should probably be its own report. > 2. Comment 2 is not a bug. The behavior implemented in Writer is defined in > Unicode Standard Annex #14 [1], which explicitly specifies, that "when the > last character measured for fit is before the space character, any number of > space characters are kept together invisibly on the previous line and the > first non-space character starts the next line". > > [1] https://www.unicode.org/reports/tr14/#SP Mike, thanks for the link to the unicode definition. That does indeed explain the unintuitive(at least to me) behavior of normal spaces never breaking. That definition doesn't say how the word processor should handle visible formatted space characters. Nor does it mention whether to show trailing formatted space characters that are before/after the margin. * MS Word shows the characters up to the margin (pre-LO7.5 behavior) * Google Docs hides all trailing formatted space characters(you can't even create trailing lines with underlined spaces) * LO is now inconsistent, showing trailing formatted space characters, but only until they cross the margin, then it hides all of them. I'll report this as another bug.
(In reply to tmacalp from comment #4) > * LO is now inconsistent, showing trailing formatted space characters, but > only until they cross the margin, then it hides all of them. *That* is exactly this bug.
*** Bug 164958 has been marked as a duplicate of this bug. ***
The issue happens only with spaces that are the trailing spaces of the line and only with legacy ODT files. Adding any non-space character to the end of the line makes the formerly trailing spaces non-trailing ones and their underline becomes visible. (Note: I wanted to add the "trailing spaces" and "legacy" keywords to this bug but those keywords don't exist. Therefore, the title of the bug should contain these keywords, otherwise it is hard to find this bug. This made me to create a new bug.) As I wrote in https://bugs.documentfoundation.org/show_bug.cgi?id=164958, the Tools -> Options -> LibreOffice Writer -> Compatibility -> Word-compatible trailing blanks switch toggles the behaviour. Turn it off and you will see the underlines of the trailing spaces as well. I also made a suggestion in that bug how LO could avoid this problem by alerting the user when opening a legacy document. Please consider that suggestion. Thank you.
1. The csongor's issue in bug 164958 is not a bug at all (or rather, the bug is that there are single-character underlined portions, where nothing must be underlined). The "Word-compatible trailing blanks" is the compatibility mode specifically to do what it tells: show blanks the same way as Word. And in Word, the document opens without shown underlines - both opening the ODT, and opening a DOCX that LibreOffice creates from the ODT - even though the underline is there in the text properties, shown on Word's toolbar. How the compat option appeared there is likely by converting a Word document, or copying from it in the period when we had a bug of bringing compat settings via copy-paste (bug 151974). The change of behavior *there* is the bug fix, not a regression. 2. But the issue in attachment 163012 [details] from comment 0 is *likely* some specific corner case. It is a DOCX, so naturally the "Word-compatible trailing blanks" is in action; but Word shows the underlines; and even Writer shows them on lines 2 and 3, when some of the trailing blanks are removed. I will try to find out the exact reason what makes Word show the underline (as opposed to bug 164958), and what makes LibreOffice not show it after some length.
(In reply to Mike Kaganski from comment #8) > 1. The csongor's issue in bug 164958 is not a bug at all (or rather, the bug > is that there are single-character underlined portions, where nothing must > be underlined). I understand that the current behaviour is the desired one, therefore, it is not a bug, it is a fearure. But if I open an ODT file in a new LO version and it looks differently in a sneaky way then it is not a good user experience. LO could remind the user that there are some changes in the document. In order to do that, it should: - compare the version of LO that created the file with the version I am using now - collect the incompatible changes between the two given versions - check if anything in the document is impacted. I believe this is not an easy check and won't be implemented ever. But this is what a good user experience would require.
Not a regression, but a missing feature. The support for Word's "Underline Trailing Spaces" compatibility option is missing. Previously, it worked as it that compatibility option was always enabled (in Word, it's disabled by default).
https://gerrit.libreoffice.org/c/core/+/182188
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a877c6ce97f73906c39cf800bc61d7d99847361c tdf#164487: Introduce "Show underline" MS Word compatibility option It will be available in 25.8.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/24eb7e8e01b9b2e9354c3d8fde66ee528b3e1ed3 tdf#164487: "Show underline" compatibility option OOXML import/export It will be available in 25.8.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.
Let me call it fixed. The problematic document should look OK. The unresolved problems mentioned in the commit message of a877c6ce97f73906c39cf800bc61d7d99847361c need own bugs.