-
Bug
-
Resolution: Unresolved
-
None
-
19w42a, 20w09a, 20w10a, 20w17a, 20w19a, 1.16 Pre-release 4, 1.17, 1.17.1 Pre-release 1, 1.19.1, 23w07a, 1.19.4, 23w12a, 23w13a, 23w14a, 23w17a, 1.20 Pre-release 4, 1.20 Pre-release 5, 1.20 Pre-release 7
-
None
-
Windows 10 (20H2)
Java embedded with the launcher (16.0.1 64bits)
Also on Linux (see comments)
-
Community Consensus
-
Internationalisation
-
Low
-
Platform
Context
No-Break Space (NBSP, U+00A0) and Narrow No-Break Space (NNBSP, U+202F) are characters that are used in some language in place of regular space for typographic reasons. For instance, they are used in french, around some punctuation characters and as thousands separator in big numbers, to avoid automatic line break.
Issue
1. Rendering
EDIT: The rendering issue has been fixed in 23w17a due to the update of unifont into the game. Tests performed on version 1.20-pre4 (see provided screenshots) shows that the rendering issue is fixed in regular Minecraft font and when unicode font is forced.
2. "No-break" behaviour
The NBSP character does not have its "no-break" behaviour when used in chat messages and other situations. Tests performed on version 1.20-pre4 (see provided screenshots) shows that :
- The option to force unicode font does not affect the behaviour issue of (n)nbsp characters.
- When used in /say and /tellraw in commands blocs, both characters act as intended.
- When used in chat messages, and in /say and /tellraw directly from the chatbox, the NBSP character does not act as intended (the line-breaking behaviour still occurs)
- In all test cases, the NNBPS act as expected.
Possible source of the issue
The issue with NBSP seems to come from the chat system, and not elsewhere, thus not affecting command blocks
Before the rendering issue was fixed, NBSP character was badly rendered in the chatbox, but rendered as a space in the message when sent (with line break behaviour). This suggests that NBSP was replaced by a regular space before rendering in chat. Even after the rendering fix (23w17a), NBSP sill acting as a regular space suggets that the NBSP->space replacement still occurs (this may be related to MC-94456).
Possible fixes
"No-break" behaviour
I would just suggest to not replace the NBSP character by a regular space (may cause an issue with flood/spam protection MC-94456).