BR: Non breaking space not respected on Windows

If the following string, there is only one space, between “Series” and “7”. However, on Windows 10, when drawing the string, it is adding a line break before the 2 where there is a non breaking space. Also, since there is enough room on the second line without breaking it, why is it breaking into a 3rd line anyway?

Looks correct on macOS:

The following code returns different values on macOS (false) and Windows (true):

bool ws = juce::CharacterFunctions::isWhitespace (juce::String (juce::CharPointer_UTF8 ("\xc2\xa0"))[0]);

So macOS doesn’t think a non breaking space is whitespace and glyph layout doesn’t break the string. But Windows does think a non breaking space is whitespace, so it thinks it’s an ok place to break the string.


I see this problem on my end all the time. std::iswspace is definitely an awkward function because of its inconsistency across toolchains and its locale dependency.

If you try with JUCE_USE_DIRECTWRITE set to 1, do you still see this? If so, then either JUCE is playing with the whitespace in some way, or Windows’ text layout is just being silly.

Here is another case I don’t understand. “HandsUp-Electro Bass” is the shortest string, but it’s 3 lines. “HandsUp-Electro Bass 2” and “HandsUp-Electro Bass 3” are longer strings, but they are 2 lines.

If there is an intention to split in 3 lines it could be to balance the lines to be as close in width as possible. If there is a Justification setting it’s worth to check. But could also be accidentally.

The settings for all three examples here are the same. It’s using justification::centered (so vertically and horizontally).

It makes no sense why the first case was split across three lines and the other two across two lines. All three should be split across two lines only because that’s all it takes to fit.

I am totally with you, it should come out the same for all three.
I was merely thinking what could have led to the difference in behaviour.

Thanks for reporting. The issue indeed arises because iswspace behaves differently between macOS and Windows.

I’ve added a fix here:

1 Like