After a change during the 4.3 development cycle, non-printable characters are now displayed in a light blue (see bug 68071). This is a bit unfortunate for several reasons:
+ lacks desktop integration (e.g. Ubuntu usually uses orange or purple as
accent colors, several other Linux desktops are rather grayish, not sure
whether anyone even thought about high-contrast themes)
+ colour is hard to see for many people
+ Normal case: use desktop selection color with ~50-75% opacity (if the
desktop already uses a half-transparent selection color, use that colour)
+ High-contrast user: use the default desktop selection colour, unless it is
white/black, in which case use a dark blue.
+ For the people that find the default hard to see: offer a check box
on the accessibility page that allows them to enable a mode where the
selection colour is used at 100 percent opacity.
You want a bibisect of this?
if I remember correctly the developer who coded that is Tomaz.
I added him to CC list.
@Joel, comment 1: no need for a bibisect. This was intended & came with http://cgit.freedesktop.org/libreoffice/core/commit/?id=fb99a6b9958815eb1ad27179d252a379ce8b79fd
I think this qualifies perfectly for an easyhack
Another possibility is to add the color to Tools > Options > Writer > Appearance.
(In reply to comment #4)
> I think this qualifies perfectly for an easyhack
Please don't. I believe the option to allow the user to select a colour should be added now to allow users to have options instead of hardcoded decisions...
Making it a easyhack means that no current developer will touch it.
> Another possibility is to add the color to Tools > Options > Writer >
Actually under Tools > Options > LibreOffice > Appearance
See this topic
This is clearly an enhancement request--setting it so.
IMHO I find Mirek's suggested #6abed3 as implemented by Tomaž V. for resolving bug 68071 to be exactly the correction needed to make the NPC distinguishable against paragraph text on a white or black (hi-contrast) document background.
Anything beyond that seems to be rather low priority polishing requiring non-trivial GUI work--both this idea for automated NPC coloring based on configuration, and Pedro's new bug 80054 to directly control it.
Seems there are other more substantive GUI issues that deserve development cycles, to the extent that I would even suggest that this and 80054 enhancements be set LOW or LOWEST priority.
Removing comma from the whiteboard.
Changing CamelCase -> wimpyCaps.
No idea what the importance should be low, in stead of medium..
Migrating Whiteboard tags to Keywords:(needDevEval -> needsDevEval)
(Harmonize spelling of term)
*** This bug has been marked as a duplicate of bug 80054 ***