5. フォントの作成

FONT ライブラリで使用するフォントリソースは、ctr_FontConverter(CUI 版は ctr_FontConverterConsole)を利用して、PC にインストールされているフォントや画像データから作成することができます。

注意:

CTR-SDK には、いかなるフォントのライセンスも付属していません。

ctr_FontConverter では FONT ライブラリによる文字表示に利用するフォントリソースを、PC にインストールされているフォントや画像データから作成することができますが、これらのフォントを利用したソフトを発売するには利用するフォントのライセンスが必要になります。必ず、ゲームソフトごとに適切なライセンスを取得してください。

ctr_FontConverter はフォントリソースの作成だけでなく、フォントを画像データとして出力することができます。出力可能な画像データのフォーマットは BMP 形式と TGA 形式で、これらの画像データはフォントリソースの作成に利用可能です。つまり、出力した画像データを手直ししてフォントリソースを再作成したり、画像データを結合して複数のフォントが含まれているフォントリソースを作成したりすることができます。

5.1. 作成に利用するファイル

ctr_FontConverter がフォントリソースを作成する際には、以下のファイルを利用します。

  • 文字フィルタファイル
  • グリフグループファイル
  • 文字順序ファイル

これらのファイルはすべて XML(eXtensible Markup Language)で記述し、おおまかな構造は共通しています。

5.1.1. 共通する構造

最上位の要素の名前は異なりますが、version 属性を持ち、head 要素と body 要素を包含している構造は共通しています。また、head 要素の構造は共通していますが、body 要素の構造はそれぞれ異なります。

下表は共通部分の要素の一覧です。表中で太字の要素および属性は必須の項目です。

表 5-1. 共通部分の要素一覧
要素

包含可能要素(上段)

属性(下段)

説明
最上位の要素 head, body

最上位の要素で、要素名はファイルごとに異なります。

包含可能要素と属性はすべてのファイルで共通です。

version
head create, title, comment, generator

ファイルそのものの情報(ヘッダ)を格納します。

すべてのファイルで共通する構造を持つ要素です。

なし
create なし

ファイル作成時の情報を格納します。

user 属性にはファイルを作成した PC のユーザー名を、host 属性には PC 名を格納します。date 属性には作成日時を ISO 8601 に規定される日付と時刻の拡張形式で格納します。

source 属性にはデータの元となるファイルが存在する場合に、元データのファイル名を格納します。

user, host, date, source
title なし

ファイルのタイトルを格納します。

GUI 版 ctr_FontConverter で表示される選択項目に使用されることがあります。

なし
comment なし ファイルの作成者のコメントを格納します。
なし
generator なし

ファイルを作成したアプリケーションの情報を格納します。

name 属性にはアプリケーションを識別するための文字列を、version 属性にはアプリケーションのバージョン文字列を格納します。

name, version

body ファイルによる ファイルの本体となる情報を格納します。
なし

下図は要素の階層を図示したものです。

図 5-1. 共通部分の要素の階層図

要素 属性 最上位の要素 version head create user host date source title comment generator name body

5.1.2. 文字フィルタファイル

文字フィルタファイル(拡張子 xllt)は、必要な文字だけを含む、コンパクトなフォントリソースの作成に利用します。フォントの変換時に、ファイルに指定されている文字以外を出力しないようにすることができます。変換元のデータに含まれている、すべての文字を対象にして作成する場合は不要です。

最上位の要素は「letter-list」で、version 属性には「1.0」を格納します。body 要素は letter 要素を 1 つだけ包含します。

表 5-2. 文字フィルタファイルの要素一覧(共通部分以外)
要素

包含可能要素(上段)

属性(下段)

説明
letter-list head, body

最上位の要素です。

version 属性には 1.0 を格納します。

version
body letter

ファイルの本体となる情報を格納します。

包含可能な要素は letter 要素 1 つだけです。

なし
letter なし

出力する文字を定義します。

文字の指定は出力したい文字を直接記述することで行います。ただし空白文字(半角スペースとタブ文字)は無視され、変換結果には必ず半角スペースが追加されます。

なし

下図は要素の階層を図示したものです。

図 5-2. 文字フィルタファイルの要素の階層図

要素 属性 letter-list version head body letter

以下のコードは、文字フィルタファイルのサンプル(sample.xllt)の内容です。

コード 5-1. 文字フィルタファイルのサンプル(sample.xllt)
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE letter-list SYSTEM "letter-list.dtd">
<letter-list version="1.0">
    <head>
        <create user="sample" date="2005-02-18T10:51:13" />
        <title>xlltサンプル</title>
        <comment>文字フィルタファイルのサンプルです</comment>
    </head>
    <body>
        <letter>
            FontConverter
            あいうえかきくけ
            任天堂
        </letter>
    </body>
</letter-list>

5.1.3. グリフグループファイル

グリフグループファイル(拡張子 xggp)は、アーカイブフォント(圧縮フォント)の作成に利用します。グループセットを指定(CUI 版ならばコマンド引数 -op にファイルを指定)することで、ファイルに設定されている、グループの情報を含んだフォントリソースを作成することができます。

最上位の要素は「glyph-groups」で、version 属性には「1.0」を格納します。body 要素は group 要素を 1 つだけ包含します。

表 5-3. グリフグループファイルの要素一覧(共通部分以外)
要素

包含可能要素(上段)

属性(下段)

説明
glyph-groups head, body

最上位の要素です。

version 属性には 1.0 を格納します。

version
body group

ファイルの本体となる情報を格納します。

包含可能な要素は group 要素 1 つだけです。

なし
group sp, group

グリフグループを定義します。

列挙された文字は、name 属性で指定された名前のグリフグループに含まれます。group 要素内では、複数の group 要素を入れ子にすることができます。

name 属性に使用できる文字は半角の英数字(0~9, a~z, A~Z)とアンダーバー(_)のみです。name 属性が重複するような group 要素は、同じファイル内に定義することができません。

name
sp なし group 要素内では半角スペースを直接記述しても無視されるため、group 要素内で半角スペースを指定するために使用します。
なし

下図は要素の階層を図示したものです。

図 5-3. グリフグループファイルの要素の階層図

要素 属性 glyph-groups version head body group name sp group (複数の入れ子が可能)

以下のコードは、グリフグループファイルのサンプル(sample.xggp)の内容を抜粋したものです。

コード 5-2. グリフグループファイルのサンプル(sample.xggp から抜粋)
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE glyph-groups SYSTEM "glyph-groups.dtd">
<glyph-groups version="1.0">
    <head>
        <create user="sample" date="2006-09-05T14:50:23" />
        <title>sample</title>
    </head>
    <body>
        <group name="all">
            <group name="ascii">
                <sp/> ! " # $ % & ' ( ) * + , - . /
                (中略)
                p q r s t u v w x y z { | } ~
            </group>
            <group name="european">
                € ‚ ƒ „ ... † ‡
                ˆ ‰ Š ‹ Œ Ž
                (中略)
            </group>
        (中略)
        </group>
    </body>
</glyph-groups>

5.1.4. 文字順序ファイル

文字順序ファイル(拡張子 xlor)は、画像データからフォントリソースを作成する場合やフォントを画像データとして出力する場合に必要となります。入力に使用した場合は、画像データ内に描かれている文字の順序と、このファイルに設定されている文字の順序は一致していなければなりません。出力に使用した場合は、このファイルに設定されている順番に文字が描かれるため、フィルタとしての役割も果たすことになります。

最上位の要素は「letter-order」で、version 属性には「1.0」または「1.1」を格納します。body 要素は area 要素と order 要素を包含します。

表 5-4. 文字順序ファイルの要素一覧(共通部分以外)
要素

包含可能要素(上段)

属性(下段)

説明
letter-order head, body

最上位の要素です。

version 属性には 1.0 または 1.1 を格納します。

version 属性に 1.0 を指定した場合、order 要素内で同じ文字コードを持つ文字が複数記述されていてもエラーになりません。ただし、同じ文字コードのグリフが存在する場合は、その中で最初に記述されたグリフが採用されるため、グリフイメージを編集してもフォントリソースに反映されない可能性があります。version 属性に 1.1 を指定した場合は、order 要素内で同じ文字コードを持つ文字が複数記述されているとエラーになりますので、通常は 1.1 を指定することを推奨します。

version
body area, order

ファイルの本体となる情報を格納します。

包含可能な要素は area 要素と order 要素です。

なし

area なし

画像データに含まれているフォントイメージを、縦横の文字数で定義します。

width 属性は横方向の文字数を定義します。省略したときは 16 が指定されたものとして扱われます。

height 属性は縦方向の文字数を定義します。省略したときは order 要素で指定された文字を出力するために必要十分な値が指定されたものとして扱われます。

width, height
order sp, null

出力する文字とその順序を定義します。

列挙された文字は、その順番どおりにフォントリソースに出力されます。

なし
sp なし order 要素内では半角スペースを直接記述しても無視されるため、order 要素内で半角スペースを指定するために使用します。
なし
null なし 出力位置を 1 文字分飛ばします。該当位置のブロックをフォントリソースに出力したくない場合に使用します。
なし

下図は要素の階層を図示したものです。

図 5-4. 文字順序ファイルの要素の階層図

要素 属性 letter-order version head body area width height order sp null

以下のコードは、文字順序ファイルのサンプル(cp1252.xlor)の内容を抜粋したものです。

コード 5-3. 文字順序ファイルのサンプル(cp1252.xlor から抜粋)
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE letter-order SYSTEM "letter-order.dtd">
<letter-order version="1.1">
    <head>
        <create user="sample" date="2005-02-18T10:51:13" />
        <title>European Language (CodePage 1252 / Latin-1)</title>
        <comment>Windows Code Page 1252 character set. It is super set of ISO 8859-1 (Latin-1).</comment>
    </head>
    <body>
        <area width="16" />
        <order>
            <sp/> ! " # $ % & ' ( ) * + , - . /
            0 1 2 3 4 5 6 7 8 9 : ; < = > ?
            (中略)
            € <null/> ‚ ƒ „ ... †
            ‡ ˆ ‰ Š ‹ Œ <null/>
            Ž <null/>
            (中略)
        </order>
    </body>
</letter-order>

5.1.4.1. 記述上の注意

ctr_FontConverter の内部処理は文字コードとして Unicode を使用しているため、文字コードが同一かどうかの判定も Unicode で行われることに注意しなければなりません。例えば、CP1252 と ShiftJIS をそれぞれの文字コードで比較すると、ASCII 文字同士および欧州文字と半角カナ文字が同一の文字コードに割り当てられていますが、Unicode の文字コードで見ると欧州文字と半角カナ文字は異なる文字コードに割り当てられているため、同一ではないと判定されます。しかし、表 5-5にある 16 文字はそれぞれの文字セットでは異なる文字コードに割り当てられていますが、Unicode では同じ文字コードに割り当てられているため、同一であると判定されます。SDK に付属している文字順序ファイルの cp1252_JIS_X0201_X0208_012.xlor と cp1252_JIS_X0201_X0208_012_94.xlor では、この問題を避けるために ShiftJIS 側の 16 文字を <null/> に置き換えています。

表 5-5. Unicode で同じ文字コードにマッピングされる文字
グリフ CP1252 での文字コード ShiftJIS での文字コード Unicode での文字コード
´ 0xB4 0x814C U+00B4
¨ 0xA8 0x814E U+00A8
0x85 0x8163 U+2026
' 0x91 0x8165 U+2018
' 0x92 0x8166 U+2019
" 0x93 0x8167 U+201C
" 0x94 0x8168 U+201D
± 0xB1 0x817D U+00B1
× 0xD7 0x817E U+00D7
÷ 0xF7 0x8180 U+00F7
° 0xB0 0x818B U+00B0
§ 0xA7 0x8198 U+00A7
0x89 0x81F1 U+2030
0x86 0x81F5 U+2020
0x87 0x81F6 U+2021
0xB6 0x81F7 U+00B6

5.2. PC にインストールされているフォントから作成する

ctr_FontConverter は、PC にインストールされているフォントからフォントリソースを作成することができます。ライセンスされていないフォントを商品に使用してしまう可能性を排除するために、自動フォントリンク機能を無効にした状態でフォントリソースを作成しますので、指定されたフォントに含まれていない文字はフォントリソースには含まれません。

自動フォントリンク機能のため、一般のテキストエディタなどで表示されるときには、フォントに含まれていない文字が別のフォントから補完されている場合があります。Windows のアプリケーション「文字コード表」ならば、フォントに含まれている文字だけを確認することができます。

5.3. 画像データから作成する

ctr_FontConverter は、フォントイメージが描かれている画像データと文字順序ファイルからフォントリソースを作成することができます。ctr_FontConverter の入力に使用可能な画像データは、以下の形式でなければなりません。

表 5-6. ctr_FontConverter が対応している画像データの形式
形式 対応範囲
インデックスカラー BMP 1 ピクセルあたり、1, 4, 8 ビット(2, 16, 256 色)。
ダイレクトカラー BMP 1 ピクセルあたり、24 ビット(RGB8)、32 ビット(RGBA8)。
ColorMap 形式の TGA 1 ピクセルあたり、インデックスは 8, 16 ビット(256, 65536 色)、パレットは 24 ビット(RGB8)、32 ビット(RGBA8)。ランレングス圧縮されたデータにも対応しています。
TrueColor 形式の TGA 1 ピクセルあたり、24 ビット(RGB8)、32 ビット(RGBA8)。ランレングス圧縮されたデータにも対応しています。

画像データからの入力オプションで指定されたカラーフォーマットと画像データの形式により、以下のように変換処理が行われます。インテンシティ形式のフォントでは、画像データの輝度値が逆転した値に変換されることに注意してください。つまり、黒に近いピクセルほど輝度値が高く、白に近いピクセルほど輝度値が低くなります。

表 5-7. カラーフォーマットと変換時に行われる処理
カラー 変換処理
A4

インデックスカラーの場合、インデックス値を 4 ビットに変換します。

ダイレクトカラーの場合、RGB 成分の平均値を 16 階調に変換します。

A8

インデックスカラーの場合、インデックス値を 8 ビットに変換します。

ダイレクトカラーの場合、RGB 成分の平均値を 256 階調に変換します。

LA4

インデックスカラーの場合、輝度値にはインデックス値を 4 ビットに変換したものを使用します。

ダイレクトカラーの場合、輝度値には RGB 成分の平均値を 16 階調に変換したものを使用します。

画像データのカラーフォーマットに関係なく、アルファ値にはピクセルのアルファ成分を 4 ビットに変換したものを使用します。

LA8

インデックスカラーの場合、輝度値にはインデックス値を 8 ビットに変換したものを使用します。

ダイレクトカラーの場合、輝度値には RGB 成分の平均値を 256 階調に変換したものを使用します。

画像データのカラーフォーマットに関係なく、アルファ値にはピクセルのアルファ成分を 8 ビットに変換したものを使用します。

RGB565 RGB 成分それぞれが 5, 6, 5 ビットになるように変換し、アルファ成分は使用しません。
RGB5A1 RGB 成分それぞれが 5 ビットになるように変換し、アルファ成分は上位 1 ビットのみ使用します。
RGBA4 RGBA 成分それぞれが 4 ビットになるように変換します。
RGB8 RGB 成分それぞれが 8 ビットになるように変換し、アルファ成分は使用しません。
RGBA8 RGBA 成分それぞれが 8 ビットになるように変換します。
線形補間対策処理

FONT ライブラリによる文字の描画では、グリフをポリゴンに貼り付けたテクスチャとして表示するため、拡大時にはハードウェアによるテクスチャの線形補間機能を使用することができます。しかし、フォントのフォーマットがアルファチャンネルを持つ場合、テクスチャの線形補間機能を使うとアルファ値が 0 のピクセルのカラーが参照され、意図しない表示になることがあります。

ctr_FontConverter では、フォントリソースへの変換時に線形補間対策処理を適用することができます。線形補間対策処理では、完全透明(アルファ値が 0)であるピクセルのカラーを、そのピクセルと隣り合う 8 つのピクセルのうち、完全透明ではない(アルファ値が 0 ではない)ピクセルのカラーを平均したものに書き換えます。アルファ値は書き換えません。このようにグリフを補正することで、線形補間機能による意図しない表示を解消することができます。

5.3.1. ブロック

ブロックとは、グリフイメージが描かれているセルと文字幅を示す幅線領域を含む画像データの部分領域のことです。文字順序ファイルに記述された 1 文字が 1 ブロックに対応し、入力に使用する画像データには、このブロックが隙間なく敷き詰められていなければなりません。

入力に使用する画像データは、以下のように制限されています。

ブロックの幅 × ブロックの横方向の数 = 画像の幅

ブロックの高さ × ブロックの縦方向の数 = 画像の高さ

つまり、画像中にブロックは隙間なく並び、余白があってはいけません。

実際には、文字順序ファイルによりブロックの横(縦)方向の数が、画像データにより画像の幅(高さ)が決定し、そこからブロックの幅(高さ)が計算されます。そして、このブロックの幅(高さ)が整数でなければ入力に使用することができません。

以下の図は画像データの例です。

図 5-5. 画像データの例(ブロック数 16×6)

ブロック内には、グリフイメージの描画エリアであるセルがあり、この領域内にグリフイメージを描画します。セルの下には、1 ピクセルの余白エリアを挟んで高さ 1 ピクセルの幅線領域があり、幅線は文字幅と、グリフイメージの相対的な位置を定義します。セルと幅線領域の周囲 1 ピクセルが余白エリア、その周囲 1 ピクセルがグリッドエリアとなっており、隣接するブロックとのグリッドエリアの境がブロックの境となります。変換時にグリッドエリアのチェックは行われませんが、余白エリアが単一色でなければグリフイメージがはみ出していると判断されます。

幅線領域の高さや余白エリア、グリッドエリアのピクセル数は固定であるため、セルの大きさは常に、

セルの幅 = ブロックの幅 - 4 ピクセル

セルの高さ = ブロックの高さ - 6 ピクセル

となります。

以下の図はブロックの模式図です。

図 5-6. ブロックの模式図

セル グリッドエリア 余白エリア 幅線領域

5.3.2. セルと幅線領域

セルの内部にはグリフイメージのみを配置します。ctr_FontConverter はセル内に存在する、アルファ値が 0 ではない、または色が白(255, 255, 255)ではないピクセルを含む最小の矩形を検出し、それをグリフイメージとして扱います。そのためセルのサイズが大きくてもグリフイメージの周囲の白色透明部分は無視され、出力されるフォントに影響を与えません。なお、画像データがアルファチャンネルを含まない場合は、色が白ではないピクセルを含む最小の矩形をグリフイメージとして扱います。

幅線領域には、幅線と呼ばれる 1 つの線分のみを描きます。幅線は文字幅と文字の左右(前後)に空けるスペースの幅を規定します。幅線の横幅がそのまま文字幅となり、線分が途中で途切れて 2 つになっていたりするとエラーとなります。文字幅はグリフイメージの幅より小さくすることができ、その場合は 3DS 上で前の文字と重なって表示されることになります。幅線との位置関係が同じであれば、セルの中でグリフイメージを左右に移動しても出力されるフォントは変化しません。

グリフイメージのサイズが 0 で幅線の幅も 0 である場合、またはセル内が単一色で塗りつぶされていて、幅線の幅が 0 の場合、このグリフは出力されません。これを利用して、文字フィルタファイルを使用せずに出力するグリフを制御することもできます。逆に、文字フィルタファイルでは出力指定されているのにグリフが出力に渡されない場合は、意図しない文字の抜け落ちの可能性があるため警告が表示されます。

5.3.2.1. 配置情報

画像データの一番左上のブロックには、文字列を描画するときに文字列の配置の基準となる値を指定する 1 ピクセルの点(配置情報)がいくつか含まれます。配置の基準となる値とはベースライン、アセンダライン、ディセンダライン、フォント幅の 4 つで、この 4 つを 5 つの点で指定します。これらの値はフォント全体で共通となり、文字ごとに指定することはできません。

すべての点はグリッドエリアに存在し、グリッドを描画している場合は白(255, 255, 255)で、グリッドを描画していない場合はグリッド色で描画します。ベースライン位置を表すピクセルは必ず存在しなければなりませんが、残りの 4 点は省略することができます。

画像の一番左上の 1 ピクセルは将来の用途のために予約されており、必ず白色(255, 255, 255)でなければなりません。また、この 1 ピクセルは抜き色としても使用しています。アルファ値が入力されている場合は、アルファ値を含む色として抜き色を判定します。

図 5-7. ブロックの配置情報

文字幅 グリフ幅 フォント幅 左スペース幅 右スペース幅 アセンダライン ディセンダライン ベースライン フォントの高さ 予約済みのピクセル フォント幅の左端を表すピクセル(省略可能) フォント幅の右端を表すピクセル(省略可能) アセンダライン位置を表すピクセル(省略可能) ベースライン位置を表すピクセル ディセンダライン位置を表すピクセル(省略可能)

ベースライン

ベースライン位置を表す点はグリッドエリアの左側領域に描画します。このピクセルの上端がベースライン位置となります。つまり、ベースラインはピクセルとピクセルの間に存在します。ベースラインは異なるフォントを混ぜて使用する場合や拡大縮小を行う場合の上下方向の基準位置となります。

アセンダライン、ディセンダライン

アセンダライン位置と、ディセンダライン位置を表す点もグリッドエリアの左側領域に描画します。アセンダラインとディセンダラインも、ベースラインと同様にピクセルとピクセルの間に存在し、アセンダラインはアセンダライン位置を表すピクセルの下端が、ディセンダラインはディセンダライン位置を表すピクセルの上端がそれぞれの位置になります。アセンダラインは文字列の上端として、ディセンダラインは文字列の下端として扱われます。また、アセンダラインとディセンダライン間の距離をフォントの高さと呼び、縦方向に拡大縮小する場合の基準サイズとなります。

アセンダラインは必ずベースラインの上方に位置し、ディセンダラインは必ずベースラインの下方に位置します。また、ディセンダライン位置を表すピクセルはベースライン位置を表すピクセルと重ねることができ、この場合ディセントは 0 になります。

アセンダライン位置とディセンダライン位置を表す 2 点は省略することができ、点の数に応じて表 5-8のように解釈されます。アセンダライン位置とディセンダライン位置を指定しなかった場合は、セルの上端がアセンダライン、セルの下端がディセンダラインとして扱われます。

ctr_FontConverter で画像データを出力すると、アセンダライン位置とディセンダライン位置を表すピクセルが描かれる場合と描かれない場合とがあります。Windows フォントを入力とする変換では常に描かれず、フォントリソースを入力とする変換では常に描かれます。画像データを入力とする場合は、入力された画像にアセンダライン位置、ディセンダライン位置を表すピクセルが含まれていれば描かれ、含まれていなければ描かれません。アセンダライン位置、ディセンダライン位置を表すピクセルが描かれるときに、セルのサイズがこれらのピクセルを表現するのに小さすぎる場合はセルのサイズが自動的に拡大されます。

表 5-8. 点の数と解釈
点の数 上から 1 つ目の点 上から 2 つ目の点 上から 3 つ目の点
0 エラー
1 ベースライン -
2 アセンダライン ベースラインとディセンダライン -
3 アセンダライン ベースライン ディセンダライン
4 以上 エラー
フォント幅

フォント幅を表す 2 つの点はグリッドエリアの上側領域に描画します。2 つの点がそれぞれ幅の左端と右端を表し、2 つのピクセルに挟まれるピクセル数がフォント幅となります。挟まれるピクセル数が同じであれば点の左右位置は影響しません。フォント幅を表す点を省略した場合はセルの幅がフォント幅として扱われます。省略しない場合は必ず 2 点存在しなければなりません。フォント幅は横方向に拡大縮小するときや、タブ幅の基準サイズとなります。

ctr_FontConverter で画像データを出力すると、フォント幅を表すピクセルが描かれる場合と描かれない場合とがあります。Windows フォントを入力とする変換では常に描かれず、フォントリソースを入力とする変換では常に描かれます。画像データを入力とする場合は、入力された画像にフォント幅を表すピクセルが含まれていれば描かれ、含まれていなければ描かれません。フォント幅を表すピクセルが描かれるときに、セルサイズがこれらのピクセルを表現するのに小さすぎる場合はセルのサイズが自動的に拡大されます。

5.4. 既存のフォントリソースから作成する

bcfnt や bcfna からも、フォントリソースの作成や画像データの出力が可能です。フォントリソースに含まれている文字のフィルタリングや調査、グリフイメージのチェックや編集などに利用することができます。

注意:

元となるフォントリソースに含まれているフォントのライセンスに注意してください。