SFML/SFML

Graphic glitch when displaying text containing non-breaking spaces

AerunDev opened this issue · 2 comments

Prerequisite Checklist

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:
2-6-1-tuffy-graphic-issue

And a version with the window enlarged for better observation of the issue:
2-6-1-tuffy-graphic-issue-zoomed

And a version with another font:
Capture d'écran 2024-05-07 184401

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?

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:

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.)