Non-printing characters use the same color as text, even changing their color when a custom color is applied to the text, which makes them hard to separate out from normal text. AbiWord, on the other hand, uses a gray for non-printing characters, while iWork Pages uses a light blue, which is more distinct and thus easier to pick out. Perhaps we could use a light blue as well?
Lovely idea - thanks for making this into an issue!
Hi all, thanks Mirek – sounds like a great idea. Maybe, since it would be less conspicuous then, we could enable the non-printing characters by default? Also, how about using the normal selection colour (in most cases that's blue, maybe except on Ubuntu where it's orange) at half the opacity as the colour?
(In reply to comment #2) > Hi all, > > thanks Mirek – sounds like a great idea. Maybe, since it would be less > conspicuous then, we could enable the non-printing characters by default? I wouldn't like them enabled by default (in many cases, they would just be unnecessary clutter). However, iWork shows paragraph symbols on text highlight, indicating whether you're selecting the line break or not. Perhaps we could do that? > Also, how about using the normal selection colour (in most cases that's > blue, maybe except on Ubuntu where it's orange) at half the opacity as the > colour? I'm a bit concerned about the visibility of the characters. I'm not sure we can always rely on the selection color providing enough contrast, especially at 50% opacity. A single solid color would be easier to manage if bugs were to arise. I can suggest the color #6abed3 for now, but please feel free to suggest different ones.
(In reply to comment #3) > I'm a bit concerned about the visibility of the characters. I'm not sure we > can always rely on the selection color providing enough contrast, especially > at 50% opacity. A single solid color would be easier to manage if bugs were > to arise. > > I can suggest the color #6abed3 for now, but please feel free to suggest > different ones. The current color for non-printing characters (NPC) is the same as the font color. So when choosing a color for NPC that is always the same, might be strange sometimes? How does that look on other applications? Other option would be the same color as the font but lighter?
(In reply to comment #4) > (In reply to comment #3) > > > I'm a bit concerned about the visibility of the characters. I'm not sure we > > can always rely on the selection color providing enough contrast, especially > > at 50% opacity. A single solid color would be easier to manage if bugs were > > to arise. > > > > I can suggest the color #6abed3 for now, but please feel free to suggest > > different ones. > > The current color for non-printing characters (NPC) is the same as the font > color. > So when choosing a color for NPC that is always the same, might be strange > sometimes? How does that look on other applications? AbiWord: http://ubuntuone.com/3vsIWE8ZfWFEqm3Wul8PPB Pages: https://discussions.apple.com/___sbsstatic___/migration-images/131/13106490-1.png, https://discussions.apple.com/servlet/JiveServlet/showImage/2-21268196-218167/Screen+Shot+2013-02-18+at+1.01.12+AM.png > Other option would be the same color as the font but lighter? The contrast wouldn't be that good, then, but it is an alternative.
It would be really great to add lower contrast or different color to the non printing characters. I took a look at the way MS Word 2011 behaves on a Mac. Funny thing is that the spaces, for example, are shown by very small dots that are scaled only partially if one zooms in the view of the document. Carriage return characters are blue and show the same strange behaviour when zooming - not growing too much when zooming in and being still visible when zooming out. It makes sense, since even if a page is zoomed out, at 30% for example, when the text is not readable anymore, the paragraph marks keep a visible size. My impression is that a decision must be taken about both colors, sizes and zooming behavior for non-printing characters. Even if an initial solution would be hardcoded and without any user option, it would still be better than the present situation. Many thanks in advance to the kind soul who has the ability to do such changes in the LibreOffice code and wants to work on this issue. Links to screenshots illustrating Word behavior: http://ubuntuone.com/5tDGP6L1Q6n1RAwE6AFX5x http://ubuntuone.com/1oGa4BizBAjXPjbMaOqrWj
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fb99a6b9958815eb1ad27179d252a379ce8b79fd fdo#68071 NPC characters now use a fixed color. 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.
On Windows 7 sp1, 64-bit with Version: 4.3.0.0.alpha0+ Build ID: c8a089d7dfa2527ff25aa144e65d0c96ea90028d TinderBox: Win-x86@39, Branch:master, Time: 2014-02-06_10:29:45 Looks great, subdued but easy to distinguish.
very nice indeed. 4.2.x backport should be considered.
Very nice change. To have a complete fix, I suggest you to add an entry in Tools > Options > LibreOffice > Appearance to set the color for non printing characters. Best regards. JBF
(In reply to comment #10) > To have a complete fix, I suggest you to add an entry in Tools > Options > > LibreOffice > Appearance to set the color for non printing characters. I agree it's a bit unfortunate for the colour to be hardcoded. However, "fixing" this by making it configurable seems like the wrong solution to me. I.e. on default Ubuntu, a light blue colour for non-printing characters will look horrible, because accent colours in the default Ubuntu themes are some kind of orange (or purple). At the same time, studies* show that around .78% percent of Ubuntu users would know how to change the colour on their own. (* There are no studies. Figure is made up.) So, my best idea (still, see comment 2) would be to make the colour depend on the selection colour. Since LibreOffice uses that native selection colour with some transparency applied for selections, how about using the 100% opacity version of the selection colour for non-printing characters then? (That should be conspicuous enough, right?) Also, should that be a new bug or should we re-open this one?
(In reply to comment #11) > Also, should that be a new bug or should we re-open this one? Report that separately. This bug, as described in its summary, is fixed. Don’t mess with that.
Actually I don't quite understand the issue: The "non-printing characters" discussed are not "non-printing characters", but "formatting marks" (well-printable characters (in the sense of isprint()). As you can turn on and off display of formatting marks, I don't quite see the issue, especially if the text in question can be blue anyway. I have the impression it was done, because it could be done, but not because it was necessary or reasonable. What about really unprintable characters (those that are requested but missing in the fonts available)? Those will actually cause a loss of information.
Any solution for Mac OS X users ? According to: https://wiki.documentfoundation.org/ReleaseNotes/4.3#Solarized_blue_for_Non-printing_characters "... Non-printing Characters are shown with "Solarized blue" color (currently not available on Mac OSX)... " It is great that, on other systems, the color of these characters was changed but I don't think this bug is really fixed until a cross-platform solution is reached. By the way, I disagree with Ulrich - this is not something that was done because it could be done: it improves user interface. Seeing spaces, tabs or end of line characters in a way that makes them less conspicuous is an enhancement that is important for some users, me included. Word has a very nice way to deal with these characters - they are shown in a smaller font and their size varies when zooming in or out of the page differently from the main text.
(In reply to Cosmin Saveanu from comment #14) > [...] but I don't think this bug is really fixed until a cross-platform > solution is reached. It is already fixed for OS X, wait for 4.4
Great Adolfo - thank you. Shouldn't that good news be mentioned on the 4.4 release notes page ? https://wiki.documentfoundation.org/ReleaseNotes/4.4
Could you possibly give users a choice as to how they view non printing characters? The previous writer version that used the same color as regular text was fine but the light blue color on the latest Writer version is hard to see - especially space indicator dots - and there doesn't appear to be any way to change the color. If coding a color selection option is too onerous, might I suggest you at least change the light blue to a darker blue? There's always the possibility that I simply can't find the menu option to change the color. I'd appreciate your response.
(In reply to Mirek2 from comment #0) > Non-printing characters use the same color as text, even changing their > color when a custom color is applied to the text, which makes them hard to > separate out from normal text. > > AbiWord, on the other hand, uses a gray for non-printing characters, while > iWork Pages uses a light blue, which is more distinct and thus easier to > pick out. > > Perhaps we could use a light blue as well? Could you possibly give users a choice as to how they view non printing characters? The previous writer version that used the same color as regular text was fine but the light blue color on the latest Writer version is hard to see - especially space indicator dots - and there doesn't appear to be any way to change the color. If coding a color selection option is too onerous, might I suggest you at least change the light blue to a darker blue? There's always the possibility that I simply can't find the menu option to change the color. I'd appreciate your response.
(In reply to Phil C from comment #19) > > There's always the possibility that I simply can't find the menu option to > change the color. I'd appreciate your response. Hi phil, the idea to have a choice or so, is OK. See bug 79381
See bug 80054 for the open enhancement to make this use configurable. Color was already set darker, from #6abed3 to #268bd2 as agreed to by UX-advise and Design team.
*** Bug 86981 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (ProposedEasyHack -> needsDevEval) [NinjaEdit]