Description: When at the end of a line in Writer, spaces seem to get inserted with zero width rather than wrapping over to the next line. I.e. x number spaces at the end of a line requires x number of backspaces to move the cursor backward again. Steps to Reproduce: 1. Open Writer 2. Hold down the spacebar Actual Results: When the cursor hits the end of the line, subsequent spaces are entered invisibly at the end of that line. Expected Results: When the cursor hits the end of the line it should wrap over to the next. Reproducible: Always User Profile Reset: No Additional Info:
Confirmed on Windows 10 Home 64-bit en-US with Version: 6.2.4.2 (x64) Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded STR 1. New Writer document 2. Page properties, set left & right margins to 3" reduce to a narrow column 3. change font for Paragraph to Liberation Mono 4. enter sequence of spaces to fill to the reduced margins (24 on US 8.5x11 in page) 5. notice the count of characters in the status bar shows 24 6. keep entering spaces, count goes up but text cursor remains at right margin 7. back space will reduce the count of characters, untill cursor starts moving left into paragraph again. Enter additional spaces, text cursor again stops a right margin. 8. save file to Flat XML .fodt 9. open the .fodt in a text editor Examine the <text:p> and note that the text spans are <text:s text:c "25"> or more, so this looks to be correct ODF 1.2 recording of spaces. And, they are legitimate Unicode U+0020 (not assigned any other glyph with an <Alt>+X toggle) However with a second paragraph, placed after the first, text cursor movement will pass from the right margin of the first directly to the left margin start of the next paragraph. Ignoring the text span's <text:s text:c> "spaces" beyond the end of the margin. Not clear it is incorrect (from ODF perspective) but it is weird UX. @Regina?
I think it is a deficit in the UI, that spaces in the margin are not shown. Word shows all spaces, SoftMaker shows one space in the margin.
(In reply to Regina Henschel from comment #2) > I think it is a deficit in the UI, that spaces in the margin are not shown. > Word shows all spaces, SoftMaker shows one space in the margin. So which is wrong, that there is no string wrap to the following line with a text run of spaces reaching the margin--allowing spaces to enter the margin, or that spaces extend beyond the margin and are not show--where all other mixed text spans will wrap. Wonder what happens with a text run of <text:t>?
I'm not sure about wrapping of spaces. Of cause an editor, which wraps at the window edge, will put the spaces to the new line. But Word and OpenOffice.org had always wrapped so, that the first non-space content is at the starting of the next line. I haven't got Wordperfect and have not used Latex. Perhaps someone knows, how they handle such spaces. But as long as the line break works as it is now, the spaces should be displayed to make it clear to the user why the cursor and delete key behave like this.
(In reply to V Stuart Foote from comment #3) > Wonder what happens with a text run of <text:t>? So checked, and a run of <text:tab> are entered one at a time and will be wrapped onto vcl canvas. So just the <text:s> with <text:c> attribute for a text run of spaces is not wrapped--but also it is not visualized to canvas, and we can not advance text cursor into the margin. Checked and LO wrap behavior matches the MS Word 2016 wrap behavior--that is the wrap will not occur until some non-space text is added, and that text then becomes the start of the next line. Spaces show into the margins, and then after the text causing the wrap. So our behavior is the same as MS Word, but we don't visualize the additional spaces outside the margins and we can not manipulate the text cursor which holds stuck against the right margin.
Cursor now follows the spaces in the margin and beyond the page with fix for bug 43100, so marking as a duplicate. Formatting marks don't show beyond the page, but that could be a follow-up bug report if it is considered to be lacking. *** This bug has been marked as a duplicate of bug 43100 ***