Comment 35 for bug 1001033

I'll pass for 1). I don't think Werner has subscribed here - I posted a link back to here when I posted the Savannah bug and I copied his response here, but I don't think he's following this bug. Did you CC him?

With regard to 2), I think Sam's test based on rendered string dimensions did show variations in other monospaced fonts. I think I agree with you above that Sam could not be confident of consistent results with that method, such as any time xMin < 0 or xMax > advance. If you look at the reported glyph metrics for the characters that mismatch in that test, in all cases either xMin < 0, xMax > advance or both. However, while investigating Sam's problem, I found that in FreeMono the advance width varies too. Would it be better to split this into a separate bug? I definitely think this contributes to Sam's problem, but I think Sam's test is unable to distinguish between these two different causes.

With regard to 3), see 2).

With regard to 4), the Pygame Font & SysFont constructors are documented[1] as taking an integer number of pixels, they pass it through[2] to SDL's TTF_OpenFont[3][4], which then uses it to call FreeType's FT_Set_Char_Size[5] like so:

FT_Set_Char_Size( font->face, 0, ptsize * 64, 0, 0 );

I believe that specifies a default 72dpi, so that the pixel size = the point size.

The methods that get widths and heights back out of the font in Pygame are definitely in pixels. font.render(...) returns a bitmap object and get_size() returns its dimensions in pixels.

Hopefully this information reduces the amount of spelunking through Pygame and SDL needed for people investigating this.

[1] - http://www.pygame.org/docs/ref/font.html#pygame.font.Font
[2] - http://hg.pygame.org/pygame/src/e6b5ebf91ac4/src/font.c
[3] - http://www.libsdl.org/projects/SDL_ttf/docs/SDL_ttf.html#SEC14
[4] - http://hg.libsdl.org/SDL_ttf/file/c37a9410f6a7/SDL_ttf.c
[5] - http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size