Graphic glitch when displaying text containing non-breaking spaces

[AerunDev]

Prerequisite Checklist

• I searched for existing issues to prevent duplicates
• I searched for existing discussions on the forum to prevent duplicates
• I am here to report an issue and not to just ask a question or look for help (use the forum or Discord instead)

Describe your issue here

We're using SFML with an open-source community to manage the display of our games.
We were previously on version 2.5.0, and since we've upgraded to 2.6.1, we've noticed a graphical issue when displaying text with non-breaking spaces. This is problematic for some languages like French, which uses them to manage word spacing.

We've tested several fonts, and the same issue persists in 2.5.1 and 2.6.1, but not in 2.5.0. It seems that the transition from 2.5.0 to 2.5.1 introduced this problem.

I'm attaching a screenshot:

And a version with the window enlarged for better observation of the issue:

And a version with another font:

Your Environment

• OS / distro / window manager: Windows 11 x64 (but tested on Windows 10 too)**
• SFML version: 2.6.1 (the issue is also verifiable in the 2.5.1 version)
• Compiler / toolchain: Visual Studio 2022
• Special compiler / CMake flags: 32 bits - x86 Release

Steps to reproduce

1. Setup a 2.6.1 32 bits project (x86)
2. Add the font in the resources/ folder
3. Run the following code using 2.6.1
4. Check if the non-breaking space is properly displayed

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(640, 480), "SFML works!");
    sf::Font font;
    // Font from the island example of 2.6.1
    if (!font.loadFromFile("resources/tuffy.ttf"))
        return EXIT_FAILURE;

    sf::Text text;
    text.setFont(font);
    text.setString("L'utiliser sur quelle créature ?");
    text.setCharacterSize(40);
    text.setFillColor(sf::Color::Red);
    text.setStyle(sf::Text::Bold);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(text);
        window.display();
    }

    return 0;
}

Expected behavior

Non-breaking spaces should be properly displayed.

Actual behavior

Seems like a graphic glitch is displayed. If we resize the window it seems like this is a pixel, maybe due to the glyph?

[eXpl0it3r]

Since you didn't mention it explicitly, I assume the "glitch" is the dot at the bottom of e in créature, correct?

Is the question mark not showing with the first font also a glitch or just a difference in the run code?

Potential candidates for the origin of the regression:

• Fixed two issues with glyph sub-pixel positioning #1452
• Fixed bug in sf::Text when applying an outline color/thickness #1176

[NuriYuri]

Hi, allow me to answer. Yes the glitch is the "dot" between the e of créature and the question mark.
The rendering of the question mark is not related (I guess the font he uses in example 1 & 2 does not contain U+FF1F).

The #1452 looks to be a good candidate for the regression, if I find time I'll try to build some binaries without this commit and see. (This candidate might also explain why sometimes smooth gets randomly enabled.)

[AerunDev]

Hello @eXpl0it3r! 😄
Any update on this issue?
I've seen that SFML 3.0 will be ended soon. Do you think a fix for this issue can be included in the 3.0?
Thanks in advance.

[pw-rey]

Hello!
I took the time to build a test case of this issue on both Windows 11 and Ubuntu 22.04 with SFML 2.6.2 and with different fonts (including tutty.ttf).
I tried reverting the two main changes of #1452 as @NuriYuri suggested and it seems like the adding of the "padding" in void addGlyphQuad is what caused the regression.

This test was also successful on SFML 3.0.0, though another unrelated issue arose where the tutty font caused the drawing to stop at the first occurrence of a non-breaking space (which didn’t happen with another font). As it’s unrelated, I can open an issue for this if you think it’s necessary.