BR Windows - UTF-8 non breaking spaces do not work in PopupMenu

[PaulDriessen]

My problem: I have a custom inline subfolder display in popupmenu, I use non breaking spaces for indenting the deeper items. The   is however not working on windows.
my function getNBSP(int n) below should return a non breaking indent

juce::String getNBSP(int n)
{
#if JUCE_WINDOWS
// on windows I have to for form the indent with a visible symbol, to avoid popupmenu
// discarding the whitespace.. Not good!
    juce::String result="";
    for(int t=0; t<n; t++) result.append(".",1);
    return result;
#else
   // this works on macos/ios, with the standard UTF-8 code for non breaking space
    juce::CharPointer_UTF8 sp=juce::CharPointer_UTF8("\xc2\xa0");
    juce::String result="";
    for(int t=0; t<n; t++) result.appendCharPointer(sp);
    return result;
#endif
}

[reuk]

• Most importantly, are you using the latest version of JUCE 8? Unicode text rendering is much improved in recent versions.
• Have you tried a few different fonts on Windows? Do you get the same result with every font you’ve tried?

This seems to work correctly on the develop branch. I modified the GuiAppExample like so:

void MainComponent::paint (juce::Graphics& g)
{
    g.fillAll (getLookAndFeel().findColour (juce::ResizableWindow::backgroundColourId));

    g.setFont (juce::FontOptions (16.0f));
    g.setColour (juce::Colours::white);
    g.drawFittedText (juce::CharPointer_UTF8 ("hello\n\xc2\xa0\xc2\xa0hello\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0hello"),
                      getLocalBounds(),
                      juce::Justification::centredLeft,
                      10,
                      1.0f);
}

The spaces render as expected:

[PaulDriessen]

thanks! I’ll try it asap, I’ve installed 8.0.7 now,
I can not find “gui app example” though, i’ll just try my own stuff with it

[PaulDriessen]

still doesnt work in Juce 8.0.7 on windows:
I store the string including indent in a StringArray, which is fed into popmenu.addItem()
works on macos/ios. default font.

juce::String s=getNBSP(5);   // make indent for subitem
auto f=deepresult.getFileName(); //get the item name
s.append(f,f.length());    // add it to indent
dispStrs.add(s);        // add it to juce::StringArray which feeds popupmenu.addItem()

[reuk]

Please can you provide a simplified minimal example that demonstrates the problem you’re seeing? Ideally, start from a completely blank JUCE project and make the smallest changes necessary to trigger the issue.

We’re unlikely to be able to help unless we can reproduce the same issue ourselves. As I showed above, drawFittedText seems to respect non-breaking spaces on Windows, and that’s the same routine that PopupMenus use to draw text when using the LookAndFeel_V4. So, the issue doesn’t seem to affect all uses of non-breaking spaces.

You said you’re using the default font - are you also using the default LookAndFeel, or have you customised the appearance of the PopupMenu somehow? Are you using custom menu item components? Have you tried drawing the same text outside of a PopupMenu, e.g. in your main app window, and do you see the same results there?

[PaulDriessen]

• I have checked your indent example with drawfittedtext() within the target app: works fine
• I have attached no look and feel to the popupmenu, also no custom menu items.
• the popupmenu is invoked via an onClick() in the editor;
  selector.onClick = [this] { selectFile(); };
• I have only used setFont() on sub component level, not in the editor itself
  On my machine is Windows 11 23H2 from juli 2024.

[stephenk]

So it would seem that what you need to provide is an example project, that has nothing but a single popupmenu in it, done with the way that you populate your menus, demonstrating the issue.

[PaulDriessen]

@reuk @stephenk
I think I know what is happening: I’m still at visual studio 2019
Because I tested in example MenusDemo:
I exchanged a menu item around line 390:
result.setInfo( juce::CharPointer_UTF8 ("\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0RED"),"set the colour..","Outer",0);

It compiles ok, but: no whitespace.
So I think it needs VS2022, but today the site https://visualstudio.microsoft.com is unreachable from my place.
Can someone with VS2022 do a quick check with the MenusDemo example?
thanks for your guidance sofar..

[stephenk]

EDITED

I just tried it on Windows 10, VS2022, using your example juce::CharPointer_UTF8 ("\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0RED" for line 391 and it does NOT show any breaking spaces. I don’t understand really how the version of VS would affect it anyway…
However, I’m not on the develop branch… I’m on 8.0.4.

[PaulDriessen]

ok, so it seems that the non breaking spaces are deleted/disregarded somewhere in PopupMenu.
I have managed to update to VS2022 here too a couple of minutes ago , and it indeed doesn’t matter, it doesn’t work either.

[stephenk]

@reuk - it seems there may be something here; I just downloaded the latest develop, and using the MenusDemo and changing line 391 to:

result.setInfo (juce::CharPointer_UTF8 ("\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0RED"), "Sets the outer colour to red", "Outer", 0);

…I get no breaking spaces.

Windows 10, VS2022

[stephenk]

more…

I discovered an issue: it won’t show the spaces if the line starts with it.

Try this:

result.setInfo (juce::CharPointer_UTF8 ("hello\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0RED"), "Sets the outer colour to red", "Outer", 0);

You will see “hello RED” - so the non-breaking spaces are shown, but not if the line starts with it.

[PaulDriessen]

yes, just as if left aligned text ignores the leading hard spaces..

[reuk]

The behaviour on develop (8.0.8) seems to be consistent with the behaviour from 7.0.12. So, this doesn’t seem to be a regression.

On the develop branch, the text gets trimmed when creating a GlyphArrangement:

modules/juce_graphics/fonts/juce_GlyphArrangement.cpp

trim() eventually calls through to CharacterFunctions::isWhitespace() to determine the first non-whitespace character. This is implemented using the platform iswspace function, which seems to behave differently on macOS and Windows, and may also be affected by the current locale. On Windows, iswspace returns ‘true’ for a non-breaking space, but the same call returns false on macOS.

This has come up before:

BR: Non breaking space not respected on Windows

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.

We’ve now switched the implementation of GlyphArrangement to trim whitespace in the same way on all platforms. As a result, non-breaking spaces should now not be trimmed on any platform.

GlyphArrangement: Use portable string trimming

[PaulDriessen]

thanks for the fix!
how do I sync to this, since I guess this is not included in 8.0.8?
(never did an in between release JUCE update sofar, never use github)