Created attachment 1729 [details]
the font

Created attachment 1730 [details]
screenshot

When using size 12, the 'n' gets a bad "horiBearingY" value from freetype (at least compared to the 'u').
This is the Y offset, when writing in horizontal layout.

See:
http://www.freetype.org/freetype2/docs/glyphs/
http://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html

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:

  TTF_SetFontHinting(font, TTF_HINTING_LIGHT);

Hi Sylvain, :)

I'm no SDL_ttf Guru master but I've been having a similar problem with my own app, and I've tried to sum up the problem and how we fixed it there:
https://bugzilla.libsdl.org/show_bug.cgi?id=2104#c12

Hopefully, this will help you or anyone else have info on the possible root cause of the problem.

Best regards,

Hi Yohann,

For the record, this issue is from another person, see this thread : 
http://forums.libsdl.org/viewtopic.php?p=44210

The font is "scalable".

Values from freetype seems to have the glitch.

I think SDL handles correctly the y offset. The glitch is already present in the freetype value (due to freetype rendering/scaling/filtering).

(freetype version is 2.5.2)

Cheers

scalable[S] horibearingY = 576 height = 576 font.ascent=12
scalable[u] horibearingY = 448 height = 448 font.ascent=12
scalable[n] horibearingY = 384 height = 448 font.ascent=12
scalable[:] horibearingY = 448 height = 448 font.ascent=12
scalable[ ] horibearingY = 0 height = 0 font.ascent=12
scalable[2] horibearingY = 576 height = 576 font.ascent=12
scalable[0] horibearingY = 576 height = 576 font.ascent=12
scalable[1] horibearingY = 576 height = 640 font.ascent=12
scalable[4] horibearingY = 576 height = 576 font.ascent=12
scalable[-] horibearingY = 256 height = 64 font.ascent=12
scalable[7] horibearingY = 576 height = 576 font.ascent=12
scalable[j] horibearingY = 576 height = 768 font.ascent=12
scalable[a] horibearingY = 384 height = 384 font.ascent=12
scalable[p] horibearingY = 384 height = 576 font.ascent=12
scalable[q] horibearingY = 384 height = 576 font.ascent=12
scalable[r] horibearingY = 384 height = 448 font.ascent=12
scalable[w] horibearingY = 448 height = 512 font.ascent=12
glyph[S] miny=0  maxy=9 yoffset=3 
glyph[u] miny=0  maxy=7 yoffset=5 
glyph[n] miny=-1  maxy=6 yoffset=6 
glyph[:] miny=0  maxy=7 yoffset=5 
glyph[ ] miny=0  maxy=0 yoffset=12 
glyph[2] miny=0  maxy=9 yoffset=3 
glyph[0] miny=0  maxy=9 yoffset=3 
glyph[1] miny=-1  maxy=9 yoffset=3 
glyph[4] miny=0  maxy=9 yoffset=3 
glyph[-] miny=3  maxy=4 yoffset=8 
glyph[0] miny=0  maxy=9 yoffset=3 
glyph[7] miny=0  maxy=9 yoffset=3 
glyph[-] miny=3  maxy=4 yoffset=8 
glyph[0] miny=0  maxy=9 yoffset=3 
glyph[2] miny=0  maxy=9 yoffset=3

Hi again Sylvain,

Thanks for the links. :)

> I think SDL handles correctly the y offset. The glitch is already present in the freetype value (due to freetype rendering/scaling/filtering).

Just to understand correctly what is happening, I guess you mean a different horibearingY from the height? Or even something else?
> scalable[n] horibearingY = 384 height = 448 font.ascent=12
> glyph[n] miny=-1  maxy=6 yoffset=6 

I'll look into adding a light font hinting, btw. :)

Regards, :)

The issue that was initially reported was "letters 'u' and 'n' are rendered misplaced".

With this log:
 
 scalable[u] horibearingY = 448 height = 448 font.ascent=12
 scalable[n] horibearingY = 384 height = 448 font.ascent=12

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

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!

Hi,

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.

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

I think I did nothing for that, except changing the font.
Maybe let's just close the bug :)

Okay, sounds good. :)