Description: In LO Writer, the U+2011 character (non-breaking hyphen) used to be highlighted (light grey if pages are white) via View > Field Shadings option. This was useful in that the user was thus visually notified that that hyphen actually exist, but has some different functionality than a normal hyphen. Now, without the highlight, the user will be confused either by no longer knowing if or where it entered already that character, or when searching, for example, "s-a întâmplat" or "s-au întâlnit" but the actual text is "s‑a întâmplat" or "s‑au întâlnit" and it will find nothing, even if the searched segment appears to be there obviously (these examples are usual wordings in my language, Romanian, where NBHy is used to prevent word wrap at the end of line by that hyphen, which grammatically is not permitted). I for myself got very confused initially when I entered Ctrl+Shift+- and the hyphen displayed normally, thus at first I was convinced that either LO Writer abandoned that shortcut, or the program entered a normal hyphen instead of the NB hyphen because of a new bug and so I was just about to fill a bug report in that sense – only days later to realize that the bug was only UI related. How do I know now if or where I entered correctly the Ctrl+Shift+- character ? After reporting this bug on LO forum, I learnt that the highlight may appear IF a Non-breaking **space** (?) checkbox is set in settings AND IF text markings via pilcrow icon is set. However (1) NBHy is one thing and NBSp is a totally different thing and (2) working with the pilcrow mark ON is not always an use case. Steps to Reproduce: Just write whatever, then enter Ctrl+Shift+-, then immediately continue write whatever. The resulted hyphen shows like any other hyphen, even if now the word cannot be word-wrapped in place of that hyphen (which is correct, functionally speaking). Alternatively, the NBHy can be obtained by writing U+2011 and then pressing Alt+x immediately after. Actual Results: The resulted hyphen looks exactly the same like the 'normal' hyphen-minus (U+002d). Expected Results: The user should become aware that the resulted hyphen is somehow different than the 'normal' hyphen-minus or gets visual confirmation that it entered the right thing. Reproducible: Always User Profile Reset: No Additional Info: -
It's Tools > Options > Formatting Aids > Soft Hyphen. We may a) switch this option on by default, and b) detach this option from the NPC set. I could agree to a), though non-printable characters NPC aka the pilcrow command would still off. But I disagree with b) as this is contrary the patch idea and considering auto-hyphenation. While testing I realize that soft hyphen show up even when NPC are off. In this case not as a field but the plain hyphen unconditionally whether effective and breaking or not.
NO, sorry, you make a confusion here. I was speaking about NON-BREAKING HYPHEN, i.e. U+2011, which is an always visible hyphen that **PREVENTS** hyphenation at the end of a row. Soft hyphen, i.e. U+00AD, is a _totally different thing_.
(In reply to Cristian Secară from comment #2) > NO, sorry, you make a confusion here. Sorry, I did. The expected result is achievable with the option "Non-breaking spaces" on. We may consider here as well to switch in on by default. But besides the label that could be more suitable I struggle to think of non-breaking space vs. hyphen as a completely different information.
> The expected result is achievable with the option "Non-breaking spaces" on. Not quite, as this being the reason for this very bug report: I mean, yes, the option is achievable with the option "Non-breaking spaces" ON, but *only* if the pilcrow markings is *also* ON (i.e. cumulative condition). This is a regression, as prior to don't-know-exactly-which 24.x version, the NBSp & NBHy grey markings were visible regardless the pilcrow status, but depending on the View > Field Shadings (aka. Ctrl+F8), which now does not appear to do anything. Maybe some snapshots might help understanding better – see attached, first with pilcrow OFF, then ON. The text is in my language, Romanian, I created it only for this test, and while it has limited meaning as is, the NBHy usage is very much plausible in real life context, where good typography is a must. As for NBHy ≈ NBSp, I agree to a certain extent – both are keeping [parts of] words glued, both should be always visible and both require the user to be somehow aware of a their special property.
Created attachment 197783 [details] normal text editing, plcrow OFF
Created attachment 197784 [details] normal text editing, plcrow ON
> As for NBHy ≈ NBSp, I agree to a certain extent – both are keeping [parts of] words glued, both should be always visible and both require the user to be somehow aware of a their special property. ... and both can be easily generated using the Ctrl+Shift+- or Ctrl+Shift+space combination respectively.
(In reply to Cristian Secară from comment #4) > ... the option is achievable with the option "Non-breaking spaces" ON, but > *only* if the pilcrow markings is *also* ON (i.e. cumulative condition). And this was the intention of the patch. But anyway, I understand you being surprised that entering the nbhy/nbsp apparently does nothing.
> But anyway, I understand you being surprised > that entering the nbhy/nbsp apparently does nothing. Yes, I was totally puzzled with this. It just happened that the pilcrow button was OFF and I didn't make the connection right away, I just thought it was either a new bug, or something wasn't working on my keyboard. I only learned from my post on the LO forum about the 'this is a feature, not a bug' change.
see also bug 67669 and dupes
Sorry, => NAB in error, under UX-advise Though IMHO a clear -1, as this is direct result of work on bug 58434, with residual as for see also bug 67669
(In reply to V Stuart Foote from comment #11) > Though IMHO a clear -1, as this is direct result of work on bug 58434, with https://bugs.documentfoundation.org/show_bug.cgi?id=58434#c16: > Including in non-printing would be OK for me. > But we may expect people to start complaining about that? ;) Let's see if we can improve.
We discussed the topic in the design meeting. Both, nbhy/nbsp insert a visible character even with Formatting Marks off. It is clearly visible later that those words break lines or not. The function to show/hide formatting marks is designed exactly for the purpose to write distraction free - or to review to formatting. With the latest modification it also allows to show these non-breaking glyphs independently from any other field or formatting mark. => WF We pondered over the naming and considered "Non-breaking <spaces and hyphen> | <glyph> | <...> (with a tooltip) | <character>". None is perfect but we should try with the first option - that could be too long when translated.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/139bb786bb4fe5cf2554f6016095ff1588f3994f Resolves tdf#164034 - Rename Non-breaking Spaces 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.
As the one who started this topic and based on comments: • (important) make the checkbox from settings enabled by default [acting as such for new installations] • (recommended) separate it in distinct options, one for NBSp and one for NBHy At least from my perspective, that should be enough. The reason for having separate checkboxes is that not all languages have same requirements or habits. Speaking for my language, Romanian: a) the normal hyphen is frequently used in every texts, and because the expressions that use it are not allowed to be hyphenated at the end of a row, NBHy is (or should be) used instead; sometimes the replacement can be performed later when reviewing a draft and looking for grammar and/or cosmetic problems b) NBSp is rarely used here On the other hand, several languages may never need NBHy for daily writing purposes (however, I have no idea about where or how often NBSp is used). As for the enabled by default, these features should remain/became obvious that they simply exists, otherwise normal users will never be aware of – and showing/hiding them with the pilcrow together with all the other non-printable writing help marks, as it is now already (AFAIK), should be good enough (if not perfect).
(In reply to Cristian Secară from comment #15) > • (important) make the checkbox from settings enabled by default [acting as > such for new installations] This is an expert argument. Novice users might struggle to understand the field-like formatting marks. But if more agree on enabling the option by default I'm happy to obey. > • (recommended) separate it in distinct options, one for NBSp and one for NBHy Clearly not since the use case is the review formatting and not to distinguish between the two types. In fact we discussed this option as a solution for the naming problem but rejected it.
(In reply to Heiko Tietze from comment #13) > We pondered over the naming and considered "Non-breaking <spaces and hyphen> > | <glyph> | <...> (with a tooltip) | <character>". None is perfect but we > should try with the first option - that could be too long when translated. (In case needed, I have some other idea..) (In reply to Heiko Tietze from comment #16) > (In reply to Cristian Secară from comment #15) > > • (important) make the checkbox from settings enabled by default [acting as > > such for new installations] > This is an expert argument. Novice users might struggle to understand the > field-like formatting marks. But if more agree on enabling the option by > default I'm happy to obey. I like the argument from Christian. > > • (recommended) separate it in distinct options, one for NBSp and one for NBHy > Clearly not since the use case is the review formatting and not to > distinguish between the two types. In fact we discussed this option as a > solution for the naming problem but rejected it. I had the idea that was because technically they depend on the same..? Reading Cristian's reason for separating, I have to admit that we didn't consider that kind of argument. And since it's impossible for to imagine all special habits/rules in all languages we serve, I really want to listen to this info.
(In reply to Cor Nouws from comment #17) > > (In reply to Cristian Secară from comment #15) > > > • (important) make the checkbox from settings enabled by default > I like the argument from Christian. Okay, patch submitted. > > > • (recommended) separate it in distinct options, one for NBSp and one for NBHy > I had the idea that was because technically they depend on the same..? The code knows only ProtectedSpace and does not separate between spaces and hyphen. But even when this would be changed I see no need to distinguish between these formatting marks.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/b1f39f4e9c6b8e921c9443b9dde0fa8ba63b811d Resolves tdf#164034 - Rename Non-breaking Spaces It will be available in 25.2.0.0.beta2. 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.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ad5e52d266b95753b3b836c701a079ecc7ba33b4 Related tdf#164034 - Enable ProtectedSpace by default 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.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/20f78576e9896e170d549a26662474e2489a06f6 Related tdf#164034 - Enable ProtectedSpace by default It will be available in 25.2.0.0.beta2. 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.
(In reply to Heiko Tietze from comment #13) > https://git.libreoffice.org/core/commit/ > b1f39f4e9c6b8e921c9443b9dde0fa8ba63b811d > > Resolves tdf#164034 - Rename Non-breaking Spaces So, the new text is: "Non-breaking s_paces and hyphen" I believe you are missing a trailing "s" ...
(In reply to Eyal Rozenberg from comment #22) > I believe you are missing a trailing "s" ... Hyphen*s*?