At the moment, non-breaking spaces can be distinguished from common spaces by their grayed background. But there is no such thing for the non-breaking spaces which are still invisible. See screenshot attached. I suggest to display narrow non-breaking spaces with a lighter gray than the one used to show non-breaking spaces.
Created attachment 83540 [details] spaces in Writer
Correction: But there is no such thing for the _narrow_ non-breaking spaces which are still invisible.
Hi Olivier, THanks for reporting. Probably easy to do, but I can't find it for now: How to add a narrow non-breaking space. I know a non-breaking space can be added with ctrl+shift+space ... not sure how to do a narrow one :). Kind regards, Joren
AFAIK, there is no easy way to type this character with LO. You have to use the Insert Character command. U+202F NARROW NO-BREAK SPACE. But I can easily add this character with my keyboard. And now French users can easily add this character with the “text formatter”, an extension for LO I wrote to help users to format texts according to French typographic rules. http://en.wikipedia.org/wiki/Non-breaking_space (Section Encodings) http://www.fileformat.info/info/unicode/char/202f/index.htm
Changed status to NEW as it is an Enhancement request. Best regards. JBF
As a workaround, copy it from the special character dialogue and put it in a user field. 1. Insert -> Fields -> More Fields -> Variables tab. 2. Under Type, select User Field. 3. Give it a name and paste the special character into the value field. 4. Click on the check mark to add it to the list 5. Insert and Close. Now it can be reused and hovering over it in the text displays the name. Windows Vista 64 Version: 4.4.4.2 Build ID: f784c932ccfd756d01b70b6bb5e09ff62e1b3285
No Way to have an easy-hack her ? From my point of view, it should be mostly a copy-paste from normal non breaking space...
Should we use a ligther gray or just use the same gray as for the non-breaking space?
Since even the non-breaking-hyphen has the same background ...
(In reply to Andreas Heinisch from comment #8) > Should we use a ligther gray or just use the same gray as for the > non-breaking space? I think, it's better to use the same gray, standardized by the user interface to avoid of potential visibility problems. Maybe the size difference is enough to differentiate the (both fixed-length) non-breaking spaces. @Heiko, what is your opinion? @Andreas: thanks for handling this issue!
(In reply to László Németh from comment #10) > I think, it's better to use the same gray, standardized by the user > interface to avoid of potential visibility problems. Yes, also to allow customization per tools > options > colors > Field Shading. And adding too many options there would be awkward.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bbb57e8198863ee7bdadd3f2aac4420c08da94a3 tdf#67669 - Make narrow no-break space visible by drawing a gray background It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
IMHO It would be fine to differentiate theses two spaces. A lighter color for the thin one would be great.
(In reply to Pierre C from comment #13) > IMHO It would be fine to differentiate theses two spaces. A lighter color > for the thin one would be great. It's possible to add a special sign in formatting mark color, like Adobe InDesign does (with all the other special spaces and characters), see thin space here: https://redokun.com/blog/show-hidden-characters-indesign
Andreas Heinisch committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/fb63d0a090b049c16993054f1804e440adeba5d7 tdf#67669 - Make narrow no-break space visible by drawing a gray background It will be available in 7.4.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Did not work in Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded It's still invisibile...
Checked in: Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL and it is visible. Can other users may check it, too?
Works with master and kf5/gtk3/gtk3/gen. Field shadings needs to be on (ctrl+F8) and the respective application color set properly.
Created attachment 181678 [details] demo document This is the demo document. -A non-breaking space between A and B -A narrow no breaking space between B and C
Created attachment 181679 [details] how I seen it with Ctrl+F8 how I seen it with Ctrl+F8
(In reply to Andreas Heinisch from comment #17) > Can other users may check it, too? I got mixed and "interesting" test results. If I insert the narrow non-breaking space character from menu "Insert > Formatting Mark > Insert Narrow Non-Break Space", it's invisible (no gray background shading). OTOH, if I insert the character from the Special Characters dialog (menu "Insert > Special Character..."), it's visible. Checking the inserted space with Alt+X shows that they are both character U+202F. The difference is that the first invisible one is in Liberation Serif font, and the second visible one is in Liberation Sans font. If I change the font of the first character to Liberation Serif, it becomes visible. (In reply to BogdanB from comment #19) > Created attachment 181678 [details] > demo document The above observation is also true for this sample document. The string is in Liberation Serif font when I open it, and the narrow NBSP between B and C is invisible. However if I select only the narrow NBSP and change its font to Liberation Sans, it becomes visible. Selecting the whole string and changing font doesn't work, though. All these behavior is rather puzzling to me. Hope a developer can reproduce what I saw and sort this out. Version Information: Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 2; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded
I confirm the behaviour noticed by Ming Hua in comment 21. It's a corner case.
(In reply to Ming Hua from comment #21) > Checking the inserted space with Alt+X shows that they are both character > U+202F. The difference is that the first invisible one is in Liberation > Serif font, and the second visible one is in Liberation Sans font. If I > change the font of the first character to Liberation Serif, Typo here. I meant "If I change... to Liberation *Sans*" > it becomes > visible.
In content.xml this are differences ---FOR THE FILE WITH A SPACE INSERTED WITH SANS-------- <style:text-properties style:font-name="Liberation Serif" officeooo:rsid="001e498a" officeooo:paragraph-rsid="001e498a"/></style:style><style:style style:name="T1" style:family="text"><style:text-properties style:font-name="Liberation Sans"/></style:style><style:style style:name="T2" style:family="text"><style:text-properties style:font-name="Liberation Sans"/></style:style>< </text:sequence-decls><text:p text:style-name="P1">A B<text:span text:style-name="T1"> </text:span>C</text:p></office:text></office:body></office:document-content> ------- ---FOR THE FILE WITH EVERYTHING IN SERIF-------- <style:text-properties style:font-name="Liberation Sans" officeooo:rsid="001e498a" officeooo:paragraph-rsid="001e498a"/></style:style></ </text:sequence-decls><text:p text:style-name="P1">A B C</text:p></office:text></office:body></office:document-content>
Created attachment 181957 [details] Both fonts using a narrow no break space hm, I still cannot reproduce it in: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 6c0b8669e1f09a8301f3ebd1da21855d84abb2b1 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL
However, I can only reproduce it with the demo document once. After I change the font to Liberation Serif and back to Liberation Sans, it gets visible as well. Maybe after this fix, documents including narrow non-breaking spaces change their xml?
Another observation: if you open the demo document and select the narrow non-breaking space and hit enter in the font box without changing anything, the nbsp gets visible.
So, there is still some place where the NBSP has to be added in order to make it visible.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/01e3c998e63fbf456e7f624adb1cae3d89ed7bb2 tdf#67669 - Make narrow no-break space visible by drawing a gray background It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
May be tested again. Thank you for your findings!
It's perfect now! I tested on many fonts! it' ok Maybe someone can confirm the same on Windows. Verified with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 27892a5e12dada80226f778ab2bd14b1bdaab58a CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
The changes made here are causing a regression in text layout, see bug 152413 for details.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f6935ce552ed625281104a10695de977a131b477 tdf#152413: Revert "tdf#67669 - Make narrow no-break space visible by drawing It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Reopening after the revert in bug 152413
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/c1553cf97e54baecb98c805b19e2913d776a33a7 tdf#152413: Revert "tdf#67669 - Make narrow no-break space visible by drawing It will be available in 7.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
NBS gets the grayed background; NNBS don't. Version: 7.6.7.2 (x86) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: en-US Calc: threaded Version: 24.2.0.3 (x86) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: es-ES Calc: threaded (In reply to Andreas Heinisch from comment #27) > […] if you open the demo document and select the narrow > non-breaking space and hit enter in the font box without changing anything, > the nbsp gets visible. Not for me. For me, the same background color for NBS and NNBS is fine.
(In reply to LeroyG from comment #36) > is fine. "would be".
Trying my luck with https://gerrit.libreoffice.org/c/core/+/167891 See also bug 161196 for follow-up questions.
Abandoned my approach with a SwBlankPortion in https://gerrit.libreoffice.org/c/core/+/167891 since some Arabic characters are not hooked properly. Example text could be رَ ٰ or /sw/qa/extras/layout/data/tdf152413.fodt
(In reply to LeroyG from comment #37) > (In reply to LeroyG from comment #36) > > is fine. > > "would be". (In reply to LeroyG from comment #36) > NBS gets the grayed background; NNBS don't. > > Version: 7.6.7.2 (x86) / LibreOffice Community > Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 > CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: > Skia/Raster; VCL: win > Locale: es-MX (es_MX); UI: en-US > Calc: threaded > > Version: 24.2.0.3 (x86) / LibreOffice Community > Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 > CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: > Skia/Raster; VCL: win > Locale: es-MX (es_MX); UI: es-ES > Calc: threaded > > (In reply to Andreas Heinisch from comment #27) > > […] if you open the demo document and select the narrow > > non-breaking space and hit enter in the font box without changing anything, > > the nbsp gets visible. > > Not for me. > > For me, the same background color for NBS and NNBS is [would be] fine. Narrow no-break space doesn’t show grey for me, on version 24.2.5.2 (X86_64, Win 11). However I’d be much more interested in having a better version of View – Formatting Marks, which doesn’t seem to be mentioned. This shows NBSP as a blue degree sign (everything is blue here), but nothing for U+202F. This item could be enhanced by allowing the user to select what is highlighted, in what colours, and to create sets of different settings. The enhancement would be best kept within the menu item, because Writer users I know are afraid of going into Tools – Options, for fear of touching geek stuff and crashing the application. I think the importance of this bug should be raised to High, because U+202F is needed, not only for big numbers and some oddities of French Typography, but as the recommended format for SI units; the BIPN is coy here, because they know about word processors. The situation is explained in https://jkorpela.fi/chars/si.html, though at the time the author didn’t know about U+202F. SI units are often encountered in many fields, and it ought to be easy for us to get the typography right. An example that led me to make this comment is presenting the time of day. Recently, friends proof-reading an invitation to a local event noticed how ugly 14 h 30 (the usual format in FR) appears with normal spacing, especially in big letters. This is in fact SI, with the ‘min’ unit omitted by convention. Slightly OT, LaTeX does SI formatting automatically, using markup to call the siunitx package; perhaps it would be possible to transpose this to LO, so the user could format highlighted text via a menu item. To the user, this might look a bit like inserting a hyperlink. Maybe the same could be done for big numbers.
(In reply to Christopher R Lee from comment #40) > However I’d be much more interested in having a better version of View – > Formatting Marks, which doesn’t seem to be mentioned. This shows NBSP as a > blue degree sign (everything is blue here)... See also bug 58434 comment 50, https://wiki.documentfoundation.org/ReleaseNotes/24.8 and bug 80054 For NNBSP/U+202F see comment 39. Raising the importance ;-)
*** Bug 163361 has been marked as a duplicate of this bug. ***