GetTextExtentPoint32 返回值有点偏离，字形被截断答案

【问题标题】：GetTextExtentPoint32 returning values a little off, glyphs truncatedGetTextExtentPoint32 返回值有点偏离，字形被截断
【发布时间】：2012-05-28 12:20:18
【问题描述】：

对于所有字符串，GDI 函数 GetTextExtentPoint32 返回的宽度似乎总是比 ExtTextOut 显示的宽度小一点：

在右侧红色箭头上方，“buggy”显示为带有ExtTextOut 的块：没问题。

在左红色箭头上方，“buggy”与ExtTextOut 一起显示，然后在width 像素之后显示“,”，其中width = GetTextExtentPoint32("buggy")。 width 好像有点太小了。

使用更大的字体大小和深色背景：

同样，“00”和“()”在不同的ExtTextOut调用中显示，它们之间有GetTextExtentPoint32("00")像素。

任何帮助表示赞赏。

【问题讨论】：

是否有可能在您选择的字体中，字母“y”的 C 宽度为负数？
@Raymond Chen 我没有尝试调用 GetCharABCWidths 所以我不确定，但我不这么认为，字体（Calibri）是标准的，单词的最后一个字符总是被截断，不管它是什么. GetTextExtentPoint32 不应该自己解决所有这些问题吗？它应该“计算指定文本字符串的宽度和高度”msdn.microsoft.com/en-us/library/dd144938(v=vs.85) ...
我不知道，我只是猜测。
不久前我已经放弃了依靠精确的文本宽度测量。字距调整、字形悬垂和 TrueType 提示使其方式太难了。 GetTextExtent 可以追溯到更简单的时代。
如果您想要精确，请不要使用 DrawText。多年前我们发现一些驱动程序没有正确实现 DrawText，返回的 DT_CALCRECT 值与实际打印不同。惊喜！

标签： winapi fonts gdi typography

【解决方案1】：

我在处理等宽 True Type 字体（Lucida Console）和 OPAQUE 背景模式时发现了同样的问题。问题似乎是使用正确的 x 坐标调用 ExtTextOut，但该函数从 x-1 开始绘制背景，这是我没想到的。较大的字体大小可能会产生较大的负偏移。字形最终被正确定位，但除非选择透明背景模式，否则“过度绘制”是一个问题。以前，我认为我不需要指定 rc 参数，因为我根本不需要剪辑，因为所有字符运行都是不重叠的，但最终我不得不提供一个明显多余的 RECT 和 ETO_CLIPPING 标志，只是以防止这种水平负重绘。

【讨论】：