C++中GetTextExtentPoint32获取文本尺寸与GDI+绘制实际尺寸不匹配

你遇到的GDI测量结果和GDI+实际绘制尺寸不匹配，本质是GDI的GetTextExtentPoint32和GDI+的文本渲染遵循两套独立的度量规则，并非你选错了字体族或者字号。 #

具体偏差来源拆解 #

• 高度偏差的核心成因：行高计算逻辑差异
  GDI的GetTextExtentPoint32返回的size.cy，是完整的文本行占位高度，计算时会强制把字体定义里的外部行间距（External Leading） 算入总高度，这部分空间是预留给多行文本排版的行间隙，根本不属于单个文本块自身的实际占用高度。
  对应你代码里的Segoe UI 26号字体，外部行间距通常在5-7px区间，刚好匹配你观测到的“测量高度62、实际绘制高度55”的差值。而GDI+构造Font对象时传入的26（单位为像素），严格对应字体的em方块高度，度量时完全不会纳入外部行间距的计算，本身就和GDI的行高统计范围不一样。
• 宽度偏差的核心成因：渲染模式与度量规则差异
  你在GDI侧创建字体时指定了CLEARTYPE_QUALITY，此时GDI会按照ClearType渲染的像素网格对齐规则计算每个字符的步进宽度，同时为了避免相邻字符的ClearType渲染糊边，会额外做字距补偿，把每个字符的测量宽度往大了取整。
  而GDI的度量会完整计入每个字符设计上的左右侧留白（Side Bearing）；但你在GDI+绘制时设置的是TextRenderingHintAntiAlias，这个渲染模式会关闭像素网格对齐，采用亚像素浮点坐标计算字符位置，既不做ClearType的边距补偿，也不强制把字符步进吸附到整数像素上，还会裁剪掉无实际字符像素的冗余侧留白。几重因素叠加下来，最终绘制出来的文本自然比GDI测量的结果窄10%~20%，刚好匹配你观测到的“测量宽度228、实际绘制宽度190”的差值。
• 认知误区澄清
  你此前的推导“只要匹配字体族、字号，测量结果就和实际绘制一致”是不成立的。文本尺寸从来不是只由字体属性决定的静态值，它和渲染提示、网格对齐策略、字距补偿规则、行间距统计范围强绑定，脱离实际绘制的渲染逻辑单独做测量，必然会出现偏差。

修正方向 #

• 最稳妥的方案是放弃用GDI的接口测量尺寸，直接复用GDI+的MeasureString方法做测量，测量时必须把Graphics对象的渲染提示设置成和后续DrawString完全一致的TextRenderingHintAntiAlias，这样得到的尺寸才能和实际绘制结果完全匹配。
• 如果你坚持用GDI测量，需要做两处对齐：一是拿到测量结果后扣除字体的外部行间距值，替换掉默认的size.cy；二是把创建字体时的渲染质量参数从CLEARTYPE_QUALITY改成ANTIALIAS_QUALITY，和GDI+的渲染模式对齐，最大限度缩小偏差。
• 顺带修正你现有代码的两个逻辑问题：
  • GDI+的DrawString传入宽字符串时，长度参数必须用wcslen计算，你当前用strlen计算ANSI字符串长度的写法虽然在纯英文场景下数值巧合一致，但遇到宽字符时会直接截断。
  • GDI测量尺寸时使用的DC，必须和实际绘制时的DC保持相同的DPI缩放、位图映射模式，否则会出现额外的尺寸偏差。

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