`setLineAlignment` set to Center/Right makes `getGlobalBounds` incorrect
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 58/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- cpp
- Domain
- computer-graphics
Research direction
Start with the Text API entry points setLineAlignment and getGlobalBounds, then run the supplied C++ reproduction with Left, Center, and Right alignment. Compare each reported bound with the rendered text in the saved image. Done means the global bounds correctly position and enclose the rendered text for all three alignments.
Written by the indexing model from the issue text.
Description
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
getGlobalBounds for text does not seem to have the correct position when setLineAlignment is set anything but Left.
In the below image you can see the below shown code for each of the setLineAlignment values: top image is line alignment set to left, center is center and bottom image is right.
The size of getGlobalBounds remains the same, the position changes, which in the below example I am correcting for, so it still should be covering the whole render texture.
Line alignment set to center seems to move text by half a pixel and line alignment set to right seems to move text by a whole pixel, in which case part of it is drawn outside of the render texture.
I've tested this with a few fonts but below example is the impact font.
Your Environment
- SFML version: 3.1.0
Steps to reproduce
int main()
{
Font f("/usr/share/fonts/Impact-Font-Family/impact.ttf");
Text t(f);
t.setString("Test");
t.setLineAlignment(Text::LineAlignment::Left);
err() << t.getGlobalBounds().position.x << " " << t.getGlobalBounds().position.y << " " << t.getGlobalBounds().size.x << " " << t.getGlobalBounds().size.y << endl;
t.setPosition(-t.getGlobalBounds().position);
RenderTexture tex;
tex.resize(Vector2u(t.getGlobalBounds().size));
tex.clear();
tex.draw(t);
tex.display();
tex.getTexture().copyToImage().saveToFile("bug.png");
}
Expected behavior
Global bounds are correct.
Actual behavior
Global bounds are not correct.
- Dominant language
- C++
- Stars
- 12k
- Forks
- 1.9k
- Avg merge
- 7h 47m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SFML/SFML
-
feature m:sfml-window
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
feature m:sfml-audio
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
bug m:sfml-audio p:macos
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
feature m:sfml-network
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
bug m:sfml-window p:windows
Difficulty 2/5 1-3 hours Newbie friendliness 25/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LadybirdBrowser/ladybird#12123 ·