为什么FONTSIGNATURE不能反映lfCharSet？

Question

我像这样枚举Windows字体：

LOGFONTW lf = {0};
lf.lfCharSet = DEFAULT_CHARSET;
lf.lfFaceName[0] = L'\0';
lf.lfPitchAndFamily = 0;
::EnumFontFamiliesEx(hdc, &lf,
                     reinterpret_cast<FONTENUMPROCW>(FontEnumCallback),
                     reinterpret_cast<LPARAM>(this), 0);

我的回调函数有这样的签名：

int CALLBACK FontEnumerator::FontEnumCallback(const ENUMLOGFONTEX *pelf,
                                              const NEWTEXTMETRICEX *pMetrics,
                                              DWORD font_type,
                                              LPARAM context);

对于TrueType字体，我通常会多次获得每个面孔的名称。例如，对于多个调用，我会将pelf->elfFullName和pelf->elfLogFont.lfFaceName设置为"Arial"。更仔细地查看其他字段，我发现每个调用都针对不同的脚本。例如，在第一次调用时，pelf->elfScript将是"Western"，而pelf->elfLogFont.lfCharSet将是ANSI_CHARSET的数字等价物。在第二个调用中，我得到了"Hebrew"和HEBREW_CHARSET。第三，调用"Arabic"和ARABIC_CHARSET。诸若此类。到现在为止还好。

但是所有版本的Arial的font signature (pMetrics->ntmFontSig)字段都是相同的。事实上，字体签名声称所有这些版本的Arial都支持拉丁语-1、希伯来语、阿拉伯语和其他语言。

我知道我试图绘制的字符串的字符集，所以我尝试基于字体签名实例化适当的字体。因为字体签名总是匹配的，所以我最终总是选择"Western“字体，即使在显示希伯来语或阿拉伯语文本时也是如此。我使用的是低级Uniscribe API，所以我没有得到Windows字体链接的好处，但我的代码似乎可以工作。

lfCharSet实际上有什么意义吗，还是它是一个遗留的工件？我是否应该将lfCharSet设置为DEFAULT_CHARSET，并停止担心每个面部的所有脚本变体？

就我而言，我只关心TrueType和OpenType字体。

Answer 1

我想我找到答案了。被多次枚举的字体是"big" fonts。大字体是包括多个脚本或代码页的字形的单一字体。

FONTSIGNATURE的Unicode部分(fsUsb)表示字体可以处理的所有Unicode子范围。这与字符集无关。如果使用宽字符API，则可以使用字体中包含的所有字形，而不管在创建字体时指定了哪个字符集。

FONTSIGNATURE (fsCsb)的代码页部分表示字体可以处理的代码页。我认为只有当字体不是“大”字体时，这才是重要的。在这种情况下，fsUsb掩码将全为零，并且fsCsb将指定适当的字符集。在这些情况下，确保LOGFONT中的lfCharSet正确是很重要的。

在实例化“大”字体并使用宽字符lfCharSet时，指定哪个API显然无关紧要。