Description: i'm logging a needed enhancement/workaround, but in the closing paragraph i outline what looks like a bug. a gray space after many punctuations is an eyesore to most writers using libreoffice when it doesnt happen anywhere else. for 10+ years, it’s a most annoying thing that makes thousands avoid using librewriter more. some suggest taking the extra step to use ‘ctrl+H’ to 'replace all' but by default, most users/writers who dont need to see this shouldn't see it. the gray space has been explained as a feature highlighting U+00A0 NO-BREAK SPACE instead of regular U+0020 SPACE created by users accidentally pressing Ctrl+Space or Shift+Space when typing. guaranteed, 99% of us did not add extra CTRL or SHIFT keystrokes after adding punctuation ex period, comma, colon, question mark, exclamation point, etc. so it's a bad assumption. we are talking about perfectly normal error-free clean writing/typing. some say this gray space is a feature not a bug. if so, many writers/users like me would like to submit a feature request to make the default not display these as gray; to make the feature an option to toggle on/off with default 'off'. the enhancement would be an acceptable workaround; we just rather not see it. but to me it seems like the copy/paste function itself is making wrong assumptions and is potentially introducing its own wrong translations. that does seem like a real bug. Steps to Reproduce: 1. type a long gmail or word doc or open one you typed 2. select all and copy all of it to clipboard 3. paste clipboard into any other editor; see no gray space anywhere in the text 4. paste clipboard into libreoffice writer; see many gray spaces after many punctuation marks throughout, you'll see 0-5 per paragraph. Actual Results: see many gray spaces after many punctuation marks throughout, you'll see 0-5 per paragraph pasted from clipboard Expected Results: see no gray space anywhere in the text (like when you paste into any other editor) Reproducible: Always User Profile Reset: No Additional Info: this literally includes both a workaround as an enhancement and a copy/paste bug. please, spawn a bug ticket from this before closing the enhancement request. this problem is 10+ years old across windows 9, 10, 11, so i see no need to reset userprofile.
LibreOffice already provides the Paste Special -> Unformatted Text that will remove what is essentially formatting as held on clipboard in the text being pasted from os/DE clipboard. Paste as Unformatted Text removes any gray field shading boxes (alternatively the toggle <Ctrl>+F8 will suppress, though bug 58434 is open to move to <Ctrl>+F10 NPC toggle). It just depends on how much else of the formatting/style of the copied text you need to retain. If you need more, the Paste Special -> More... dialog will offer any additional formats your system clipboard is reporting to LibreOffice. A few clipboard formats won't be recognized (depending on the source application and the LO module in use) and the handling of the pasted content will depend on content of the clipboard format and the LO filter implementation handling of that content. Nothing to be fixed here, LO *consumes* what is present on the os/DE clipboard.
(In reply to wolf from comment #0) > Description: > ......... > a gray space after many punctuations is an eyesore to most writers using > libreoffice when it doesnt happen anywhere else. for 10+ years, it’s a most > annoying thing that makes thousands avoid using librewriter more. > .......... Why do you need to mention thousands of annoyed people, do you really think it will sell your personal interest any better? Instead, better ask those thousands to add their comment supporting this report?
i restarted in safe mode, as expected, the same issues occur.
this occurs using both 'paste' and 'paste unformatted' which is why an option to turn this 'off' by default ideal to match behavior of most other editors ex word, gmail. i will double-check the 'paste special' options to see if any work, if it does, that'd be a good to know workaround, but still the default paste behavior for writers coming from word/gmail type editors that mask this info by default. i'm told 'non-breaking space' is widespread in HTML markup and copying from web pages would bring existing NBSPs along. ok, but i'm primarily talking about text i personally typed cleanly with no accidental 'shift' or 'ctrl' keystrokes. note: pasting content from a long notepad file i have pasted clean, no gray spaces. i restarted in safe mode, as expected, the same issues occur. my bad, for trying to sell the case for 'thousands' of others who opted out because of it as i have, but am now returning to face it again.
Can not confirm. Observe that Paste Special -> Unformatted Text does strips out the NBS or ZW characters that show as gray field shading.
just triple-checked: there is no paste option that strips out these gray shading/spaces after punctuation and on line breaks. and 90% of the time, i aim to paste with basic rtf formatting vs strip it out.
Created attachment 193120 [details] Writer Flat ODF sample file with Unicode formatting codes subject to Field Shading Attaching a sample document that shows the objectionable handling as field shading on paste, either default or as unformatted text. A copy & paste of the text will show the current handling of the Unicode formatting marks as field shading. Use <Ctrl>+F8 to toggle off the Field shading, Use <Ctrl>+F10 to toggle off the NPC. And the unformatted paste does not clear the specific Unicode glyphs that result in the field shading. So I was wrong regards that, sorry for the noise. However, beyond VCL formatting changes needed for bug 58434, there is nothing incorrect with LibreOffice's handling on paste of clipboard content. Applying field shading needs to be removed, that is bug 58434
<Ctrl>+F8 to toggle off the Field Shading works! a workaround existed all these years deep under the hood. so the enhancement would simply be to turn Field Shading 'off' by default.
mikekaganski informs me that 24.2 has the “off by default” implemented.
I guess you know ctrl+F10 resp. the button with a pilcrow icon (¶) to show/hide formatting marks and would easily get the point of highlighted special breaks. So let's make this report a duplicate of bug 58434. (In reply to wolf from comment #4) > i'm primarily talking about text i personally typed cleanly > with no accidental 'shift' or 'ctrl' keystrokes. You wont see any formatting mark or field that is getting highlighted then. *** This bug has been marked as a duplicate of bug 58434 ***