Following the addition of feature https://wiki.documentfoundation.org/ReleaseNotes/4.3#Light_Blue_for_Non-printing_characters which was a solution to Bug #68071 and after extensive discussion on the Design mailing list http://nabble.documentfoundation.org/Light-Blue-for-Non-printing-characters-tp4110478.html I'm requesting that an option is added to allow the user to manually select any color (from the LO palette or from RGB, whatever is simpler). This would allow people to select a more visible color (or return to the previous black default if they so wish) This is NOT the same request as BUG #79381 which asks for the color of non-printing characters to be automatically adjusted following some rules. My request is that a separate setting is added under Tools > Options > LibreOffice > Appearance > Custom colors> General > Non-printing characters
More niche options? Please, no!
(In reply to comment #1) > More niche options? Please, no! If the color is so unimportant why did a Developer spend his time changing it? Maybe it is not such a niche... In any case this option will allow users to set it back to black if they so wish (which is something you CAN'T do with the Startup Center) The users can ignore options (staying with the Default) but other users can't ignore HARDCODED changes.
Actually it isn't a niche wish at all. The ultimate solution for this problem isn't to provide a way to change the color, but recalculate the color of non printing characters according to the color we have in background (=the color page or in the case of a user is writing in a table,...). This should still be provided as an easy hack IMHO.
The decision we reached both in our vote (https://dudle.inf.tu-dresden.de/Non-printing_characters_color/) and in our monthly meeting of june (https://wiki.documentfoundation.org/Design/Meetings/2014-06-29) is to add this option and change the default color to "Solarized blue".
Created attachment 101981 [details] PNG capturing difference between initial blue for NPC and new agreed "Solarized blue" The new Design / UX agreed default color for NPC is RGB #268bd2 named "Solarized blue" This clip shows that compared to the existing unnamed blue used for NPC with RGB #6abed3 as implemented in bug 68071 As a default, the new blue is a bit more pronounced on both light and darker back grounds. When the enhancement for a Tools -> Options -> Appearance -> Custom Colors control of the NPC variable NON_PRINTING_CHARACTER_COLOR RGB_COLORDATA can be implemented this color as default should be completely functional. In the interim, would suggest that the newly approved color be overlaid on Tomaž's http://cgit.freedesktop.org/libreoffice/core/commit/?id=fb99a6b9958815eb1ad27179d252a379ce8b79fd and included for the 4.3.0 rc2 build.
(In reply to comment #2) > (In reply to comment #1) > > More niche options? Please, no! > > If the color is so unimportant You misunderstood. I said niche OPTIONS, not niche COLORS. Design is trying to remove superflous options to reduce complexity, and IMHO adding a color chooser for non-printing characters is one such superflous setting. If it’s so desperately wanted, it could live buried in Expert Config. Changing component to Writer as the UX Advise has settled on a new color, Solarized Blue (I voted for it as well).
Adolfo, (In reply to comment #6) > I said niche OPTIONS, not niche COLORS. Design is trying to remove > superflous options to reduce complexity, and IMHO adding a color chooser for > non-printing characters is one such superflous setting. If it’s so > desperately wanted, it could live buried in Expert Config. Actually, I'd probably disagree with that, because as a reasonable UX customization that has gained Design team approval, setting a custom color from the Appearance panel is a very logical implementation. Additionally as Expert Config remains a horrible hack at this point--it is really not functional at all for efficiency of UI configuration. Especially a joy if you happen to be using AT. IMHO the Tools -> Options -> Appearance -> Custom Colors remains the most direct and efficient way to implement assignment of alternate color to the NON_PRINTING_CHARACTER_COLOR RGB_COLORDATA as manipulating RGB color assignment to variables either directly or more often via enum lists is how this aspect of the UI is customized, see svtools/colorcfg. Implementing remaining facet of this issue probably rates an easy-hack designation. But if combined with the automated adjustment of bug 78381, and a need to handle display of NPC in modules other than writer it becomes a more substantial development effort.
(In reply to comment #7) s/79381/78381
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c0a7a7e499c07627b15072aeb627fcb4897ea4d6&h=libreoffice-4-3 fdo#80054 change color for NPC to "solarized blue" It will be available in LibreOffice 4.3.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a5d4e237049abec3b6c7d13f25d8bb0773d1df5a fdo#80054 change color for NPC to "solarized blue" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-4-3-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bbb1806f35815497b4bee7eed5334c697825f82f&h=libreoffice-4-3-0 fdo#80054 change color for NPC to "solarized blue" It will be available already in LibreOffice 4.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm rather confused by this issue. The summary asks for an option to select color.. and the commits from Thomasz are changing the color... It this is the request for enhancement, it's a duplicate of bug 79381 :)
See the OP, this is to allow user to manually set the fixed color--either a item in Tools -> Options Advanced: Expert Configuration dialog; or a new item in Tools -> Options -> LibreOffice -> Appearance -> Custom colors -> General Bug 79381 was suggestion to algorithmically assign a color based on the foreground and background color of the active document.
Removing targets 4.3.1 and 4.4.0 keywords for the commits to reassign the fixed color from #6abed3 to #268bd2 -- as in comment 9 comment 10 UI work to provide user customizable NPC color assignment remains to be accomplished.
I strongly support the OP's request. When I reveal Non-Printing Characters, they appear in a blue colour (instead of black). I find this distracting and it interferes with my reading the text. I do not wish to turn off the exposure of the Non-Printing Characters. Al Maloney
Whereas I fully understand the concern of cluttering the prefs too much, I, for one, fully support the notion to make this setting user-definable. (A potential general solution LO would benefit from immensely in this respect in my opinion is "Basic"/ "Advanced" preferences toggle. This could accommodate for the needs of both standard and power users.) Some people want to non-printing characters to remain black, for me 100% opacity and solarised blue is too "visible". (Currently and at least in the OS X version of LO, the "space" dots are way too large and slightly overlap surrounding text in certain cases, significantly limiting readability.) Also, 2 suggestions (seeking peer opinion before considering them as enhancement request posts): a) non-breaking spaces: currently rendered as grey-background space, a new symbol could be used for non-breaking spaces and changed to a standard non-printing character logic b) non-printing characters such as carriage returns, tabs, line breaks, non-breaking spaces, column breaks, page breaks etc. (i.e. ) should be displayed when a block of text is (being) selected even if show non-printing characters is turned off. (Similarly to the way non-printing chars are handled in Pages). It helps A LOT to see what you are really copying and prevents unintential copy-paste mess.
*** Bug 58674 has been marked as a duplicate of this bug. ***
+1 for Expert option "Highlight Non-Printables" = ON | OFF The blue highlighting is counter productive on blueish/greenish backgrounds. Recent discussion on the user forum: https://forum.openoffice.org/en/forum/viewtopic.php?f=5&t=85532
LibreOffice v5.1.5.2 I very much agree with the original poster in this thread I also think LO would be greatly improved by allowing users the option make non-printing characters (NPCs) any colour they please. This setting should be added to Tools > Options > LibreOffice > Application Colours > Non-Printing Characters (and could easily be made to conform to the colour options there available for other elements of LO). There are several reasons why I think this should be done. 1) As it stands just now the light-blue colour doesn't show up well if the user changes the Document Background to a colour that doesn't allow the blue colour NPCs to stand out well in the document. 2) If the user has a free choice on the colour of the NPCs then the user is free to choose colours that are either highly visible or a bit less visible - according to the user's own preference for this kind of thing. (Personally I prefer them highly visible.) 3) If LO introduced an 'automatic colour' scheme for NPCs then the results of the automatic choice made might not be to the liking of the user - doubly so if the user has changed the Document Background colour. What suits one person, the person that coded the automatic colour selection, will not suit all people. 4) I don't think this NPCs colour setting should be made in Advanced Settings. The reason is that it is so easy to change the Document Background colour that the NPCs colour setting should be in the same place as the Document Background colour. Putting such a setting in Advanced Settings does nothing but overly complicate the issue for the average user that just wants to use LO to get things done. I would like to add that I feel *very strongly* that the NPCs colour should be able to be set by the user. This to the extent that I am currently thinking of going back to OpenOffice instead of continuing to use LO because at least in OpenOffice I can very clearly see the NPCs but I can't do that in LO. I really do think this should be a *high priority* issue for LO - this change needs to be made soon.
IMHO, if the user has to change the color of non printing characters manually, this means the piece of software has a design issue, i.e. a UX problem. You specified a bunch of configurations (blueish screen tint, document background color, automatic colour scheme, etc...) which could make these non printing characters nearly invisible because of the same color. This is why I mentioned, way earlier, the ability to recompute the color of non printing characters depending of the color the background of the document has. This could solve this issue. And if that color computation doesn't suit the user's needs, the ability to change that color manually must still be offered to the end user. Whether it should be in the main options or the advanced options should depend on the usage rate of this feature.
*** Bug 106157 has been marked as a duplicate of this bug. ***
*** Bug 79381 has been marked as a duplicate of this bug. ***
Could the solution be similar to bug 116241?
Can we make an easy hack out of this for Writer.. to speed things up a bit. Or has the more substantial change priority.. taking another couple of years if not more to solve.. based on bug 80054 comment 7
*** Bug 141475 has been marked as a duplicate of this bug. ***
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aabb5be81a066c70142e9c15e64ebfbed9994e3c Resolves tdf#80054 - Customization for non-printable character color It will be available in 25.2.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.
To change this color, you need to go to: Tools - Options - LibreOffice - Application Colors - Text Documents - Non-printable characters. Thanks Heiko, working well. Verified with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dda85e275d70d6365009042b8e207337f2e712c2 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Thank you for implementing this optional setting. Confirmed that it works as expected under Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cd4498d32867af26e95de84836b724b4f85ba1b0 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: pt-PT (pt_PT); UI: pt-PT Calc: CL threaded This Enhancement Request can be CLOSED. Thanks!