6

我的问题与此类似，但向前迈出了一步。

在我的 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它们不支持代理对。
我也尝试过支持代理对的GetCharacterPlacementUniscribe ScriptItemize+ ScriptShape，但是所有这些功能只搜索 HDC 的基本字体（Segoe UI），它们不搜索最终的后备字体（Segoe UI Symbol），这是提供字形。

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

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

编辑

我找到了某种解决方案，可以复制此代码并添加最后一个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是正确的）。

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

4

2 回答 2

0

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

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

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

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

于 2017-12-16T10:44:42.193 回答
-3

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

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

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

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

于 2017-12-16T00:11:52.810 回答