嘿，你碰到的这个情况其实是FreeType里很常见的正常表现，和字体设计、FreeType的缩放逻辑都有关系，我给你拆解明白：

1. FT_Set_Pixel_Sizes到底在干啥？ #

你调用FT_Set_Pixel_Sizes( ftFace, 0, 28 )的时候，是告诉FreeType把字体的em框（font em square）缩放到28像素高，但这可不是直接强制字符的总渲染高度（从ascender到descender的距离）必须等于28px。

2. Ascender和Descender是字体本身决定的 #

Ascender（字符最高点到基线的距离）和descender（字符最低点到基线的距离，通常是负数）是字体设计师在制作字体时就定义好的数值。FreeType只是按照你设置的像素尺寸，把这些设计值缩放后返回给你：

• 你输出的24和-5，就是缩放后的结果，加起来29的高度，是这个字体在28px设置下，字符可能占据的最大垂直空间。
• 很多字体的设计都会让这个总高度略大于em框高度——毕竟要给那些带重音的字母、手写体的延伸笔画留空间，不然渲染的时候就会被裁掉，影响美观。

3. 为啥总和不等于设置的28px？ #

FreeType的像素尺寸是基于字体的em单位来缩放的，而em框是字体设计的基准坐标系，和字符实际的排版边界（ascender/descender）并不是严格相等的关系：

• 有些字体设计比较“规整”，ascender+|descender|刚好等于em框高度，这时候总和就会和你设置的像素尺寸一致；
• 但更多字体为了排版好看，会让这个总高度稍微超出em框，这就出现了你看到的29>28的情况。

小建议 #

要是你想验证这个说法，可以换几个不同的字体试试：

• 像Courier New这类等宽字体，可能更接近你设置的28px；
• 而那些带复杂字形的艺术字体、手写体，差异会更明显。

如果需要严格控制字符的渲染高度，可以试试这两种方法：

• 手动算缩放比例：用你想要的目标高度（28）除以实际的ascender+|descender|（29），得到缩放系数，再调整FT_Set_Pixel_Sizes的参数；
• 改用FT_Set_Char_Size，它是基于点大小和DPI来设置的，能更精细控制，但本质上还是绕不开字体本身的设计限制。

内容的提问来源于stack exchange，提问作者newbeeep