Bug Hunting Session
Bug 58434 - Show formatting marks when displaying non-printing characters <Ctrl>+F10, rather than field shading <Ctrl>+F8 (for formatting marks as in comment 18)
Summary: Show formatting marks when displaying non-printing characters <Ctrl>+F10, rat...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 52526 63538 121256 128411 (view as bug list)
Depends on:
Blocks: Formatting-Mark 121596
  Show dependency treegraph
 
Reported: 2012-12-17 20:40 UTC by Alexandre Demers
Modified: 2019-10-27 14:42 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
nonbreaking characters under LO (19.10 KB, image/jpeg)
2012-12-17 20:49 UTC, Alexandre Demers
Details
nonbreaking characters under MS Office (14.82 KB, image/jpeg)
2012-12-17 20:50 UTC, Alexandre Demers
Details
Example of nonbreaking characters with grey background (10.14 KB, application/vnd.oasis.opendocument.text)
2013-11-25 01:08 UTC, Alexandre Demers
Details
More detailed information about these kind of special characters (23.74 KB, application/vnd.oasis.opendocument.text)
2015-01-23 23:17 UTC, Harald Koester
Details
Use of special characters 2.0 (49.82 KB, application/vnd.oasis.opendocument.text)
2015-01-25 22:06 UTC, Simo Kaupinmäki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Demers 2012-12-17 20:40:18 UTC
To improve readability when writing, reading and reviewing text, it would be visually better to display nonbreaking characters (space and hyphen) as regular characters. For now, they are displayed with a gray background.

The gray background should only be visible when displaying nonprintable/special characters or, instead of a gray background, a different sign could be used like Word does when displaying special characters.
Comment 1 Alexandre Demers 2012-12-17 20:49:31 UTC
Created attachment 71693 [details]
nonbreaking characters under LO

You can see nonbreaking characters under LO displayed with a gray background, as if they were highlighted.
Comment 2 Alexandre Demers 2012-12-17 20:50:30 UTC
Created attachment 71694 [details]
nonbreaking characters under MS Office

The same text under MS Office Word is displayed as regular characters, which is visually easier to read.
Comment 3 Joel Madero 2013-11-25 00:05:05 UTC
I'm sorry just not following this bug report:

What might help:

Provide reproducible steps
An attachment of an actual document showing these gray areas

I don't see gray areas at all in Linux with or without non printing characters visible.

Marking as NEEDINFO - with additional information you can mark the bug as UNCONFIRMED but please provide very explicit steps so it's easier to follow what's going on. 


Thanks!
Comment 4 Alexandre Demers 2013-11-25 01:05:24 UTC
(In reply to comment #3)
> I'm sorry just not following this bug report:
> 
> What might help:
> 
> Provide reproducible steps
> An attachment of an actual document showing these gray areas
> 
> I don't see gray areas at all in Linux with or without non printing
> characters visible.
> 
> Marking as NEEDINFO - with additional information you can mark the bug as
> UNCONFIRMED but please provide very explicit steps so it's easier to follow
> what's going on. 
> 
> 
> Thanks!

I'm under Linux, using latest stable LO available and I can still reproduce it every time. I also use LO daily on Windows. In both cases, I can see what I reported and explained. I can also see it on all 5 computers at work. Were you typing nonbreaking characters as explained in the screenshots?

I'll be attaching an example right now.
Comment 5 Alexandre Demers 2013-11-25 01:08:59 UTC
Created attachment 89725 [details]
Example of nonbreaking characters with grey background

All the nonbreaking characters have a grey background as if they were highlighted in grey. They are between the brackets []. They can be seen with or without activating the display of special characters.
Comment 6 Alexandre Demers 2013-11-25 01:10:54 UTC
(In reply to comment #5)
> Created attachment 89725 [details]
> Example of nonbreaking characters with grey background
> 
> All the nonbreaking characters have a grey background as if they were
> highlighted in grey. They are between the brackets []. They can be seen with
> or without activating the display of special characters.

replace "special characters" by "printing characters" in the sentence.
Comment 7 Joel Madero 2013-11-25 01:46:00 UTC
Thank you for reporting this enhancement request! I can confirm that this is a valid enhancement request on:
Version: 4.2.0.0.alpha0+Build ID: 09a4c4d176ff97ab8ff4027af83a549991667baf
Date:   Sat Nov 16 20:32:43 2013 +0100 
Platform: Ubuntu Linux 13.04 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
As I've been able to confirm the enhancement request I am marking as:

New (confirmed)
Enhancement
Medium


Whiteboard Status - ProposedEasyHack

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 8 Simo Kaupinmäki 2014-06-13 16:01:37 UTC
The grey background is actually field shading, which can be toggled on and off separately (View > Field Shadings). But I agree that it would be more intuitive if the highlighting of these formatting characters was linked to the visibility of non-printing characters.

Besides no-break space (U+00A0) and non-breaking hyphen (U+2011), there are other characters that have field shading, including at least soft hyphen (U+00AD), zero width space (U+200B), and word joiner (U+2060). On the other hand, narrow no-break space (U+202F) and figure space (U+2007), for example, do not have field shading, although they are also exceptional as regards line breaking.
Comment 9 Simo Kaupinmäki 2014-06-13 16:05:10 UTC
*** Bug 63538 has been marked as a duplicate of this bug. ***
Comment 10 Simo Kaupinmäki 2014-06-13 18:08:36 UTC
*** Bug 52526 has been marked as a duplicate of this bug. ***
Comment 11 Yousuf Philips (jay) (retired) 2014-12-31 12:39:02 UTC
With the grey being visible and invisible depending on View > Field Shadings when its not a field like page number or date, this is a bug in my opinion and not an enhancement.
Comment 12 Jean-Francois Nifenecker 2015-01-01 08:11:04 UTC
I agree with Jay. The grey shading (or whatever colour) should appear only when the nonbreaking chars are made visible.
Comment 13 Harald Koester 2015-01-07 12:51:58 UTC
I also agree with Jay that using the field shading colour for formatting marks is a bug. Hence I have changed importance to 'medium normal'.

But what is the correct function? I think this has not been properly defined yet. And so this is the enhancement part of this bug report.

I also see the necessity to visualize this kind of characters. To display them with a shading, if the nonprinting characters are displayed, may be a solution. But in this case two things have to be taken into account: 
(1) The term 'nonprinting character' is no longer correct, because some of the formatting marks are printable. It may be better to have an additional item in the View menu in order to display formatting marks.
(2) It may be possible that background colours are used and these colours may be equal or similar to the shading colour. For this case an algorithm should be implemented in order to ensure, that there is a sufficient contrast between shading and background colour.
Comment 14 Yousuf Philips (jay) (retired) 2015-01-10 15:52:04 UTC
Like Harald suggested, i agree that the display of formatting marks should be settable in the view menu and in that way it is independent from regular and non-printable character view modes like it is right now. It should be turned off by default, as it is not needed by most regular users, similar to non-printable characters is also turned off by default.

It should be noted that there is no visual difference between a number of these kinds of characters when the gray background is shown. (e.g. non-breaking hyphen and soft hyphen)
Comment 15 V Stuart Foote 2015-01-10 17:16:36 UTC
Yup, reasonable enhancement to isolate these special characters (as listed by Simo in comment 8, any others?) from current UI handling of toggling as if field data. That UI choice was probably wrong--but does function as designed.  So really not a bug.

Simplest enhancement would be to associate with non-printing character handling of the paragraph breaks. But the better UX might come with implementing a new UI motif and unique color for these elements.
Comment 16 Cor Nouws 2015-01-18 11:13:42 UTC
Including in non-printing would be OK for me.
But we may expect people to start complaining about that?
Whatever change is chosen: I'm a fan of easy toggling the visibility on and of.
Comment 17 Harald Koester 2015-01-23 23:17:59 UTC
Created attachment 112753 [details]
More detailed information about these kind of special characters

Meanwhile I found the following sentence in the help: “Field Shadings: Shows or hides field shadings in your document, including non-breaking spaces, custom hyphens, indexes, and footnotes.” If the function will be changed also this text has to be changed.

So it seems that it was intended to use the field shading also for formatting marks and hence it would not be a bug in a narrower sense. But to my opinion it is still rather mistakable. So I would appreciate if formatting marks would be highlighted in a different way. 

In order to get an impression how the different non-printing characters and formatting marks are treated, I examined the current behaviour and created a list with the results. You can find this list inside a document which I will attach to this bug report. My impression is, that there is no clear direction how these special characters are treated. I think the list is not complete, because there are special characters which are used in languages which I do not know. In the list there are also some question marks where I did not know or examine the behaviour. Feel free if you like to complete or enhance the list.

Hence the situation is a bit complicated, a more general approach should be considered. Therefore some questions should be answered. In the attached document I added a list with, what I think are the relevant questions together with some more aspects.
Comment 18 Simo Kaupinmäki 2015-01-25 22:06:59 UTC
Created attachment 112798 [details]
Use of special characters 2.0

Thanks for the comparison table, which certainly helps in seeing the big picture. However, there seems to be confusion about some Unicode characters, so I have reordered the table and added background colors in cells as an attempt to make it a little clearer overall. I have also omitted some of the name variants (including the German names) and instead added new columns for line-break behavior, samples and notes. The character list is still not complete, since Unicode has, for example, many more space characters in different widths, but most of these allow line breaks in the same way as the normal space, so I don't regard them as particularly problematic here.

I think the primary concern is to be able to show and identify any character that behaves differently from what the user is likely to expect. As far as I can see, exceptional line breaks are the most common case of this. 

(Also take notice of the comments included in the original table by Harald. These have been omitted from my version.)
Comment 19 Yousuf Philips (jay) (retired) 2015-04-27 05:05:19 UTC
Lets see if we can get some evaluation by a dev with some code pointers.
Comment 20 Cor Nouws 2015-05-04 09:41:48 UTC
(In reply to Harald Koester from comment #17)
> Created attachment 112753 [details]
> More detailed information about these kind of special characters

thanks a lot! Nice :)

(Side note: I expect Field: Hidden text and Field: Hidden paragraph to be shown with Ctr+F9)

> Meanwhile I found the following sentence in the help: “Field Shadings: Shows
> or hides field shadings in your document, including non-breaking spaces,
> custom hyphens, indexes, and footnotes.” If the function will be changed
> also this text has to be changed.

Indeed. Good catch!

> Hence the situation is a bit complicated, a more general approach should be
> considered. Therefore some questions should be answered. In the attached
> document I added a list with, what I think are the relevant questions
> together with some more aspects.

Yes... but in your document I see no blocking for the common opinion in this issue that toggling the visibility with non printing characters makes more sense.

(I expect that the current behavior origins from the code, that they work more like fields.)

I would say: +2 and go..
Comment 21 Robinson Tryon (qubit) 2015-12-13 11:24:00 UTC Comment hidden (obsolete)
Comment 22 Yousuf Philips (jay) (retired) 2016-09-22 04:14:12 UTC
So this issue should also cover other non-printing characters that have gray backgrounds like soft hyphen, non-width optional break, and non-width no break.
Comment 23 Xisco Faulí 2017-09-29 08:50:02 UTC Comment hidden (obsolete, spam)
Comment 24 Cor Nouws 2017-09-29 21:19:58 UTC
sill in Version: 6.0.0.0.alpha0+
Build ID: 892c719fffa06de4c7aeab497326cad7bae9e5c6
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-27_03:02:09
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 25 QA Administrators 2018-09-30 02:49:19 UTC Comment hidden (obsolete)
Comment 26 Heiko Tietze 2018-10-02 11:05:33 UTC
One vote is for simplicity but the majority wants a separation of text formatting from fields. Removing UX, once it is implemented we can talk about the right visualization.

See also the discussion around URLs that are better not be treated as field. Meaning, we could check what items is a field at all.
Comment 27 Thomas Lendo 2018-10-09 18:41:18 UTC
(In reply to Yousuf Philips (jay) (retired) from comment #14)
> Like Harald suggested, i agree that the display of formatting marks should
> be settable in the view menu and in that way it is independent from regular
> and non-printable character view modes like it is right now. It should be
> turned off by default, as it is not needed by most regular users, similar to
> non-printable characters is also turned off by default.

(In reply to V Stuart Foote from comment #15)
> Yup, reasonable enhancement to isolate these special characters (as listed
> by Simo in comment 8, any others?) from current UI handling of toggling as
> if field data. [...]
> Simplest enhancement would be to associate with non-printing character
> handling of the paragraph breaks. But the better UX might come with
> implementing a new UI motif and unique color for these elements.
I vehemently support the idea of a new setting, separated from fields and non-printable characters.

This should also be considered for other components, not only Writer.
Comment 28 Heiko Tietze 2018-10-11 08:32:52 UTC
Could be an easyhack
Comment 29 V Stuart Foote 2018-11-07 21:38:52 UTC
*** Bug 121256 has been marked as a duplicate of this bug. ***
Comment 30 ajlittoz 2018-11-08 10:42:07 UTC
No objection to set bug 121256 as a duplicate to this one, but don't forget to add U+200E LEFT-TO-RIGHT MARK, U+200E RIGHT-TO-LEFT MARK and U+202C POP DIRECTIONAL FORMATTING to the list of formatting marks (only the first one is present in attachment 112798 [details] and POP is missing in attachment 112753 [details])
Comment 31 V Stuart Foote 2019-10-27 14:42:33 UTC
*** Bug 128411 has been marked as a duplicate of this bug. ***