FreeType是解析TTF文件头信息最可靠标准，因其跨平台、完整支持TrueType表结构（如name、OS/2、head），且经广泛验证；手动解析易因表偏移、校验、字节序等问题出错。
用 FreeType 解析 TTF 文件头信息最可靠
标准 C++ 没有内置字体解析能力，必须依赖第三方库；FreeType 是唯一被广泛验证、跨平台、支持完整 TrueType 表结构（如 name、OS/2、head）的成熟选择。别试图手动解析 TTF 二进制——它的表偏移、校验、字节序、可选表嵌套太容易出错。
实操建议：
- Linux/macOS：用包管理器安装，例如
apt install libfreetype6-dev或brew install freetype - Windows：推荐用 vcpkg：
vcpkg install freetype:x64-windows，避免 DLL 路径和 ABI 不匹配问题 - 链接时确保加
-lfreetype（GCC/Clang）或正确配置 VS 的附加依赖项
读取字体家族名和样式名要用 FT_Get_Sfnt_Name
TTF 的“字体名”不只存在一个地方：name 表里有多个语言/平台组合的字符串，比如英文 Windows 名、中文 macOS 名。直接读 face->family_name 或 face->style_name 只返回 ASCII 版本，且在某些字体中为空或不准确。
正确做法是遍历 name 表，按优先级查找：
立即学习“C++免费学习笔记（深入）”；
- 先查平台 ID = 3（Microsoft）、编码 ID = 1（Unicode BMP），名称 ID = 1（Family Name）
- 再查名称 ID = 2（Subfamily Name）
- 用
FT_Get_Sfnt_Name获取原始字节，再根据string[0]判断编码（UTF-16BE 还是 UTF-16LE），手动转成std::u16string或 UTF-8
示例关键片段：
FT_SfntName name;
if (FT_Get_Sfnt_Name(face, 0, &name) == 0 && name.name_id == 1) {
// 注意：name.string 是 uint8_t*，长度为 name.string_len
// 若 name.platform_id == 3 && name.encoding_id == 1，需按 UTF-16 解码
}
获取字体度量信息要区分 face->units_per_EM 和实际 glyph bbox
face->units_per_EM 是设计网格单位数（常见为 1000 或 2048），不是像素值；而 face->ascender/face->descender 是以该单位表示的逻辑高度，不是屏幕坐标。直接当成像素使用会导致字号缩放错误。
真正用于渲染布局的是转换后的像素值：
- 调用
FT_Set_Char_Size(face, 0, pixel_height, 0, 0)后，face->size->metrics.height才是行高像素值 - 单个字形的边界框需先加载（
FT_Load_Char），再读face->glyph->metrics.width（水平布局用）或face->glyph->metrics.horiAdvance - 注意：
FT_Load_Char默认只加载 glyph outline，若需 bitmap 需额外指定FT_LOAD_RENDER
Windows 上读取本地 TTF 文件路径含中文会失败
FreeType 的 FT_New_Face 接口只接受 const char* 路径，在 Windows 下传入 GBK 或 UTF-8 编码的中文路径大概率返回 FT_Err_Unknown_File_Format（实际是 fopen 失败，但错误码被掩盖）。
绕过方法只有两个：
- Linux/macOS 无此问题，UTF-8 路径可直接用
- Windows 必须走宽字符路径：用
FT_New_Face_From_Stream+ 自定义FT_Stream，底层用_wfopen打开std::wstring路径，再把文件内容喂给 FreeType - 别依赖
FT_New_Face的自动路径处理——它在 Windows 上根本不支持 Unicode
这个坑非常隐蔽：错误码不提示路径问题，日志里也看不到 fopen 失败细节，只能靠调试确认 stream->descriptor.pointer 是否为空。
