OpenTypeフォントの続き(6)・・・cmapテーブル
今回はcmapテーブル。
cmapテーブルは文字コードからグリフインデックスへのマッピングを定義するテーブルで、必須である。また、様々なプラットフォーム・エンコーディング向けに複数のサブテーブルを定義することができる。
cmapテーブルの構造は、cmapヘッダーで始まり、次のようになる。
型 | 名前 | 説明 |
---|---|---|
USHORT | Version | テーブルバージョン |
USHORT | NumTables | エンコーディングテーブル数 |
EncodingRecord | EncodingRecords[NumTables] | エンコーディングレコードの配列 |
NumTablesフィールドはcmapテーブルに含まれるエンコーディングサブテーブルの数を表し、EncodingRecordsフィールドはエンコーディングレコードの配列を表す。各エンコーディングレコードの構造は次のようになる。
型 | 名前 | 説明 |
---|---|---|
USHORT | PlatformID | プラットフォームID |
USHORT | EncodingID | プラットフォーム固有のエンコーディングID |
ULONG | Offset | cmapテーブルの先頭からのエンコーディングサブテーブルへのオフセット(バイト単位) |
PlatformID、EncodingIDフィールドの表す値は、nameテーブルの回で説明した通りである。Offsetフィールドはcmapテーブルの先頭からのエンコーディングサブテーブルへのオフセットを表し、この値を使って、各エンコーディングサブテーブルにアクセスする。次にエンコーディングサブテーブルの構造であるが、エンコーディングの特性に応じて、複数のフォーマットが定義されている。各フォーマットの概要は次のようになる。
種類 | 概要 |
---|---|
フォーマット0 | Byte encoding table |
フォーマット2 | High-byte mapping through table |
フォーマット4 | Segment mapping to delta values |
フォーマット6 | Trimmed table mapping |
フォーマット8 | mixed 16-bit and 32-bit coverage |
フォーマット10 | Trimmed array |
フォーマット12 | Segmented coverage |
フォーマット0は、1バイトエンコーディングフォーマットである。フォーマット2は、混合8/16ビットエンコーディングフォーマットで、1バイトと2バイトの文字コードが混在する日本語のShift-JISなどで使われる。フォーマット4は2バイトエンコーディングフォーマットである。フォーマット8、10、12は4バイトエンコーディングフォーマットである。MicrosoftはWindows向けのサロゲートペアに対応したUnicodeフォントを作成する時、フォーマット4とフォーマット12を組み合わせて使うように推奨している。ちなみに、どのフォーマットが使われているかを判定するには、各エンコーディングサブテーブルの先頭2バイトがフォーマットの種類を表すFormatフィールドで始まるので、このフィールドを参照して判定できる。
各フォーマットの詳細は割愛するとして、実際にcmapテーブルを解析してみた。
上の画像はTahomaフォント(TAHOMA.TTF)を解析した時の実行結果である。MacintoshプラットフォームとMicrosoftプラットフォーム向けの2つのエンコーディングサブテーブルが含まれていることが分かる。Microsoftプラットフォーム向けのエンコーディングサブテーブルは、Unicodeエンコーディングでフォーマット4が使われていることも分かる。Macintoshプラットフォーム向けのエンコーディングサブテーブルは、下の画像が示す通り、フォーマット0が使われている。
実際に、TAHOMA.TTFファイルをMacintosh上でそのまま使えるかは分からないが、フォーマット0は1バイト文字コード向けのフォーマットなので、Macintosh上では、最大256個のグリフまでしかアクセスできないことになる。
最後にいつもならMS ゴシックフォントを解析するところだが、結果がTahomaフォントとあまり変わらないので、インターネット上で見つけた無料のフォントを解析してみた。
Macintoshプラットフォーム向けにShift-JISのエンコーディングサブテーブルが定義されていて、フォーマット2が使われていることが分かる。
« OpenTypeフォントの続き(5)・・・OS/2テーブル | トップページ | OpenTypeフォントの続き(7)・・・locaテーブル »
「フォント」カテゴリの記事
- OpenTypeフォントの続き(2)・・・OpenTypeテーブル(2008.02.07)
- OpenTypeフォントの続き(1)・・・TTC(2008.02.06)
- OpenTypeフォントの続き(4)・・・head・maxpテーブル(2008.02.14)
- OpenTypeフォントの続き(6)・・・cmapテーブル(2008.02.28)
- OpenTypeフォントの続き(8)・・・glyfテーブル(2008.03.01)
コメント
トラックバック
この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1497665/39651794
この記事へのトラックバック一覧です: OpenTypeフォントの続き(6)・・・cmapテーブル:
« OpenTypeフォントの続き(5)・・・OS/2テーブル | トップページ | OpenTypeフォントの続き(7)・・・locaテーブル »
貴重なフォント情報をありがとうございます。
Mac OSXの欧米ソフトで縦書きフォントを使いたいのですが、フォントの選択肢には横書きのものしか
表示されません。
縦方向に送る機能はあるので、見た目縦書きになるのですが、例えば音引きなどの
フォントが横向きになってしまいます。
マップテーブルの情報を書き換えて縦書き文字のグリフをヨコに寝てしまうグリフの
位置に置きたいと思うのですが、cmapを変更してそういったこともできるでしょうか。
具体的にはFinalCutでBoris Title3Dという字幕を入れるソフトです。
ご指導いただけると有りがたいです。
投稿: ばば | 2012年2月29日 (水) 06時22分
cmapを変更するというより、OpenTypeフォントのvertフィーチャーを
使うのが一般的かもしれません。
http://vanillasky-room.cocolog-nifty.com/blog/2008/07/opentype-4b7d.html
http://vanillasky-room.cocolog-nifty.com/blog/2008/08/opentype5gsub-2.html
つまり、文字コードからcmapを使って横書きのグリフに変換されて、vertフィーチャーを適用し、その横書きのグリフが縦書きのグリフに変換されるという感じで。
この場合、フォント自体が縦書きに対応してvertフィーチャーをもっていても、表示するフォントレンダラの方が対応できなきゃ意味ないですが。
cmapを変更してもいけるとは思いますが、MacOS自体やお使いのアプリ自体の内部動作がどうなってるのかわからないので、実際やってみていちいち目で確認するとかしかないような気がします。グリフIDはcmap以外のテーブルでも色々使われていたりして、状況によっては表示があれ?みたいな感じになるかもしれませんが。
投稿: vanilla | 2012年2月29日 (水) 23時33分