Hello, I use TTF_SizeText/UTF8 a lot to “predict” surface sizes without rendering. However, while the sizing function gives me the correct width, the height is always around 10% smaller (I tested it with m5x7 with various font sizes, the average multiplier was 1.104025) than that of the rendered texture. Does anyone have any idea why this happens? Is it intentional? Thank you.
The size that you are providing to SDL_OpenFont(fontPtr, size) is rarely a measure of pixels described here.
But if that’s not the issue:
I’m using roboto.ttf found at google fonts as my default font.
I don’t get a difference between the returned surface height and the reports from TTF_FontSize on my end.
I do think there’s some font feature that would allow for text that expects to merge into other lines, so it depends on the font and what languages are being supported.’
What font are you using, and how are you setting your texture’s height?
Are you grabbing the height from the temp surface as from this clip:
SDL_Rect pos = {0,0,0,0};
SDL_Texture * image = NULL;
SDL_Surface * temp = TTF_RenderUTF8_Blended(baseFont, text.c_str(), color);
int h, w;
TTF_SizeText(baseFont, "My Text", &w, &h);
SDL_Log("AcutualHeight = %d, ReportedHeight = %d", temp->h, h);
image = SDL_CreateTextureFromSurface(renderer, temp);
pos.w = temp->w;
pos.h = temp->h;
SDL_FreeSurface(temp);
You might also try out TTF_FontLineSkip to get the expected line spacing.
When comparing, I was opening the font in different sizes, then comparing the dimensions of the surface with SizeText’s output.
The font I am using is the open-source m5x7 pixel font. I tried Roboto, and indeed, the sizes now match, so it seems to be on a per-font basis. I’ll play around with the line skip to compensate for this.
Thanks!
1 Like
itch open-source m5x7 ← is this the font in question? I don’t know it personally, but on that page it is recommended to use multiples of 16 for font sizes which I don’t quite understand that necessity in a ttf font. It probably has to do with avoiding anti-aliasing to have a retro look.
However;
It also seems to answer your original question, it has a +7 ascender and a -2 descender. Those probably scale along with the font size. Using that terminology, I got to the wikipedia for ascenders and descenders. It does seem to me that TTF_SizeText follows the same rules, reporting the font’s definition of height rather than the actual rendered height. I am curious for your specific font, if that TTF_FontLineSkip function I mentioned before might be reporting the correct height for that font…
Whoa, that’s a rabbit hole I didn’t expect to fall into tonight… Oh well. 
You got the correct font. Thank you very much for the research, it’s much appreciated. I haven’t had the chance to test the skip yet, and will do so in the next few hours.
Either way, I’ll try rewriting my TTF rendering function to trim any potential unused space. This stuff messes with some positioning functions too, which isn’t pleasant.
A while back I wanted to create a font-editor so I could make my own fonts.
I spent a couple of hours reading the TrueTypeFont file specifications and instruction sets 
, and decided that there were already plenty of open source fonts available…
Ain’t that the truth! Sometimes it’s just better to leave well enough alone…
Anyway - I tried what you suggested. Indeed, the height and skip corresponded to what SizeText and the rendered surface reported, respectively. I’ll either issue a warning to the user, or provide an alternate function that explicitly clips the surface to its minimum possible size.
In any case, I didn’t expect fonts to be so complicated, but I suppose it makes sense, they’re one of the most important things in everyday life after all. 