If you use a different size (11 or 13), you get better result because the "horiBearingY" of 'u' and 'n' are equals
But it seems that if the font get loaded with different hint flags, you have also better result.
So after loading the font, you can use:
On 2014-12-19 10:12:05 +0000, Yohann Ferreira wrote:
We see that freetype says "letters 'u' and 'n' have same height".
And also "'u' and 'n' are not aligned" (because of the different horiBearingY).
So, even before rendering the "letters 'u' and 'n' are misplaced".
I am not a freetype expert, but it seems to me, the issue is with freetype.
Using the light font, is just a workaround to have the same font-size without the glitch. (But, who knows, the same kind of issue may appears with other glyph).
On 2014-12-19 21:59:51 +0000, Yohann Ferreira wrote:
Hi Sylvain, :)
Thanks for all the info. there is indeed something fishy with horizBearingY.
Can you tell how you got the info? Did you had some log in sdl ttf?
In fact, I must say I was wondering whether the FT_CEILING and FT_FLOOR could somehow get in the way.
If they don't, the next step is the freetype code source!
On 2014-12-20 08:43:45 +0000, Sylvain wrote:
Yes, the log comes from a few "printf" added into SDL_ttf.c.
The FT_CEIL/FT_FLOOR are also defines in this file.
43 /* Handy routines for converting from fixed point */
44 #define FT_FLOOR(X) ((X & -64) / 64)
45 #define FT_CEIL(X) (((X + 63) & -64) / 64)
I've Tried with freetype 2.5.4, and also freetype 2.4.0. Same issue.
On 2017-09-10 06:02:00 +0000, Sam Lantinga wrote:
I can reproduce this with the SDL_ttf test program:
./showfont ~/Downloads/HelveticaNeue-Regular.ttf 12 "Sun: 2014-07-02"
I'm not sure what we can do if FreeType is returning bad values...
On 2017-09-10 12:03:29 +0000, Sylvain wrote:
I think I did nothing for that, except changing the font.
Maybe let's just close the bug :)
On 2017-09-10 16:19:59 +0000, Sam Lantinga wrote:
Okay, sounds good. :)
The text was updated successfully, but these errors were encountered: