Marc Baloup
- marcbal
- marcbal
- Europe/Stockholm
- Yes
- No
MC-164687
Low
Normal
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.
These characters are, sometimes, badly rendered or does not behave as intended :
Rendering
Current rendering in chat Current rendering in chat input field Expected rendering NBSP renders like regular space renders a square with "NBSP" inside (in 1.14.4, renders like regular space)should render like regular space NNBSP renders a square with "NNBSP" inside renders a square with "NNBSP" inside should render like regular space but thinner "No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur NNBSP line break does not occur line break muststill not occur even after fixing the rendering problemA workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking
This bug report may be related to
MC-94456.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.
This affect chat messages generated by plugin having multilingual support and/or using Java number formatting using Locale of specific languages.
NBSP and NNBSP are, sometimes, badly rendered or does not behave as intended :
Rendering
Current rendering in chat Current rendering in chat input field Expected rendering NBSP renders like regular space renders a square with "NBSP" inside should render like regular space NNBSP renders a square with "NNBSP" inside renders a square with "NNBSP" inside should render like regular space but thinner (maybe 1px thinner) "No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur NNBSP line break does not occur line break should still not occur even after fixing the rendering problem A workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking.
It seems that NBSP is simply replaced by a regular space before rendering in chat. That fixes the rendering problem but it makes the line breaking where he shouldn’t.
This bug report may be related to
MC-94456.
Windows 10 (
1903)
Java embedded with the launcher (1.8.0_51 64bits)Windows 10 (20H2)
Java embedded with the launcher (16.0.1 64bits)
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.
This affect chat messages generated by plugin having multilingual support and/or using Java number formatting using Locale of specific languages.
NBSP and NNBSP are, sometimes, badly rendered or does not behave as intended :
Rendering
Current rendering in chat Current rendering in chat input field Expected rendering NBSP renders like regular space renders a square with "NBSP" inside should render like regular space NNBSP renders a square with "NNBSP" inside renders a square with "NNBSP" inside should render like regular space but thinner (maybe 1px thinner) "No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur NNBSP line break does not occur line break should still not occur even after fixing the rendering problem A workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking.
It seems that NBSP is simply replaced by a regular space before rendering in chat. That fixes the rendering problem but it makes the line breaking where he shouldn’t.
This bug report may be related to
MC-94456.Possible fixes
Rendering
Probably adding the corresponding character into the font ressource (or whatever how you render the regular space, also render the NBSP the same way and the NNPSP 1pw thinner would be good)
"No-break" behaviour
I think this is the part responsible of the status "Community consensus", probably because the NBPS is replaced by regular space in a chat message, probably to filter potential food (see
MC-94456)
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.
This affect chat messages generated by plugin having multilingual support and/or using Java number formatting using Locale of specific languages.
NBSP and NNBSP are, sometimes, badly rendered or does not behave as intended :
Rendering
Current rendering in chat Current rendering in chat input field Expected rendering NBSP renders like regular space renders a square with "NBSP" inside should render like regular space NNBSP renders a square with "NNBSP" inside renders a square with "NNBSP" inside should render like regular space but thinner (maybe 1px thinner) "No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur NNBSP line break does not occur line break should still not occur even after fixing the rendering problem A workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking.
It seems that NBSP is simply replaced by a regular space before rendering in chat. That fixes the rendering problem but it makes the line breaking where he shouldn’t.
This bug report may be related to
MC-94456.Possible fixes
Rendering
Probably adding the corresponding character into the font res
source (or whatever how you render the regular space, also render the NBSP the same way and the NNPSP 1pwthinner would be good)"No-break" behaviour
I
think this is the part responsible of the status "Community consensus", probably because the NBPS is replaced by regular space in a chat message, probably to filterpotential food (seeMC-94456)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.
This affect chat messages generated by plugin having multilingual support and/or using Java number formatting using Locale of specific languages.
NBSP and NNBSP are, sometimes, badly rendered or does not behave as intended :
Rendering
Current rendering in chat Current rendering in chat input field Expected rendering NBSP renders like regular space renders a square with "NBSP" inside should render like regular space NNBSP renders a square with "NNBSP" inside renders a square with "NNBSP" inside should render like regular space but thinner (maybe 1px thinner) "No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur NNBSP line break does not occur line break should still not occur even after fixing the rendering problem A workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking.
It seems that NBSP is simply replaced by a regular space before rendering in chat. That fixes the rendering problem but it makes the line breaking where he shouldn’t.
This bug report may be related to
MC-94456.Possible fixes
Rendering
Probably adding the corresponding character into the font resource (or whatever how you render the regular space, also render the NBSP the same way and the NNPSP 1px thinner would be good)
"No-break" behaviour
I would just suggest to not fix the rendering problem by replacing these characters by regular space (may cause an issue with flood/spam protection
MC-94456)
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.
This affect chat messages generated by plugin having multilingual support and/or using Java number formatting using
Locale of specific languages.NBSP and NNBSP are, sometimes, badly rendered or does not behave as intended :
RenderingCurrent rendering in chatCurrent rendering in chat input fieldExpected rendering
Current rendering in chat Current rendering in chat input field Expected rendering NBSP renders like regular space renders a square with "NBSP" inside should render like regular space NNBSP renders a square with "NNBSP" inside renders a square with "NNBSP" inside should render like regular space but thinner (maybe 1px thinner) "No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur NNBSP line break does not occur line break should still not occur even after fixing the rendering problem A workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking.
It seems that NBSP is simply replaced by a regular space before rendering in chat. That fixes the rendering problem but it makes the line breaking where he shouldn’t.
This bug report may be related to
MC-94456.Possible fixes
Rendering
Probably adding the corresponding character into the font resource (or whatever how you render the regular space, also render the NBSP the same way and the NNPSP 1px thinner would be good)
"No-break" behaviour
I would just suggest to not fix the rendering problem by replacing these characters by regular space (may cause an issue with flood/spam protection
MC-94456)EDIT : The rendering issue has been fixed in snapshot 23w17a, but the no-break behaviour of NBSP is still missing in chat message.
Original Issue
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.
This affect chat messages generated by plugin having multilingual support and/or using Java number formatting using Locale of specific languages.The NBSP does not behave as intended :
"No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur A workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking.
It seems that NBSP is simply replaced by a regular space before rendering in chat. That fixes the rendering problem but it makes the line breaking where he shouldn’t.
This bug report may be related to
MC-94456.Possible fixes
"No-break" behaviour
I would just suggest to not fix the rendering problem by replacing these characters by regular space (may cause an issue with flood/spam protection
MC-94456)
Windows 10 (20H2)
Java embedded with the launcher (16.0.1 64bits)
Also on Linux (see comments)
EDIT : The rendering issue has been fixed in snapshot 23w17a, but the no-break behaviour of NBSP is still missing in chat message.
OriginalIssueNo-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.
This affect chat messages generated by plugin having multilingual support and/or using Java number formatting using Locale of specific languages.The NBSP does not behave as intended :
"No-break" behaviour
Current behaviour Expected behaviour NBSP line break still occurs line break should not occur
A workaround to fix the no-break effect's problem would be to not consider NBSP and NNBSP as "whitespace" for the function taking care of line breaking.It seems that NBSP is simply replaced by a regular space before rendering in chat. That fixes the rendering problem but it makes the line breaking where he shouldn’t.
This bug report may be related toMC-94456.Possible fixes
"No-break" behaviour
I would just suggest to not
fix the rendering problem byreplacingthesecharactersby regular space (may cause an issue with flood/spam protectionMC-94456)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. RenderingEDIT: 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).
No-Break Space (U+00A0)and Narrow No-BreakSpace(U+202F) does not render/act as intendedNo-Break Space (U+00A0) does not act as a "no-break" space in chat messages and commands issued by players
The bug
When putting a huge amount of particle using the command /particle, the client freeze.
How to reproduce?
On singleplayer or multiplayer, type this command :
/particle minecraft:cloud ~ ~ ~ 0 0 0 1 10000000 forceOn multiplayer, the server will continue to run normally. Only the clients that have to display the particles are freezing.
The bug
When putting a huge amount of particle using the command /particle, the client freeze.
How to reproduce?
On singleplayer or multiplayer, type this command :
/particle minecraft:cloud ~ ~ ~ 0 0 0 1 10000000 forceOn multiplayer, the server will continue to run normally. Only the clients that have to display the particles are freezing.
The bug
When putting a huge amount of particle using the command /particle, the client freeze.
How to reproduce?
On singleplayer or multiplayer, type this command :
/particle minecraft:cloud ~ ~ ~ 0 0 0 1 10000000 forceOn multiplayer, the server will continue to run normally. Only the clients that have to display the particles are freezing.
Possible fixes
Command argument
The argument <count> of the command /particle should have a maximum value:
IntegerArgumentType.integer(0, 16384)Protocol
The Particle packet should have the Particle Count field with a type with lower byte count (Short instead of Int)
Client implementation
The bug
When putting a huge amount of particle using the command /particle, the client freeze.
How to reproduce?
On singleplayer or multiplayer, type this command :
/particle minecraft:cloud ~ ~ ~ 0 0 0 1 10000000 forceOn multiplayer, the server will continue to run normally. Only the clients that have to display the particles are freezing.
Possible fixes
Command argument
The argument <count> of the command /particle should have a maximum value:
IntegerArgumentType.integer(0, 16384)Protocol
The Particle packet should have the Particle Count field with a type with lower byte count (Short instead of Int)
Client implementation
Something like this could be implement when receiving the Particle packet, before rendering:
count = Math.min(count, MAX_PARTICLE)MAX_PARTICLE being the maximum number of particle being displayed simultaneously on the client (currently around 16000)
Oh okay cool, thanks for the info!!
The client could do simple thing like Math.min(count, 16384) before starting to render the particles.
Actually the number of particle is already limited to a fixed value, client side. This is visible in F3 when you summon a lot of particle (spamming fireworks or command), this is always limited to a little more than 16000 (16384 in my previous comment was a guess)
I don’t agree with this.
The Minecraft client already apply a limit to the number of particle simultaneously rendered on the screen. This limit is around 16k and you can notice it in F3 when you spawn a fairly high number of particle using a /particle command or using fireworks. I didn’t find any configuration in the client interface to change that limit.
The existence of this limit implies that the calculation made by the client when trying to render 10M particles is mostly useless, even on a very powerful machine, and the resulting freeze could be avoided by the suggestions I made in the bug description.
The fix I suggest here won’t technically add any "feature" except "avoiding a freeze of the client", that is what I call a bug fix.
The issue is also noticeable on multiplayer on some server. And I'm on Windows 10.
The suggested solution of caching every command at game launch is not possible due to multiplayer that can have additional commands. So the command caching should happen on world load for single player, and on multiplayer every time the server sends the command list to the client. Of course, that loading / caching should be asynchronous, to avoid the game freezing. If the player starts typing "/" in the chat when the cache is still loading, the interface should not freeze either, letting the user typing the command without suggestion.
No, the issue you linked describe an issue with the regular (non-F3) cross-hair being misaligned by a few pixel from the actual center of the screen.
My issue describe the even bigger misalignment of the F3 cross-hair.
But this is definitely related in some way.
It looks like the crosshair is actually shifted either to the left or the right, depending of the size of the game window:
crosshair 1.png
crosshair 2.png
There is also probably the same problem with top/bottom alignment when adjusting the window height, but this is more difficult to observe.
@philhzss its probably for the next snapshot
@jd-dev thanks for the screenshot. You are testing the issue with command blocks (probably /tellraw or /say command), and I was testing with chat messages.
I have tested all conditions and here are the conclusions:
In conclusion, the issue with nbsp seems to come from the chat system, and not elsewhere, thus not affecting command blocks