This thread is an attempt to fix a certain bug in the TTF addon in A5. This is taken outside of the usual mailing list discussion so that people who don't subscribe to it can offer some insight.

Here's how things work right now:

The user calls al_ttf_load_font with a specific size passed to it.

This size is then given to FT_Set_Pixel_Sizes to scale the glyphs to the target size. The passed size parameter is stored, and is returned when al_font_text_height is called.

However, this does not result in the correct behaviour. For example, drawing a font that was loaded with size 18, and then drawing a rectangle that is 18 pixels high results in this sort of output on my machine:

The font is clearly rendered too small, or the font height is too big. If I compare the output of the equivalent font of the same size in say, OpenOffice, the former conclusion seemingly is right: the glyphs are smaller than they should be.

Now, there is another function, FT_Set_Char_Size, which can also scale glyphs. If I use this function as follows: FT_Set_Char_Size(face, size * 64, 0, 96, 0), where I set the DPI to be 96, the bug goes away and the glyphs are rendered identically in Allegro and in OpenOffice. The documentation says that FT_Set_Pixel_Sizes assumes the DPI of 72, which naturally leads to smaller looking glyphs.

Now, so here is the question. Will assuming 96 DPI always result in this correct behaviour? The internet suggested that on Mac's the 72 DPI is used instead.

I had another way to solve this, going from the other direction. Instead of making the glyphs bigger, I would measure the actual pixel height of the font, by measuing the ascent of some capital character, like 'M', and using that as the height of the font as reported by al_font_text_height.

This last solution does not seem satisfactory to me, however.

In the end, the solution of this bug should exhibit these two properties: al_ttf_load_font should produce the same pixel height for fonts loaded on different computers; and, al_font_text_height should return a value that approximately represents the actual height of the font.

Hmm, but will FT_Set_Pixel_Sizes result in the same bitmap sizes on different computers when given identical inputs?

If so, is there a way to determine the size of the em square in pixels given that fixed DPI?

FT_Set_Pixel_Sizes sets the size of the em in pixels, so should produce identical results on all computers.

Just in case anyone comes along who wants to disagree, I made a quick graphic of some random characters in the LinoType/Apple version of Helvetica:

http://www.allegro.cc/files/attachment/596904

Check out how some of the non-Latin characters are substantially taller than the capital M.

Also, I've realised that what I said in my last post is horridly worded so as to be misleading. The size of an em is directly related to the font size in points. The size of glyphs relative to the em is arbitrary and related to the particular font you are using. For example, I'm aware that in the standard Microsoft Windows set, Arial is visibly different from Times New Roman.

EDIT:

Times New Roman versus Arial Ms at the same point size — Times New Roman is wider but shorter, but both fonts have the same sized em.

http://www.allegro.cc/files/attachment/596905

It's the same as the nominal size of the font. So if you display text in a 12 point font then you are telling it to size the em so that it is 12/72ths of an inch.

Yeah, I was just thinking the same myself. It looks like the best course of action. Both values are useful to have, but are clearly not very related to each other as Thomas Harte pointed out. I like the naming scheme too.

EDIT: Reflecting your edit, Elias, I think the current font height function should stay, as its value reflects the 'single spacing' spacing for multi-line texts. The bounding box trick does make more sense, but it shouldn't be the only function there is.

EDIT2: Oh, I misread what you said. Nvm. I like the idea.

And that's why A5 doesn't do it that way.

We probably should (that also makes get_text_height() to match get_text_width()), but what does al_get_text_height() return? Does it include the ascender and descender? Normally if you print text, you want the base of the characters to align.

In that case have it in addition, since all three have their use. Yes, you can get the other two from this, but that's not pretty. It also doesn't solve the problem of getting text to align properly.

So, what I think we need:

• A way to get the height and width of a string so that it fits within a bounding box

• A way to place strings in such a way that the bottom of the characters (not counting descenders) aligns.

• A way to do that such that the text fits within a given bounding box.

• Maybe functions to get the ascender and descender for a given font?

• And yes, it should give the same result on all platforms. I guess it's ok for Allegro to internally use a resolution of 72 DPI (or something else) as long as that's documented.

Probably. The discussion is just about the basic "this is the size of an em, draw this text on this baseline": you (possibly) probably want to know the size of the ascender and descender, and reliably set the size of the em such that you get predictable results on different platforms.
On a side note, does Allegro [4.9/5] currently draw text on the baseline? I can think of a situation where it'd be useful to draw the baseline on y+"font_height", where "font_height" is some typical size of the text, in this way you can draw text to (0,0) and have it show up in the upper left hand corner of the screen, similar to how A4 works. Either way, it's not clearly indicated in the documentation at the moment, if I recall correctly.

So is FreeType used on every platform?

Since FreeType supports other types of fonts why not just call it the FreeType add on instead? This way you could include direct access to FreeType structures and functions...

Right now, text is drawn at y + bitmap_top, where y is what the user passes in and bitmap_top comes from Freetype:

I think we indeed should have all those. Now whether it's a good idea to tell users to simply directly access FT_Face and FT_Glyph I'm not sure - it certainly would be a lot easier for end-users if Allegro itself could provide the info. And not sure in cases where you need more than the above you really should bother to even use the TTF/Freetype addon instead of using Freetype it directly. There's also still the bitmap-font addon - so only those ALLEGRO_FONT objects loaded by this addon are handled by Freetype.

No, it doesn't.

No.*

*) Actually, that will still work (at the moment and if you include the header that exposes the struct elements), but it shouldn't be used.