Bug 80054 - Enhancement request: Add option to allow user to select color of non-printing characters
Summary: Enhancement request: Add option to allow user to select color of non-printing...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 58674 79381 106157 141475 (view as bug list)
Depends on:
Blocks: Formatting-Mark Authors Automatic-Color
  Show dependency treegraph
 
Reported: 2014-06-15 15:48 UTC by Pedro
Modified: 2023-11-23 09:18 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
PNG capturing difference between initial blue for NPC and new agreed "Solarized blue" (7.58 KB, image/png)
2014-06-29 18:31 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro 2014-06-15 15:48:22 UTC
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
Comment 1 Adolfo Jayme Barrientos 2014-06-16 17:48:58 UTC
More niche options? Please, no!
Comment 2 Pedro 2014-06-16 18:01:07 UTC
(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.
Comment 3 William Gathoye 2014-06-21 17:05:35 UTC
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.
Comment 4 Laurent Lyaudet 2014-06-29 17:00:11 UTC
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".
Comment 5 V Stuart Foote 2014-06-29 18:31:37 UTC
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.
Comment 6 Adolfo Jayme Barrientos 2014-06-30 04:29:38 UTC
(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).
Comment 7 V Stuart Foote 2014-06-30 04:57:20 UTC
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.
Comment 8 V Stuart Foote 2014-06-30 05:25:19 UTC
(In reply to comment #7)
s/79381/78381
Comment 9 Commit Notification 2014-07-15 13:04:11 UTC
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.
Comment 10 Commit Notification 2014-07-15 13:36:39 UTC
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.
Comment 11 Commit Notification 2014-07-15 16:04:12 UTC
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.
Comment 12 Cor Nouws 2014-11-26 20:40:40 UTC
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 :)
Comment 13 V Stuart Foote 2014-11-26 21:59:24 UTC
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.
Comment 14 V Stuart Foote 2014-11-27 04:05:11 UTC
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.
Comment 15 Al Maloney 2015-01-04 00:15:06 UTC
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
Comment 16 Dan 2015-01-28 09:18:09 UTC
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.
Comment 17 Cor Nouws 2015-09-01 07:41:41 UTC
*** Bug 58674 has been marked as a duplicate of this bug. ***
Comment 18 Andreas Säger 2016-10-11 17:28:10 UTC
+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
Comment 19 Radish 2016-10-11 19:26:37 UTC
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.
Comment 20 William Gathoye 2016-10-12 11:49:12 UTC
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.
Comment 21 V Stuart Foote 2017-02-24 15:14:01 UTC
*** Bug 106157 has been marked as a duplicate of this bug. ***
Comment 22 V Stuart Foote 2017-02-24 15:20:22 UTC
*** Bug 79381 has been marked as a duplicate of this bug. ***
Comment 23 Aron Budea 2018-08-10 16:22:45 UTC
Could the solution be similar to bug 116241?
Comment 24 Telesto 2020-05-17 15:02:31 UTC
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
Comment 25 Dieter 2021-04-18 10:57:47 UTC
*** Bug 141475 has been marked as a duplicate of this bug. ***