1

私は次のような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。2回目の呼び出しで、とを取得"Hebrew"しHEBREW_CHARSETます。3回目の呼び出し"Arabic"とARABIC_CHARSET。等々。ここまでは順調ですね。

ただし、Arialのすべてのバージョンのフォント署名（ ）フィールドは同じです。pMetrics->ntmFontSig実際、フォント署名は、ArialのこれらのバージョンすべてがLatin-1、ヘブライ語、アラビア語などをサポートしていると主張しています。

描画しようとしている文字列の文字セットを知っているので、フォントの署名に基づいて適切なフォントをインスタンス化しようとしています。フォントの署名は常に一致するため、ヘブライ語やアラビア語のテキストを表示する場合でも、常に「西洋」フォントを選択することになります。低レベルのUniscribeAPIを使用しているため、Windowsフォントリンクのメリットは得られませんが、コードは機能しているようです。

lfCharSet実際に何か意味がありますか、それともレガシーアーティファクトですか？それぞれの顔のすべてのスクリプトのバリエーションについて心配するのをやめるlfCharSetべきですか？DEFAULT_CHARSET

私の目的では、TrueTypeフォントとOpenTypeフォントのみを気にします。

4

1 に答える 1

1

私は答えを見つけたと思います。複数回列挙されるフォントは「大きな」フォントです。ビッグ フォントは、複数のスクリプトまたはコード ページのグリフを含む単一のフォントです。

FONTSIGNATURE( ) のUnicodefsUsb部分は、フォントが処理できるすべての Unicode サブ範囲を表します。これは文字セットに依存しません。ワイド文字 API を使用すると、フォントの作成時に指定された文字セットに関係なく、フォントに含まれるすべてのグリフを使用できます。

FONTSIGNATURE( )のコード ページ部分はfsCsb、フォントが処理できるコード ページを表します。これは、フォントが「大きな」フォントでない場合にのみ重要だと思います。その場合、fsUsbマスクはすべてゼロになりfsCsb、適切な文字セットが指定されます。lfCharSetそのような場合、 で正しいを取得することが重要LOGFONTです。

lfCharSet「大きな」フォントをインスタンス化してワイド文字 API を使用する場合、どちらを指定しても問題はないようです。

于 2010-06-16T19:47:26.653 に答える