Bug 68071 - Editing: Non-printing Characters are Not Set Apart from Text
Summary: Editing: Non-printing Characters are Not Set Apart from Text
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:4.3.0
Keywords: needsDevEval
: 86981 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-08-13 16:08 UTC by Tin Man
Modified: 2020-05-17 13:15 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tin Man 2013-08-13 16:08:55 UTC
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?
Comment 1 Cor Nouws 2013-08-13 17:03:56 UTC
Lovely idea - thanks for making this into an issue!
Comment 2 Stefan Knorr (astron) 2013-08-22 14:02:07 UTC
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?
Comment 3 Tin Man 2013-08-22 19:02:44 UTC
(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.
Comment 4 Cor Nouws 2013-08-26 11:18:36 UTC
(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?
Comment 5 Tin Man 2013-08-27 14:14:45 UTC
(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.
Comment 6 Cosmin Saveanu 2013-09-03 09:50:42 UTC
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
Comment 7 Commit Notification 2014-02-06 08:28:05 UTC
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.
Comment 8 V Stuart Foote 2014-02-09 02:10:40 UTC
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.
Comment 9 tommy27 2014-02-19 16:48:34 UTC
very nice indeed. 4.2.x backport should be considered.
Comment 10 Jean-Baptiste Faure 2014-02-22 22:17:52 UTC
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
Comment 11 Stefan Knorr (astron) 2014-02-22 22:29:34 UTC
(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?
Comment 12 Adolfo Jayme Barrientos 2014-02-23 18:07:30 UTC
(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.
Comment 13 Ulrich Windl 2014-10-14 07:04:24 UTC
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.
Comment 14 Cosmin Saveanu 2014-10-14 08:23:54 UTC
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.
Comment 15 Adolfo Jayme Barrientos 2014-10-15 06:47:59 UTC
(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
Comment 16 Cosmin Saveanu 2014-10-15 08:51:37 UTC
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
Comment 17 Phil C 2014-11-26 18:45:28 UTC
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.
Comment 18 Phil C 2014-11-26 18:46:11 UTC
(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.
Comment 19 Phil C 2014-11-26 18:46:49 UTC Comment hidden (obsolete)
Comment 20 Cor Nouws 2014-11-26 19:34:01 UTC
(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
Comment 21 V Stuart Foote 2014-11-26 20:35:23 UTC
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.
Comment 22 Adolfo Jayme Barrientos 2014-12-04 16:25:37 UTC
*** Bug 86981 has been marked as a duplicate of this bug. ***
Comment 23 Robinson Tryon (qubit) 2015-12-18 10:13:02 UTC Comment hidden (obsolete)