检查是否显示Unicode字符或豆腐

Question

我的问题与this one 类似，但有点进步。

在我的 Win32 程序中，我在 BMP 上方有一些带有 Unicode 字符的菜单按钮，例如 U+1F5A4 ???? （UTF-16 代理对 0xD83D 0xDDA4）。
在 Windows 10 中，系统字体 Segoe UI 没有此字形：它会自动替换为字体 Segoe UI Symbol 中的字形并正确显示在按钮中，谢谢到一个称为字体链接（或字体回退，我仍然不清楚）的过程。
但在 Windows 7 中，字体链接带来的字体也没有此字形，并且代理对显示为两个空框▯▯。在带有 Tahoma 字体的 Windows XP 中也是如此。

我想避免这些替换框，方法是在分配给按钮之前或之后解析文本，并用一些常见的 ASCII 字符替换丢失的字形。

我尝试了GetGlyphOutline、ScriptGetCMap、GetFontUnicodeRanges 和 GetGlyphIndices，但它们不支持代理对。
我还尝试了支持代理对的GetCharacterPlacement 和 Uniscribe ScriptItemize+ScriptShape，但所有这些函数只搜索 HDC 的基本字体（Segoe UI），他们不搜索最终后备字体（Segoe UI Symbol），它提供了 ????字形。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink 这是我看过的地方，但我真的认为它不在那里，系统会获取要链接的字体。

问题是：我如何知道系统字体链接是否生成了正确的字形或豆腐框？

---

编辑

我找到了一种复制 trom this code 并添加最后一个 GetCharacterPlacement 的解决方案。

#include <usp10.h>

wchar_t *checkGlyphExist( HWND hwnd, wchar_t *sUnicode, wchar_t *sLimited ) {

    // Create metafile
    HDC hdc = GetDC( hwnd );
    HDC metaFileDC = CreateEnhMetaFile( hdc, NULL, NULL, NULL );

    // Select menu font
    NONCLIENTMETRICSW ncm;
    ncm.cbSize = sizeof(ncm);
    SystemParametersInfoW( SPI_GETNONCLIENTMETRICS, ncm.cbSize, &ncm, 0 );
    HFONT hFont = CreateFontIndirectW( &(ncm.lfMenuFont) );
    SelectObject( metaFileDC, hFont );
    wprintf( L"%s\n", ncm.lfMenuFont.lfFaceName );  // 'Segoe UI' in Win 10 and 7 (ok)
                                                    // 'Tahoma' in Win XP (ok)

    // Use the meta file to intercept the fallback font chosen by Uniscribe
    SCRIPT_STRING_ANALYSIS ssa;
    ScriptStringAnalyse( metaFileDC, sUnicode, wcslen(sUnicode), 0, -1,
                      SSA_METAFILE | SSA_FALLBACK | SSA_GLYPHS | SSA_LINK,  
                      0, NULL, NULL, NULL, NULL, NULL, &ssa );
    ScriptStringFree( &ssa );
    HENHMETAFILE metaFile = CloseEnhMetaFile(metaFileDC);
    LOGFONTW logFont = {0};
    EnumEnhMetaFile( 0, metaFile, metaFileEnumProc, &logFont, NULL );
    DeleteEnhMetaFile( metaFile );
    wprintf( L"%s\n", logFont.lfFaceName );
        // 'Segoe UI Symbol' in Win 10 (ok)
        // 'Microsoft Sans Serif' in Win 7 (wrong, should be 'Segoe UI Symbol')
        // 'Tahoma' in Win XP for characters above 0xFFFF (wrong, should be 'Microsoft Sans Serif', I guess)
    
    // Get glyph indices for the 'sUnicode' string
    hFont = CreateFontIndirectW( &logFont );
    SelectObject( hdc, hFont );
    GCP_RESULTSW infoStr = {0};
    infoStr.lStructSize = sizeof(GCP_RESULTSW);
    wchar_t tempStr[wcslen(sUnicode)];  
    wcscpy( tempStr, sUnicode );
    infoStr.lpGlyphs = tempStr;
    infoStr.nGlyphs = wcslen(tempStr);
    GetCharacterPlacementW( hdc, tempStr, wcslen(tempStr), 0, &infoStr, GCP_GLYPHSHAPE );
    ReleaseDC( hwnd, hdc );

    // Return one string
    if( infoStr.lpGlyphs[0] == 3 || // for Windows 7 and 10
        infoStr.lpGlyphs[0] == 0 )  // for Windows XP
        return sLimited;
    else
        return sUnicode;
}

// Callback function to intercept font creation
int CALLBACK metaFileEnumProc( HDC hdc, HANDLETABLE *table, const ENHMETARECORD *record,
                            int tableEntries, LPARAM logFont ) {
    if( record->iType == EMR_EXTCREATEFONTINDIRECTW ) {
        const EMREXTCREATEFONTINDIRECTW* fontRecord = (const EMREXTCREATEFONTINDIRECTW *)record;
        *(LOGFONTW *)logFont = fontRecord->elfw.elfLogFont;
    }
    return 1;
}

你可以用checkGlyphExist( hWnd, L"????", L"<3" );调用它

我在 Windows 10 和两个虚拟机上进行了测试：Windows 7 Professional、Windows XP SP2。
它工作得很好，但是当基本字体中缺少字形时，EnumEnhMetaFile 检索的后备字体仍然存在两个问题：

• 在 Windows 7 中始终是 Microsoft Sans Serif，但真正的后备字体应该是 Segoe UI Symbol。
• 在 Windows XP 中是 Tahoma 而不是 Microsoft Sans Serif，但仅适用于代理对字符（对于 BMP 字符是 Microsoft Sans Serif是正确的，我猜）。

有人可以帮我解决这个问题吗？

Answer 1

首先，您必须确保在 Win7 和 Win10 上使用相同的 API。我认为，较低级别的 gdi32 API 通常不应该支持代理对，而更新的 DirectWrite 在每个级别上都支持。接下来要记住的是字体回退（字体链接是不同的东西）数据因版本而异，它不是用户可以访问的东西，也不能修改。

首先要检查Win7是否在U+1F5A4处为符号提供字体，它可能只是在以后的版本中引入的。

基本上，如果您使用的是系统渲染功能，无论是旧的还是新的，大多数时候您都不应该控制回退，如果它对您不起作用，通常意味着它不起作用。 DirectWrite 允许自定义后备列表，例如，您可以在其中明确地将 U+1F5A4 分配给您想要的任何支持它的字体，包括您可以与应用程序捆绑的自定义字体。

如果您想要更详细的答案，您需要显示一些不适合您的来源摘录。

Answer 2

我相信代理对的高位和低位 16 位字已经很好地定义了。您应该能够通过检查每个 16 位字的值范围来识别代理对。

对于高位字，它应该在 0xd800 到 0xdbff 的范围内 对于低位字，它应该在 0xdc00 到 0xdfff 的范围内

如果任何两对“字符”满足此条件，则它们是代理对。

有关更多信息，请参阅有关 UTF-16 的维基百科文章。