Bug 135451 - EDITING: Different behavior with No-break space and Narrow no-break space
Summary: EDITING: Different behavior with No-break space and Narrow no-break space
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: All All
: medium enhancement
Assignee: Andreas Heinisch
Whiteboard: target:7.5.0
Depends on:
Blocks: Formatting-Mark
  Show dependency treegraph
Reported: 2020-08-04 21:49 UTC by LeroyG
Modified: 2022-08-21 12:14 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description LeroyG 2020-08-04 21:49:52 UTC
Non-breaking spaces¹ and non-breakable narrow space² behave differently when combining Ctrl(+Shift) with left and right arrows, backspace and delete keys.

¹(Ctrl+Shift+Space; Unicode: No-break space, U+00A0)
²(Shift+Alt+Space; Unicode: Narrow no-break space, U+202F)

Test case with non-breaking space:
1.a. Type a Ctrl+Shift+Space b (without spaces)
1.b. Press Ctrl+Left arrow, and the cursor will go to the left of "a"
Non-breaking spaces within a word behave as part of the word.

Steps to reproduce:
2.a. Type a Shift+Alt+Space b (without spaces)
2.b.1. Press Ctrl+Left arrow, and the cursor will go to the left of "b"
2.b.2. Press again Ctrl+Left arrow, and the cursor will go to the left of the non-breakable narrow space
2.b.3. Press again Ctrl+Left arrow, and finally the cursor will go to the left of "b"
Non-breakable narrow spaces (NBNS) within a word, for this issue, makes it to behave as NBNS*2+1 words; in this example three words.

Expected behavior³ instead of 2.b.1 to 2.b.3.:
2.b. Press Ctrl+Left arrow, and the cursor will go to the left of "a"

³Especially in large numbers.

For "Word and character count", both spaces count as characters but do not count as word; like (normal) space.

For the character I am using "space".
For the key I am using "Space". Although dictionaries spell it as "Space bar", in LibreOffice Help, "Space" and "Spacebar" are used interchangeably (https://help.libreoffice.org/6.4/en-US/text/swriter/04/01020000.html, https://help.libreoffice.org/6.4/en-US/text/shared/optionen/01040600.html).

LibreOffice (x86); OS: Windows 6.1
Version: (x86)
Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: es-MX (es_MX); UI-Language: en-US
Calc: threaded
Comment 1 V Stuart Foote 2020-08-04 22:59:30 UTC
OK, confirming on 2020-07-29 TB77 Windows build of master
Version: (x64)
Build ID: <buildversion>
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

The LibreOFfice assigned shortcuts are:

Alt+Shift+Space -- Insert Narrow No-break Space (.uno:InsertNarrowNobreakSpace)

Ctrl+Shift+Space -- Insert non-breaking space (.uno:InsertNonBreakingSpace)

Or, done efficiently with the convenient <Alt>+X toggle of a Unicode entry.

The non-breaking spaces probably should have the same ICU lib handling for either in that neither should be counted as word bounds--strings should be 1 word. And the <Ctrl> <R,L> should move to beginning or end of either (it does for the NBS, not for the NNBS).

The NBS word bound movement is correct (inherited from OOo), the NNBS was only command was only added recently by Heiko with https://gerrit.libreoffice.org/c/core/+/66776/ for bug 121596 and maybe needed more work on the edit shell behavior.

And for many of these NPC/formatting marks we do have bug 58434 to get them all on the same toggle control for visibility on document canvas.
Comment 2 LeroyG 2020-11-19 20:53:30 UTC
NNBS (U+202F) also affect the use of decimal tab stops.

Having a number (e.g. 12 345.6) with NNBS as thousand separator will align at the right of 12 not of 345.
Comment 3 LeroyG 2021-11-09 12:21:56 UTC
The same at
Version: (x86) / LibreOffice Community
Build ID: c6a4e3954236145e2acb0b65f68614365aeee33f
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
Comment 4 Andreas Heinisch 2022-07-28 14:18:59 UTC
The word boundaries in LO are processed using u_isWhitespace that excludes the no-break-spaces. 

The Unicode functions defined in [1] can be used:

u_isUWhiteSpace=UCHAR_WHITE_SPACE: Unicode White_Space property; most of general categories "Z" (separators) + most whitespace ISO controls (including no-break spaces, but excluding IS1..IS4)
u_isWhitespace: Java isWhitespace; Z + whitespace ISO controls but excluding no-break spaces
u_isJavaSpaceChar: Java isSpaceChar; just Z (including no-break spaces)
u_isspace: Z + whitespace ISO controls (including no-break spaces)
u_isblank: "horizontal spaces" = TAB + Zs

[1] https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/uchar_8h.html

We could add simply the Narrow no-break space, U+202F, as a workaround
Comment 5 Commit Notification 2022-08-21 12:13:33 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":


tdf#135451 - Change the skipSpace implementation of the break iterator

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:

Affected users are encouraged to test the fix and report feedback.