-
Hey guys! It has been a while since I have been around on the forum. But now I'm back with a question:
I recently have been developing stuff under Linux. When I was working with Fonts, I noticed that the font size isn't accurate; I had to move the font to achieve what I wanted. Then I compiled the same code under Windows and It looked weird, because the font size was right. I also noticed that this doesn't happen with every font.
Example:
I compiled the following code under both operating systems(I used the font facile sans (http://twicolabs.com/facile-sans-free-font/)):
#include <SFML/Graphics.hpp>
int main()
{
sf::RenderWindow window(sf::VideoMode(500, 500), "Example");
sf::Font font;
font.loadFromFile("font.ttf");
sf::Text text;
text.setFont(font);
text.setPosition(0, 0);
text.setCharacterSize(84);
text.setString("Text");
text.setColor(sf::Color::Black);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear(sf::Color::White);
window.draw(text);
window.display();
}
return 0;
}
This is how it looks under Linux:
(http://i.imgur.com/HuurKAN.png)
Under Windows:
(http://i.imgur.com/hKsYPdM.png)
Does anyone know why this happens and how to fix it?
I appreciate any help :)
-
Can you compile SFML from the following branch and see if it fixes your issue?
https://github.com/SFML/SFML/tree/bugfix/font_fix
-
I uninstalled SFML from my Linux OS and compiled the branch. The git command I used to get the code was
git clone -b bugfix/font_fix --single https://github.com/SFML/SFML.git
I hope this command got me the right repository, I don't know much about git.
The Example Program compiles fine, but the result is still the same :(
Any other ideas?
-
Considering SFML gets all of its glyph metric data from FreeType, and the font data stays the same on both operating systems, I can only assume that the FreeType implementation changes. On Linux, SFML resorts to using the development packages provided through the distribution's package management system, this applies to FreeType as well. On Windows, since nothing similar exists, SFML simply uses the pre-compiled libraries that are provided with the source code. If the versions differ, then something might have changed in FreeType that might lead to different behaviour.
-
I have Linux (Fedora 20) and I get what you get on Windows:
(http://i61.tinypic.com/1ibww3.png)
-
I don't use Fedora Linux but Linux Mint 17, which bases on Ubuntu 14.04. Which version of the freetype development files have you installed?
-
I found out that the dimensions of the text also are different:
Dimensions on Linux: left: 0 top: 19 width: 207 height: 65
Dimensions on Windows: left: -1 top: -2 width: 209 height: 66
Code used to get the dimensions:
sf::FloatRect rect = text.getLocalBounds();
cout << endl << "Width: " << rect.width << " Height: " << rect.height << " Top: " << rect.top << " Left: " << rect.left;
And to achieve the look from windows on linux, I had to set the position of the text to 0, -20 .
-
If you are using the latest freetype from Ubuntu's package repository, it should be version 2.5.2.
I went ahead and checked all the change logs between 2.4.4 (which is what is used on Windows) and 2.5.2 and found this in the change log for 2.4.6 (http://sourceforge.net/projects/freetype/files/freetype2/2.4.6/README/view):
I. IMPORTANT BUG FIXES
- For TrueType based fonts, the ascender and descender values were
incorrect sometimes (off by a pixel if the ppem value was not a
multiple of 5). Depending on the use you might now experience
a different layout; the change should result in better, more
consistent line spacing.
This wasn't the only size/layout related fix that happened between 2.4.4 and 2.5.2. There were many others as well.
So... I guess it really is FreeType that is bugged in the Windows version... Oh well ::) Someone might be nice enough to update the supplied FreeType to 2.5.2 ;D.
-
So... I guess it really is FreeType that is bugged in the Windows version...
According to the screenshots, it's rather his Linux version that is bugged... unless the extra space on top is more correct (accentuated upper case characters?).
Someone might be nice enough to update the supplied FreeType to 2.5.2
I can do it if it's needed.
-
Yes, I'm using freetype version 2.5.2.
And I also think that the Linux version is bugged, unless the space on the top is a specific problem of the font. But I'll see how it looks on Windows after the supplied freetype has been updated.
-
unless the extra space on top is more correct (accentuated upper case characters?).
That is also what I understood. There should be spacing at the top of those characters, on both systems. If an accent was placed on top of the upper case E, it probably wouldn't be visible (off-screen) whereas the correct behaviour would be to accommodate for this even without any accents being present since we are using global font metrics rather than individual glyph metrics.
-
If an accent was placed on top of the upper case E, it probably wouldn't be visible (off-screen)
That's exactly what happened to me on Windows. For instance when displaying a Ê, the accent is not visible (or only bottom pixels).
Also, the line spacing (returned by sf::Font::getLineSpacing) doesn't include the extra space for accents (this is probably the root cause). It can be seen with multiline text, when drawing a letter with a loop (eg. g) above an accentuated capital (eg. Â): both characters overlap.
According to the FreeType tutorial (http://www.freetype.org/freetype2/docs/tutorial/step2.html), the ascender value (used to compute the line height) may have a different meaning depending on the font format. I guess it may also depend on the font itself (some fonts may set invalid values). Still according to this documentation, it should include the space for accents (so the correct rendering would be the Linux version).
You may consider updating your font file for a consistent result. I had the issue with an old version of FreeSans; with a freshly downloaded version, the line spacing includes accent spacing, as expected.
-
It can't be a fix in 2.4.6 because Fedora 20 has 2.5.0. It has to be something after 2.5.0 or some distro specific patch in Ubuntu or Fedora.
-
OK... so I tested this myself on both Windows (with the supplied FreeType 2.4.4) and Arch Linux (with FreeType 2.5.3) and they produced the same result using the font you linked, without any space above the character for accents. If I replace the font with any system provided fonts (e.g. Arial on Windows and DejaVuSans on Linux), they will have space above the characters on both platforms, which is what is expected.
I don't think SFML is directly responsible for this discrepancy. All text rendering code is platform independent and only relies on FreeType and OpenGL, and since I really really can't imagine OpenGL rendering producing different results on different platforms, it can only be the FreeType library you have (perhaps non-standard) or indeed the font file that has something wrong with it.
Until now, nobody else has been able to reproduce it other that you, so unfortunately, we don't have much to work with since it doesn't seem to be easily reproducible :(.
-
I replace the font with any system provided fonts (e.g. Arial on Windows and DejaVuSans on Linux), they will have space above the characters on both platforms, which is what is expected.
Same with DejaVuSans and OpenDyslexicRegular with 2.5.0 on Fedora 20. :P
Until now, nobody else has been able to reproduce it other that you, so unfortunately, we don't have much to work with since it doesn't seem to be easily reproducible :(.
Maybe it's Mint specific bug? If you have USB bootable PC then you could try boot Mint from pendrive. :-\
The sha1 sums of the fonts straight from site are
723ce6489b30fed829e7763db700d50dfc4e26c1 Facile Sans.otf
2c078150376bc66e2a4a20ffa6bbbe7a5c03e752 Facile Sans.ttf
BTW, check yours Cadisol87.
-
OK... I went the whole nine yards and downloaded and installed Linux Mint 17 in a VM and built SFML with FreeType 2.5.2-1ubuntu2.2... And... I get the same result as all the other cases... With that font, there is no spacing on top of the characters. I don't know what else to try anymore :-\.
-
I guess we wait for OP to come back with more info and/or "mark" this as "cannot reproduce". :D
I feel like I just did that to you by suggesting the futile Mint attempt: http://i.giflike.com/1LFAQu5.gif
I'm crying from laughter, sorry. ;D
-
Okay, so I checked the Sha1 sums of the fonts, they seem to be the same as yours:
2c078150376bc66e2a4a20ffa6bbbe7a5c03e752 Facile Sans.ttf
723ce6489b30fed829e7763db700d50dfc4e26c1 Facile Sans.otf
Here (http://i.imgur.com/SXRyFCC.png) is a screenshot of the Synaptic Package Manager, I searched for "libfreetype". It looks like I have the same libfreetype version.
Again, here is the code I used:
#include <SFML/Graphics.hpp>
#include <iostream>
using namespace std;
int main()
{
sf::RenderWindow window(sf::VideoMode(500, 500), "Example");
sf::Font font;
font.loadFromFile("Facile Sans.ttf");
sf::Text text;
text.setFont(font);
text.setPosition(0, 0); // (0, -20) looks good
text.setCharacterSize(84);
text.setString("Text");
text.setColor(sf::Color::Black);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear(sf::Color::White);
window.draw(text);
window.display();
}
return 0;
}
I use the bugfix/font_fix branch of SFML. (https://github.com/SFML/SFML/tree/bugfix/font_fix (https://github.com/SFML/SFML/tree/bugfix/font_fix))
I hope this helps. If you need more information, just ask for it.
-
Yeah... I have no more ideas. I even tried building 2.0rc with your code and it yields the same result, so it really really can't have anything to do with SFML :-\. You can try reinstalling a fresh copy of Mint on a separate partition or in a virtual machine and reproduce the issue there. If you can't reproduce it, you can try to compare where the differences lie between your installation and a fresh copy, there is bound to be some discrepancy.
-
I've set up a VM with Linux Mint, and I'm able to reproduce the problem. I didn't install any updates on the virtual machine, and I only installed the packages cmake-gui, libsfml-dev, codeblocks and g++.
I copied the CB project folder to my wm and compiled the code; it showed me the same results as on my original system.
Now I will build the bugfix branch and try to compile it without code::blocks...
-
So... what happens if you do exact same, except instead of installing libsfml-dev, you grab the latest GitHub master, build it and install it? If it produces the correct results, then libsfml-dev is bogus.
-
So... what happens if you do exact same, except instead of installing libsfml-dev, you grab the latest GitHub master, build it and install it? If it produces the correct results, then libsfml-dev is bogus.
It works perfectly, theres no space on top. Tested with a fresh Mint VM without updates. After I installed SFML in the usr/local directory, the example program didn't start, and showed me an error message that it couldn't find the SFML library, which is weird, since I linked it statically. Then I installed SFML in the root directory and it worked.
I had libsfml-dev installed before I built SFML from source on my original system, but removed it before I started building the library (apt-get remove libsfml-dev and apt-get autoremove, I forgot to simply use purge).
So I guess that libsfml-dev was/is causing the error.
-
Okay, its not the fault of libsfml-dev.
Today, I installed a fresh Arch Linux (x86_64), and It doesn't work. I built SFML from GitHub master with cmake.
The libraries extra/freetype2 2.5.3-2
and extra/libxft 2.3.2-1
were already installed (maybe they are dependencies of cinnamon).
I honestly have no idea what I could do to solve the problem :(
Does somebody have an idea?
-
Today I built SFML from the latest GitHub source on my Win7 PC, and It also had the space on top of the text. I guess my problem is solved now, since my code won't provide different results depending on the operating system anymore! :)