爲什麼FONTSIGNATURE不反映lfCharSet？

我列舉Windows字體是這樣的：爲什麼FONTSIGNATURE不反映lfCharSet？

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，希伯來語，阿拉伯語等。

我知道我想繪製的字符串的字符集，所以我試圖基於字體簽名實例化一個適當的字體。由於字體簽名總是匹配，所以即使在顯示希伯來文或阿拉伯文文本時，我總是最終選擇「西方」字體。我使用低級別的Uniscribe API，所以我沒有得到Windows字體鏈接的好處，但我的代碼似乎工作。

lfCharSet究竟是否帶有任何意義，或者是遺留的神器？我是否應該將lfCharSet設置爲DEFAULT_CHARSET並停止擔心每張臉的所有腳本變體？

爲了我的目的，我只關心TrueType和OpenType字體。

來源

2010-06-14 Adrian McCarthy

我想我找到了答案。多次枚舉的字體是"big" fonts。大字體是包含多個腳本或代碼頁的字形的單一字體。

FONTSIGNATURE（fsUsb）的Unicode部分表示字體可以處理的所有Unicode子範圍。這與字符集無關。如果使用寬字符API，則可以在字體中使用所有包含的字形，而不管創建字體時指定了哪個字符集。

FONTSIGNATURE（fsCsb）的代碼頁部分代表字體可以處理的代碼頁。我相信這隻在字體不是「大」字體時纔有意義。在這種情況下，fsUsb掩碼將全部爲零，並且fsCsb將指定適當的字符集。在這些情況下，在LOGFONT中正確輸入lfCharSet非常重要。

當實例化一個「大」字體並使用寬字符API時，指定哪個lfCharSet顯然無關緊要。

來源

2010-06-16 19:47:26

爲什麼FONTSIGNATURE不反映lfCharSet？

回答

相關問題