This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• test case (misplaced_glyph.c, text/x-csrc, 2014-07-03 19:03:01 +0000, 1859 bytes)
• the font (HelveticaNeue-Regular.ttf, application/font-truetype, 2014-07-03 19:03:26 +0000, 49832 bytes)
• screenshot (Screen Shot 2014-07-03 at 2.56.49 .png, image/png, 2014-07-03 19:04:40 +0000, 26702 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2014-07-03 19:03:01 +0000, Sylvain wrote:

Created attachment 1728
test case

Some glyph are misplaced with this font.
here's a test case + picture.

On 2014-07-03 19:03:26 +0000, Sylvain wrote:

Created attachment 1729
the font

On 2014-07-03 19:04:40 +0000, Sylvain wrote:

Created attachment 1730
screenshot

On 2014-07-04 09:47:20 +0000, Sylvain wrote:

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

On 2014-12-19 10:12:05 +0000, Yohann Ferreira wrote:

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,

On 2014-12-19 13:11:32 +0000, Sylvain wrote:

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

On 2014-12-19 14:21:25 +0000, Yohann Ferreira wrote:

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, :)

On 2014-12-19 14:45:52 +0000, Sylvain wrote:

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

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:

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.

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