今回はMLangの続きで、IMLangFontLinkインターフェース。フォントリンクとは、選択したフォントで表示できない文字を、その選択したフォント(ベースフォント)にリンクしたフォントで表示できれば、それを使って表示するメカニズムのことであるが、このインターフェースを利用すれば、フォントリンクを利用したり、カスタムフォントを作成できるとのことなので、実際に使ってみる。
IMLangFontLinkインターフェースにいくつかのメソッドがあるが、フォントリンクのサービースを利用するには、主にその内の
- GetFontCodePagesメソッド
- GetCharCodePagesメソッド
- MapFontメソッド
- ReleaseFontメソッド(とResetFontMappingメソッド)
を使用する。まずは、GetFontCodePagesメソッドである。MSDNの説明によれば、
Gets the set of code pages whose characters can be output by the specified font on the given device context.
である。指定したデバイスコンテキスト上で指定したフォントによって表示できる文字のコードページ集合が返される。最初、指定したフォントだけで表示できる文字のコードページ集合が返されると勘違いしてしまったが、返されるのは指定したフォントとそれにリンクしたフォントで表示できる文字のコードページ集合である。
次に、GetCharCodePagesである。これは指定した文字のコードページ集合を求めるメソッドである。指定した文字が指定したフォント(とそれにリンクされたフォント)で表示できるか判定するには、上記2つのメソッドを使って返されたコードページ集合のビットごとの論理積を取ればよい。
MapFontメソッドは指定したコードページ集合とソースフォントからそれを表示できるリンクしたフォント?を返すメソッドらしい??。
と、MapFontメソッドで返されるフォントの理解に苦しむが、いつも通りU+0000からU+FFFFの各文字に対してMapFontメソッドを呼び出しどのようなフォントが返されるか調べてみる。実行結果は次の通り。
ベースフォントはTahomaである。Tahomaフォントを指定してGetFontCharCodePagesメソッドを呼び出して返されるコードページ集合は2032127であるが、そのコードページ集合に含まれる各コードページは、
である(まぁ、ここらへんは実行環境によって変わるはず)。先ほどの、GetFontCodePagesメソッドの説明で、返されるコードページ集合は、指定したフォントとそれにリンクしたフォントによって表示できる文字のコードページ集合と書いたが、Tahomaは日本語の文字に対するグリフを持っていないが、上の画像に日本語のシフトJISに対応するコードページが含まれていることからも、リンクしたフォントも考慮されている事が分かる。また、最初の画像より、コードポイントU+0041の「A」(LATIN CAPITAL LETTER A)に対するMapFontメソッドによって返されるフォントの名前がArialであることが分かる(MapFontメソッドによって返されるのはHFONT型のフォントハンドルなのでそれからWin32APIのGetObject関数を使いLOGFONT構造体を取得してそのlfFaceNameメンバの値をここでは表示した)。
次に、コードポイントU+3042の「あ」(KATAKANA LETTER A)を見てみる。
MS PゴシックフォントがMapFontメソッドによって返されているのが分かる。
ところで、この結果をCharCodePagesが0の結果でフィルタしてみると、
MSDNのヘルプに、IMLangFontLinkはMicrosoftのコードページベースでフォントリンクを行うと書いてあるように、CharCodePagesが0の文字に対してMapFontメソッドの呼び出しが失敗していることが分かる(FontNameがFailedになってるが実際にFailedという名前のフォントが返されたのではない事に注意)。
ふむふむ。
最後にいつものように、作ったプログラムはここのMultiLang.zip。メモリ食うし重いので注意を。
最近のコメント