I’m seeing some odd rendering problems with fonts when using SDL_ttf 2
with ParaGUI. You can see this by comparing
http://david.hedbor.org/tmp/ttf1.jpg and
http://david.hedbor.org/tmp/ttf2.jpg.
Someone suggested that TTF_SizeText returned an incorrect value for
height, but I don’t know if that’s true. It seems like there is simply
too much space above the rendered font, which cuts off the buttom. Any
clue? 
– David
** On Apr 24, David Hedbor scribbled:
I’m seeing some odd rendering problems with fonts when using SDL_ttf 2
with ParaGUI. You can see this by comparing
http://david.hedbor.org/tmp/ttf1.jpg and
http://david.hedbor.org/tmp/ttf2.jpg.Someone suggested that TTF_SizeText returned an incorrect value for
height, but I don’t know if that’s true. It seems like there is simply
too much space above the rendered font, which cuts off the buttom. Any
clue?
No, the space above is OK, it’s called ascent and is used to encompass both
the glyphs that stem above the usual character height (capital leters) and
also, or rather primarily, it is used for the accented letters - their
accent is put in the ascent area. The problem is that TTF_SizeText reports
the font size from baseline to the ascent (inclusive) but it leaves out the
descent of the font - i.e. the area where the “stems” of some characters are
printed (y, g, q). What’s more, even when I added the descent, the reported
size was one less than that reported by the 1.x version of TTF_SizeText. It
might seem that FreeType 2 reports the glyph size differently…
marek–
Visit: http://caudium.net - the Caudium WebServer
/* A completely unrelated fortune */
That all men should be brothers is the dream of people who have no
brothers. – Charles Chincholles, “Pensees de tout le monde”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010425/5d71989c/attachment.pgp
Marek Habersack wrote:
** On Apr 24, David Hedbor scribbled:
I’m seeing some odd rendering problems with fonts when using SDL_ttf 2
with ParaGUI. You can see this by comparing
http://david.hedbor.org/tmp/ttf1.jpg and
http://david.hedbor.org/tmp/ttf2.jpg.Someone suggested that TTF_SizeText returned an incorrect value for
height, but I don’t know if that’s true. It seems like there is simply
too much space above the rendered font, which cuts off the buttom. Any
clue?
No, the space above is OK, it’s called ascent and is used to encompass both
the glyphs that stem above the usual character height (capital leters) and
also, or rather primarily, it is used for the accented letters - their
accent is put in the ascent area. The problem is that TTF_SizeText reports
the font size from baseline to the ascent (inclusive) but it leaves out the
descent of the font - i.e. the area where the “stems” of some characters are
printed (y, g, q). What’s more, even when I added the descent, the reported
size was one less than that reported by the 1.x version of TTF_SizeText. It
might seem that FreeType 2 reports the glyph size differently…marek
Actually, as I said, adding “abs(descent) + 1” to the height doesn’t
work. What did work was to change back the height setting in
TTF_SizeUNICODE to that of SDL_ttf 1.x; *h = font->height
After doing that, all rendering is perfect. Bug or feature, anyone?
– david
David Hedbor wrote:
Actually, as I said, adding “abs(descent) + 1” to the height doesn’t
work. What did work was to change back the height setting in
TTF_SizeUNICODE to that of SDL_ttf 1.x; *h = font->heightAfter doing that, all rendering is perfect. Bug or feature, anyone?
To reply to my own message, it seems like the problem is the difference
between the rendered surface and the size of the text on that surface.
From pglabel.cpp with some debug:
int wl = my_srfText->w;
int hl = my_srfText->h;
std::cout << "Actual size: " << wl << "?" << hl << std::endl;
GetTextExtend(my_textLabel.c_str(), wl, hl);
std::cout << "Given size: " << wl << "?" << hl << std::endl;
my_srfText is the rendered text for this label. GetTextExtend returns
the size for the actual text using TTF_SizeText():
Example output is:
Actual size: 98?21
Given size: 98?11
I.e the rendered surface is 21 pixels high while paragui only uses the
height of the actual text rendered. The problem is that the text on the
returned surface isn’t in the upper left corner, but somewhere farther
down (depending on the text). That is why text is truncated.
There are two fixes for this:
Personally, 1 or 2 are the only acceptable solutions to me, since 3
would be backwards incompatible.
Either way, the current behavior is a bug, which, if known, can be
worked around (i.e ParaGUI can ignore the TTF_SizeText height and use
the height of the surface).
– david
Actually, as I said, adding “abs(descent) + 1” to the height doesn’t
work. What did work was to change back the height setting in
TTF_SizeUNICODE to that of SDL_ttf 1.x; *h = font->height
After doing that, all rendering is perfect. Bug or feature, anyone?
It’s a feature, but perhaps it should revert to the original semantics.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Actually, as I said, adding “abs(descent) + 1” to the height doesn’t
work. What did work was to change back the height setting in
TTF_SizeUNICODE to that of SDL_ttf 1.x; *h = font->heightAfter doing that, all rendering is perfect. Bug or feature, anyone?
It’s a feature, but perhaps it should revert to the original semantics.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Did you read the second mail I sent? The problem is that rendered text
returns a surface bigger than the actual size of the rendered text. What
do you think of fix #2, i.e crop the surface down before returning it? I
find it a feature that you get the actual size too, but it’s not useful
today since you can’t use it for anything.
Did you read the second mail I sent? The problem is that rendered text
returns a surface bigger than the actual size of the rendered text. What
do you think of fix #2, i.e crop the surface down before returning it?
I’m not sure. Would it be useful in the general case?
See ya,
-Sam Lantinga, Lead Programmer, Loki Software, Inc.
Sam Lantinga writes:
Did you read the second mail I sent? The problem is that rendered text
returns a surface bigger than the actual size of the rendered text. What
do you think of fix #2, i.e crop the surface down before returning it?I’m not sure. Would it be useful in the general case?
Well, I’m wondering what the use of the function that returns actual
height is, if you can’t actually use that value for anything (i.e
there is no way of getting a surface that represents the size of the
font).–
[ Below is a random fortune, which is unrelated to the above message. ]
The first time, it’s a KLUDGE!
The second, a trick.
Later, it’s a well-established technique!
– Mike Broido, Intermetrics