简介：本文系统解析GDI字体度量结构TEXTMETRIC的20个成员含义、逻辑单位与映射模式的关系，以及tmPitchAndFamily的位编码规则。读者将掌握通过GetTextMetrics获取字体度量、计算字符宽度与行高、判定字体类型的方法，并了解其与高级字体度量结构的关联，从而在文本布局与渲染中实现精确控制。

TEXTMETRIC 字体度量结构详解：从字段语义到精确文本布局

在Windows图形设备接口（GDI）的字体体系中，TEXTMETRIC 是一个基础且关键的数据结构。它承载了当前设备上下文中被选入字体的物理度量信息，是开发者进行字符宽度计算、行高规划、字体类型判定的直接数据来源。无论是使用原生 SDK 还是 MFC 框架，只要涉及文本排版与渲染，几乎都绕不开这个仅有 20 个成员的结构体。

本文从结构定义出发，逐层剖析各字段的语义、单位约定与位编码规则，并结合典型使用场景给出可落地的实践方法。

一、结构定位与单位约定

TEXTMETRIC 定义于 wingdi.h 头文件，用于描述物理字体的基本度量信息。理解它的第一个前提是：所有尺寸均以逻辑单元表示，其实际物理含义取决于目标设备上下文当前的映射模式。在 MM_TEXT 映射模式下，逻辑单位即像素；而在 MM_LOMETRIC、MM_HIMETRIC 等映射模式下，同一数值对应的物理尺寸截然不同。因此，在跨设备、跨分辨率场景中直接硬编码度量数值是不安全的，应始终基于当前 DC 的映射模式进行换算。

结构体共包含 20 个成员，可归纳为四组：纵向度量、横向度量、字符集信息与样式标志、间距与家族编码。

二、纵向度量：行高与基线的分解

纵向度量的核心是三个相互约束的字段：

tmHeight：字符单元的总高度，等于 tmAscent 与 tmDescent 之和。
tmAscent：基线以上的上升部分，即从基线到字符单元顶部的距离。
tmDescent：基线以下的下降部分，覆盖字母下伸部（如 g、p 的尾部）。

在此之上还有两个与行间距相关的字段：

tmInternalLeading：位于 tmHeight 界限内部的额外空间，通常用于容纳重音符号等超出常规字高的部分。它包含在 tmHeight 之内，因此计算字符单元高度时不应重复累加。
tmExternalLeading：推荐的行与行之间的额外间距，位于 tmHeight 之外。它由字体设计者建议，但并不强制，应用程序可自行决定是否采用。

由此可得两个常用的派生量：

// 字符单元高度（不含外部行距）
int cyChar = tm.tmHeight + tm.tmExternalLeading;
// 若仅需字形本体高度
int cyGlyph = tm.tmHeight;

需要强调的是，tmHeight 已包含 tmInternalLeading，因此行高计算中不应再加一次，这是实践中常见的错误来源。

三、横向度量：平均宽度与最大宽度

横向度量决定文本布局的横向推进量：

tmAveCharWidth：字符平均宽度，通常按小写字母的加权平均估算。它适合用于粗略估算一段文本的显示宽度，但不适用于精确排版。
tmMaxCharWidth：字体中最宽字符的宽度，可用于预留最坏情况下的空间。
tmOverhang：合成字体（如斜体或粗体的模拟合成）在字符串两端可能产生的额外宽度。当多个字符连续排布时，此值通常已被吸收；但在计算单个字符串的精确外接矩形时需要考虑。

对于固定间距字体，tmAveCharWidth 与 tmMaxCharWidth 通常相等；对于可变间距字体，二者差异明显。开发者不应假设二者关系，而应通过实际测量验证。

四、设计纵横比与字符集信息

tmDigitizedAspectX / tmDigitizedAspectY：字体被数字化时所针对的设备的纵横比。当目标设备的纵横比与之不一致时，GDI 会进行相应调整。这两个字段在需要精确控制字体拉伸行为的场景中具有参考价值。
tmFirstChar / tmLastChar：字体所定义的第一个与最后一个字符，界定了字体的字符覆盖范围。
tmDefaultChar：当请求的字符不在字体覆盖范围内时使用的替代字符。
tmBreakChar：用于文本对齐与断词处理的字符，通常为空格。
tmCharSet：字符集标识，决定字符编码到字形的映射关系。

五、样式标志：斜体、下划线与删除线

三个布尔型字段以字节形式表达样式信息：

tmItalic：非零表示斜体。
tmUnderlined：非零表示带下划线。
tmStruckOut：非零表示带删除线。

这些标志反映的是字体本身的属性，而非通过绘图状态临时施加的效果。在需要判断”当前字体是否原生支持斜体”时，应读取此字段，而不是仅依据创建字体时传入的请求参数——因为 GDI 可能通过合成方式模拟不存在的样式。

六、tmPitchAndFamily：位编码的双重语义

tmPitchAndFamily 是整个结构中最需要谨慎处理的字段，它用同一个字节承载了两类完全不同的信息：低 4 位描述间距与技术属性，高 4 位描述字体系列。

低 4 位的技术标志：

常量	含义
TMPF_FIXED_PITCH	注意其语义与名称相反：置位表示可变间距，清零才表示固定间距
TMPF_VECTOR	向量字体
TMPF_TRUETYPE	TrueType 字体
TMPF_DEVICE	设备字体

其中 TMPF_FIXED_PITCH 的反直觉语义是历史遗留问题，必须通过位测试而非字面理解来判断。正确的判定方式为：

BOOL bFixedPitch = !(tm.tmPitchAndFamily & TMPF_FIXED_PITCH);
BOOL bTrueType  = (tm.tmPitchAndFamily & TMPF_TRUETYPE) != 0;

高 4 位的家族信息： 通过 0xF0 掩码提取，取值对应 FF_DONTCARE、FF_ROMAN、FF_SWISS、FF_MODERN、FF_SCRIPT、FF_DECORATIVE 等系列常量。应用程序应将其视为”建议性分类”，用于字体选择时的偏好匹配，而不应作为严格保证。

官方文档特别提示：应用程序应仔细测试这些位所编码的品质，不应进行任意假设。不同字体驱动对这些位的填充可能存在差异，尤其在设备字体与合成字体场景下。

七、典型使用流程

在窗口创建阶段获取度量并缓存，是常见且高效的做法。以下示例在 WM_CREATE 中完成初始化：

case WM_CREATE: {
    HDC hdc = GetDC(hwnd);
    TEXTMETRIC tm;
    GetTextMetrics(hdc, &tm);
    // 行高：包含外部行距
    int cyChar = tm.tmHeight + tm.tmExternalLeading;
    // 平均字符宽度
    int cxChar = tm.tmAveCharWidth;
    // 大写字母宽度估算：固定间距字体下按平均宽度与最大宽度推导
    int cxCaps = (tm.tmPitchAndFamily & TMPF_FIXED_PITCH)
                 ? (cxChar * 3) / 2
                 : cxChar;
    ReleaseDC(hwnd, hdc);
    // 将 cyChar、cxChar、cxCaps 缓存到窗口实例数据中
    return 0;
}

此处 cxCaps 的经验式推导源于：大写字母通常比小写字母宽，在可变间距字体中约为平均宽度的 1.5 倍。这一估算适用于快速布局，若需精确值，应使用 GetCharWidth 或 GetTextExtentPoint32 逐字符测量。

八、与高级度量结构的关联

TEXTMETRIC 提供的是基础度量。当需要更丰富的排版信息——如字体的全名、版权信息、各字符的精确宽度数组、下划线与删除线的位置等——可使用 OUTLINETEXTMETRIC 结构。后者在 TrueType 字体下可提供更完整的字形级数据，并通过 GetOutlineTextMetrics 获取。两者的关系是层次化的：TEXTMETRIC 满足常规布局需求，OUTLINETEXTMETRIC 面向需要精细排版控制的场景。在字体管理系统的整体架构中，它们共同构成从基础度量到扩展度量的数据支撑。

九、实践要点小结

单位随映射模式变化，跨设备场景必须做逻辑到物理的换算。
tmHeight 已含 tmInternalLeading，行高计算勿重复叠加。
TMPF_FIXED_PITCH 语义反转，判定固定间距需取反。
位标志只作参考，应实际测试而非假设字体能力。
度量宜缓存，在窗口创建时获取一次，避免每帧重复查询 DC。
精确排版用测量 API，平均宽度仅适合估算，逐字符宽度应通过文本范围计算获得。

掌握 TEXTMETRIC 的字段语义与位编码细节，是构建可靠文本布局逻辑的基础。它既是一个数据容器，也是理解 GDI 字体渲染决策链路的入口。

TEXTMETRIC字体度量结构详解