Created attachment 71693 [details]
nonbreaking characters under LO

You can see nonbreaking characters under LO displayed with a gray background, as if they were highlighted.

Created attachment 71694 [details]
nonbreaking characters under MS Office

The same text under MS Office Word is displayed as regular characters, which is visually easier to read.

I'm sorry just not following this bug report:

What might help:

Provide reproducible steps
An attachment of an actual document showing these gray areas

I don't see gray areas at all in Linux with or without non printing characters visible.

Marking as NEEDINFO - with additional information you can mark the bug as UNCONFIRMED but please provide very explicit steps so it's easier to follow what's going on. 


Thanks!

(In reply to comment #3)
> I'm sorry just not following this bug report:
> 
> What might help:
> 
> Provide reproducible steps
> An attachment of an actual document showing these gray areas
> 
> I don't see gray areas at all in Linux with or without non printing
> characters visible.
> 
> Marking as NEEDINFO - with additional information you can mark the bug as
> UNCONFIRMED but please provide very explicit steps so it's easier to follow
> what's going on. 
> 
> 
> Thanks!

I'm under Linux, using latest stable LO available and I can still reproduce it every time. I also use LO daily on Windows. In both cases, I can see what I reported and explained. I can also see it on all 5 computers at work. Were you typing nonbreaking characters as explained in the screenshots?

I'll be attaching an example right now.

Created attachment 89725 [details]
Example of nonbreaking characters with grey background

All the nonbreaking characters have a grey background as if they were highlighted in grey. They are between the brackets []. They can be seen with or without activating the display of special characters.

(In reply to comment #5)
> Created attachment 89725 [details]
> Example of nonbreaking characters with grey background
> 
> All the nonbreaking characters have a grey background as if they were
> highlighted in grey. They are between the brackets []. They can be seen with
> or without activating the display of special characters.

replace "special characters" by "printing characters" in the sentence.

Thank you for reporting this enhancement request! I can confirm that this is a valid enhancement request on:
Version: 4.2.0.0.alpha0+Build ID: 09a4c4d176ff97ab8ff4027af83a549991667baf
Date:   Sat Nov 16 20:32:43 2013 +0100 
Platform: Ubuntu Linux 13.04 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
As I've been able to confirm the enhancement request I am marking as:

New (confirmed)
Enhancement
Medium


Whiteboard Status - ProposedEasyHack

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material

The grey background is actually field shading, which can be toggled on and off separately (View > Field Shadings). But I agree that it would be more intuitive if the highlighting of these formatting characters was linked to the visibility of non-printing characters.

Besides no-break space (U+00A0) and non-breaking hyphen (U+2011), there are other characters that have field shading, including at least soft hyphen (U+00AD), zero width space (U+200B), and word joiner (U+2060). On the other hand, narrow no-break space (U+202F) and figure space (U+2007), for example, do not have field shading, although they are also exceptional as regards line breaking.

*** Bug 63538 has been marked as a duplicate of this bug. ***

*** Bug 52526 has been marked as a duplicate of this bug. ***

With the grey being visible and invisible depending on View > Field Shadings when its not a field like page number or date, this is a bug in my opinion and not an enhancement.

I agree with Jay. The grey shading (or whatever colour) should appear only when the nonbreaking chars are made visible.

I also agree with Jay that using the field shading colour for formatting marks is a bug. Hence I have changed importance to 'medium normal'.

But what is the correct function? I think this has not been properly defined yet. And so this is the enhancement part of this bug report.

I also see the necessity to visualize this kind of characters. To display them with a shading, if the nonprinting characters are displayed, may be a solution. But in this case two things have to be taken into account: 
(1) The term 'nonprinting character' is no longer correct, because some of the formatting marks are printable. It may be better to have an additional item in the View menu in order to display formatting marks.
(2) It may be possible that background colours are used and these colours may be equal or similar to the shading colour. For this case an algorithm should be implemented in order to ensure, that there is a sufficient contrast between shading and background colour.

Like Harald suggested, i agree that the display of formatting marks should be settable in the view menu and in that way it is independent from regular and non-printable character view modes like it is right now. It should be turned off by default, as it is not needed by most regular users, similar to non-printable characters is also turned off by default.

It should be noted that there is no visual difference between a number of these kinds of characters when the gray background is shown. (e.g. non-breaking hyphen and soft hyphen)

Yup, reasonable enhancement to isolate these special characters (as listed by Simo in comment 8, any others?) from current UI handling of toggling as if field data. That UI choice was probably wrong--but does function as designed.  So really not a bug.

Simplest enhancement would be to associate with non-printing character handling of the paragraph breaks. But the better UX might come with implementing a new UI motif and unique color for these elements.

Including in non-printing would be OK for me.
But we may expect people to start complaining about that?
Whatever change is chosen: I'm a fan of easy toggling the visibility on and of.

Created attachment 112753 [details]
More detailed information about these kind of special characters

Meanwhile I found the following sentence in the help: “Field Shadings: Shows or hides field shadings in your document, including non-breaking spaces, custom hyphens, indexes, and footnotes.” If the function will be changed also this text has to be changed.

So it seems that it was intended to use the field shading also for formatting marks and hence it would not be a bug in a narrower sense. But to my opinion it is still rather mistakable. So I would appreciate if formatting marks would be highlighted in a different way. 

In order to get an impression how the different non-printing characters and formatting marks are treated, I examined the current behaviour and created a list with the results. You can find this list inside a document which I will attach to this bug report. My impression is, that there is no clear direction how these special characters are treated. I think the list is not complete, because there are special characters which are used in languages which I do not know. In the list there are also some question marks where I did not know or examine the behaviour. Feel free if you like to complete or enhance the list.

Hence the situation is a bit complicated, a more general approach should be considered. Therefore some questions should be answered. In the attached document I added a list with, what I think are the relevant questions together with some more aspects.