SDL_ttf pixel wrapping bug?

There’s a bug in the version of SDL_ttf and/or FreeType2 that I’m
running (at least here at work).

What happens is, when the first character in a rendered string
has some pixels at the far left, they end up appearing on the far
right of the surface!

See this screenshot:

http://www.sonic.net/~nbs/sdlttfbug.gif

As you can see in the left part of the picture,
the leftmost pixels of the horizontal line in the "t"
ends up on the right.

On the right, the leftmost part of the tail of the “j” ends up
at the lower right. (So “j” comes out more like "i,"
and “jello” comes out more like “iello,”.)

I’m using SDL_ttf-2.0.so.0.0.5 and /usr/lib/libfreetype.so.6.3.0

Also, another issue I’ve noticed is where the letter “g” can end rendered
with the rightmost line missing. It ends up looking more like:

( instead of: (|
_ _|

See the screenshot here:

http://www.sonic.net/~nbs/sdlttfgbug.gif

(It doesn’t matter where in the string it’s rendered.)

This is using a 14pt version of “FreeSans.ttf”, which is available here:

http://www.freesoftware.fsf.org/freefont/

I need to double-check that my box at home has these issues, too.
It could be I’m using older versions of something (though both boxes
are Debian/Woody, so I don’t see how).

-bill!

Yeah, I’ve been having this same problem and I posted
this same question about a month and a half ago.
Unfortunately, I haven’t seen any solutions and I
haven’t tracked down the source of the problem yet.

I’ve produced this problem with both SDL_ttf 1.x and
2.x, so I’m skeptical it’s a Freetype problem (because
1.x was Freetype 1, and 2.x is Freetype 2).

I get the problem with the bundled “showfont” and
"glfont" programs. I often use times.ttf and arial.ttf
that comes with Windows.

Most of my programs are OpenGL based so my SDL 2D
experience is limited to the “showfont” program.
However, in 3D (and it still might be true for 2D) is
that the magnitude of the problem seems to vary
somewhat based on different hardware. The problem
seems less pronounced on Nvidia based video cards on
PCs, and have noticed it more on ATI and Matrox,
espeically in Linux. The problem is really pronounced
on my Mac running OSX.2 with an ATI Rage128.

If anybody has a solution, please post it as I’m still
dying to know.

Thanks__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Yeah, I’ve been having this same problem and I posted
this same question about a month and a half ago.
Unfortunately, I haven’t seen any solutions and I
haven’t tracked down the source of the problem yet.

I just verified the issue occurs on my Linux box at home.

The missing vertical line in the ‘g’ is less obvious, but the line is
unnaturally thin (compared to all other lines in all other chars. of the
same font & size).

The ‘wrap’ problem (e.g., with the letter “j”) still occurs as well.

> If anybody has a solution, please post it as I'm still > dying to know.

Hear hear!

-bill!On Wed, Sep 25, 2002 at 10:59:26PM -0700, Eric Wing wrote:

If anybody has a solution, please post it as I’m still
dying to know.

Here is a solution. The problem is that the left bearing of the italic 'j’
is negative, meaning that it should be placed before the end of the previous
character. The code in SDL_ttf.c recognizes this when calculating the size
of the temp bitmap where it renders the font, but it forgets it when it
actually renders the text.
The last six lines of the snippet below should be pasted at three locations
(all three locations can be found by searching for /* Load and render each
character */).
Of course this is a dirty hack. Besides it is not completely correct because
the entire text will now be offset a few pixels to the right (the same
number of pixels that you saw on the right side of the text).

/* Load and render each character */ xstart = 0; for( ch = text; *ch; ++ch ) { FT_Bitmap* current;

error = Find_Glyph(font, *ch, CACHED_METRICS|CACHED_PIXMAP);
if( error ) {
SDL_FreeSurface( textbuf );
return NULL;
}
glyph = font->current;

if (ch == text) { // first char
if (glyph->minx < 0) { // first character has negative bearing
xstart -= glyph->minx; // fixup xstart
}
}

Huib-Jan

Here is a solution. The problem is that the left
bearing of the italic 'j’is negative, meaning that
it should be placed before the end of the
previous character. The code in SDL_ttf.c recognizes
this when calculating the size of the temp bitmap
where it renders the font, but it forgets it when it
actually renders the text.

Thank you for for posting your insights. I’ve noticed
this problem for normal fonts as well, not just
italics. Do you believe it is the same problem for
both?

Of course this is a dirty hack. Besides it is not
completely correct because the entire text will now
be offset a few pixels to the right (the same
number of pixels that you saw on the right side of
the text).

Does this mean that the disappearing vertical line on
’g’ will become worse?

Thanks__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[to the fellow who posted a patch]:

Thank you for for posting your insights. I’ve noticed
this problem for normal fonts as well, not just
italics. Do you believe it is the same problem for
both?

I’ve also tested with “AUGIE___.ttf” font
(from emerald city fontwerks: www.speakeasy.org/~ecf )

It is not italic, but the letter ‘t’ (lowercase) has the same
’wrapping’ issue.

> Does this mean that the disappearing vertical line on > 'g' will become worse?

Note that the ‘g’ issue happens no matter where it is in
the string.

If it does get worse, then, I’m guessing it will only get worse
when it’s on the far right. (The wrapping issue happens at the
’string’ level, not the character level. Again, see my bug screenshot:
http://www.sonic.net/~nbs/sdlttfbug.gif )

As to what the problem is with the ‘g’, I’m not sure it’s related.
(e.g., the far-right vertical part that’s “disappearing” doesn’t
appear on the far left. See: http://www.sonic.net/~nbs/sdlttfgbug.gif )

-bill!On Thu, Sep 26, 2002 at 09:00:49AM -0700, Eric Wing wrote

Thank you for for posting your insights. I’ve noticed
this problem for normal fonts as well, not just
italics. Do you believe it is the same problem for
both?

Yes, the problem is not related to whether a font is italic. What matters is
the left bearing of the first character. If it is negative the problem will
appear.

Of course this is a dirty hack. Besides it is not
completely correct because the entire text will now
be offset a few pixels to the right (the same
number of pixels that you saw on the right side of
the text).

Does this mean that the disappearing vertical line on
’g’ will become worse?

No, the problem with the ‘g’ is probably a problem with the font itself.
Creating good hints for a font is very difficult.
It is very unlikely that this would be a bug in SDL_ttf.c.

Huib-Jan