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
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0
Keywords:
Depends on:
Blocks: Formatting-Mark
  Show dependency treegraph
 
Reported: 2020-08-04 21:49 UTC by LeroyG
Modified: 2024-06-22 10:16 UTC (History)
5 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 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 6.3.6.2 (x86); OS: Windows 6.1
Version: 6.3.6.2 (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: 7.1.0.0.alpha0+ (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:

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

U+00A0
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: 7.1.7.2 (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":

https://git.libreoffice.org/core/commit/70c99eef1643a17b2c1f0dba38b55a58cdb9aafc

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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Stéphane Guillou (stragu) 2022-12-28 10:13:35 UTC
Andreas, when doing Ctrl + Left navigation on "a b" (separated by NNBS), LO 7.5 does now lump it with "a" just like it would with a breaking space (an improvement over LO 7.4, which would take the NNBS as a word - thank you for that!).
However, as I understand it, Leroy argues it should behave the same as with a NBS: the whole "a b" is taken as a single word. (It can be tested here in a web browser: at least Firefox does skip the whole string in one go, no intermediate stop at the left of "b".)

Is a follow-up needed for that or am I missing something?
Comment 7 Andreas Heinisch 2022-12-28 14:43:16 UTC
Yes, you are right. We should re-open the ticket and check for a fix.
Comment 8 LeroyG 2023-05-22 13:27:20 UTC
The same at
Version: 7.5.3.2 (x86) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
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
Comment 9 LeroyG 2023-05-22 13:36:11 UTC
(In reply to LeroyG from comment #8)
> The same at

Like in comment #6.
Comment 10 Stéphane Guillou (stragu) 2023-05-25 10:04:42 UTC
Issue is inherited as it is present in OOo 3.3