CID 割り当ての完成

まず、変換元フォントに含まれる、すべてのグリフの CID 値を取得する必要があるので、おなじみの spot コマンドを使います。

$ spot -nc SourceHanSansJP-Regular.otf > cid.txt

-nc で、フォント内のすべてのグリフの、GID と CID (またはグリフ名) のマッピング情報を、１つ１行で出力します。

--- names[glyphId]=<name>
[0]=<\0>
[1]=<\1>
[2]=<\2>
...

左が GID、右が CID またはグリフ名です。

>> remap-tool.py
(右クリックで、名前を付けて保存してください)

$ python3 remap-tool.py -u out2.txt cid.txt > unused.txt

-u で、変換元フォントで未使用となるグリフの GID の番号を、標準出力に出力します。

１番目に、remap-gsub.py で出力したファイル。
２番目に、spot -nc で出力したファイルを指定してください。

ここでは、結果を unused.txt に出力します。

65,210,211,221,222,223,224,246,250,251,252,
253,254,374,375,376,377,378,379,380,381,382,
383,384,385,386,387,388,389,390,391,392,393,
...

このような形で、カンマで区切った GID のリストが並びます。
※ CID ではありません。

AFDKO には、グリフのアウトラインを PDF で出力するコマンドがいくつかあります。

fontplot と fontplot2 は、グリフのアウトラインと、グリフ名などの情報をリストで表示します。

fontplot は、グリフの情報が枠内に描画されるため、アウトラインによっては情報が隠れます。
fontplot2 は、グリフの情報が枠の外に描画されます。

ここでは、CID 番号も確認したいので、fontplot2 を使います。

$ fontplot2 -o out.pdf -gf unused.txt --pageIncludeTitle 0 --drawMeta_SideBearings 0 --metaDataNameSize 200 SourceHanSansJP-Regular.otf

-o FILE	出力ファイル名
-gf FILE	ファイルで指定されたグリフを対象にします。 指定がない場合、すべてのグリフが出力されます。 グリフはカンマで区切ります。 ',' の前後の空白・タブ・改行は無視されます。
--pageIncludeTitle 0	デフォルトで、ページの上部にタイトルが表示されますが、グリフと重なって邪魔な場合があるので、消します。
--drawMeta_SideBearings 0	"L=*,R=*,Width=*" の情報を消します。
--metaDataNameSize 200	グリフ名のテキストサイズ。 デフォルトでは 80 となり、とても小さくて見えづらいので、大きくします。

PDF 出力に関する細かいパラメータのヘルプは、-help_params で表示できます。

出力が終わると自動で PDF が開かれるので、グリフを確認してください。
自動で開きたくない場合は、-dno を指定してください。

主に記号がほとんどですが、韓国語や、縦書き用のひらがな・カタカナなどがあります。
Adobe-Japan1 では定義されていないようなグリフも多いので、基本的には無視して構いません。

縦書き用のひらかなに関しては、源ノフォントにおいては、GSUB の vert で置換グリフがあるため、縦書き時はそのグリフが使用されることになりますが、Adobe-Japan1 では、（小文字を除いて）vert でのひらかなグリフに対する、縦書き用のグリフは存在しません。
ただし、vkna での印刷縦組み用のひらかなは存在します。

これらの縦書き用のひらかなグリフは割り当てていませんが、実際は、これがなくても、問題なく描画できます。

Adobe-Japan1 では定義されているけれど、源ノフォントでは存在しないグリフも多数あります。

https://github.com/adobe-type-tools/Adobe-Japan1
Adobe-Japan1 のグリフ一覧は Adobe-Japan1-*.pdf。
各グリフの説明は、Adobe-Japan1-*_ordering.txt で確認できます。

源ノ角ゴシックであれば、単純に 6375 個ほどのグリフが不足しているわけですが、その多くは、縦書き用の90度回転した欧文グリフや、斜体のグリフ、囲み文字など、あまり使われないような文字がほとんどです。

そのため、これらが空であっても、たいして問題はありません。

mergefonts で、一部のグリフを別の名前に変更する場合は、その情報をファイルに記述して、指定する必要があります。
書式は以下のようになっています。

mergefonts [CID フォント辞書名]
[変換先の CID or グリフ名] [変換元の CID or グリフ名]
...

例:

mergefonts SansAJ-Regular-Generic
00000 00000
07479 01078
07480 01079

• １行目には、必ず "mergefonts" を記述する。
• mergefonts の後に、CID フォントのフォント辞書の名前を指定できる。
• CID 番号は 10 進数で表記し、桁数は自由 (CID は最大５桁)。
• 行頭が '#' で、コメント。
• 行末には常に改行が必要。
• .notdef (CID 0) のグリフは必ず含めること。

mergefonts コマンドでは、ファイルの先頭が "mergefonts" かどうかで、フォントファイルかマッピングファイルかを判断しているので、先頭には必ず "mergefonts" を記述してください。

欧文などの CFF フォントでは、各グリフはグリフ名で識別されるので、その場合は CID 番号ではなく、グリフ名を記述することになります。

CID フォントでは、フォント内に、複数のフォント辞書が存在し、各グリフは、そのフォント辞書に所属します。

例えば、源ノ角ゴシック CJK の Regular であれば、フォント自体の PostScript 名は「SourceHanSans-Regular」ですが、その中には、以下のようなフォント辞書名が存在します。

SourceHanSans-Regular-Alphabetic
SourceHanSans-Regular-AlphabeticDigits
SourceHanSans-Regular-Dingbats
SourceHanSans-Regular-DingbatsDigits
...

Adobe-Japan1-*_ordering.txt を見てみるとわかりますが、フォント辞書名の末尾の "Alphabetic" などは、各グリフの文字種を表しており、SourceHanSans-Regular-Alphabetic のフォント辞書内には、アルファベットのグリフが格納されています。

このように、CID フォントでは、各グリフの文字種別にフォント辞書が作成されるのが一般的であるため（必須ではありません）、CID フォントを作成する場合は、同じようにするのが好ましいでしょう。

mergefonts のマッピングファイルでは、１行目の "mergefonts" の後に、このファイルで指定されているグリフが所属するフォント辞書名を指定することができます。
指定名のフォント辞書が存在しない場合は新しく作成され、存在する場合は、そこにグリフが追加されます。

フォント辞書名は、基本的に、フォントの PostScript 名に、"-" と文字種の名前を付加した文字列となります。

※一つのマッピングファイルには、一つのフォント辞書しか指定できないので、複数のフォント辞書を指定する場合は、複数のマッピングファイルが必要になります。

>> remap-tool.py
(未使用グリフを確認した、先のスクリプトと同じです)

remap-gsub.py で出力したマッピング情報から、mergefonts 用のマッピングファイルを複数出力します。

$ python3 remap-tool.py -m 7 SansAJ-Regular out2.txt Adobe-Japan1-7_ordering.txt [-o DIR]

-o は、マッピングファイルの出力ディレクトリを指定します。
必要があれば、指定してください。

-m <suppliment> <PostScript名> で、各ファイルを元に、margefonts のマッピングファイルを出力します。

Suppliment は、作成するフォントの ROS の３番目の番号です (3〜7)。
最終的に Adobe-Japan1-7 のフォントを作成するのであれば、"7" を指定します。
それ以前の ROS にしたいのであれば、その番号を指定してください。
CID の総数を、各 ROS に対応した数に減らすだけで、対応できます。

２番目で指定する PostScript 名は、マッピングファイルのフォント辞書名の指定で使います。
最終的に出力するフォントの PostScript 名を指定してください。
基本的には、フォント名から空白や記号などを除外して、"-" とスタイル名を追加した名前となります。
ここでは、仮に "SansAJ-Regular" としておきます。

次に、remap-gsub.py で出力した、CID の割り当て情報のファイルを指定します。

その次に、以下でダウンロードしたファイルを指定してください。
(省略時は "Adobe-Japan1-7_ordering.txt")
各 CID の文字種を取得するために使います。

https://github.com/adobe-type-tools/Adobe-Japan1
- Adobe-Japan1-7_ordering.txt

文字種ごとに、map-*.txt のファイルが複数出力されます。

なお、グリフが割り当てられていない CID では、元フォントの CID 0 のグリフを割り当てます。

CID 0 は、.notdef のグリフです。
フォント内にグリフが存在しない時に使われる字形がセットされています。

グリフを定義せずに、空にすることもできますが、CID フォントは基本的にすべての定義グリフが埋まっているものなので、空にせずに、グリフをセットします。

mergefonts で CID フォントを出力する場合は、CFF 形式の CID フォントが作成されます。
OpenType の CFF テーブルに直接格納されるようなフォーマットとなっています。

CFF フォントには、基本的に、グリフのアウトラインデータと、最低限のフォント情報しか含まれていません。

Unicode とのマッピング情報など、実際にフォントとして使うための多くの情報が含まれないため、このままではまともに使うことはできません。
実際は、このファイルを元にして、makeotf コマンドを使って、OpenType フォントを作成する必要があります。

入力ファイルは、「マッピングファイル フォントファイル」で、２つを対にして指定するか、フォントファイルのみを指定します。
連続で複数の入力ファイルを指定できます。

フォントファイル指定の前に、マッピングファイルの指定がない場合（前のファイル名の中身の先頭が "mergefonts" ではない時）は、すべてのグリフを、同じグリフ名で、そのまま変換先にコピーします。

もし、複数の入力ファイルで、同じグリフ名にグリフがセットされるような場合は、最初に処理したグリフが優先され、後のフォントのグリフは無視されます。

今回の場合、入力フォントは一つですが、CID のフォント辞書を複数作成する必要があります。

一つのマッピングファイルには、一つのフォント辞書しか指定できないため、複数のマッピングファイルを作ってフォント辞書を指定し、入力フォントには、すべて同じファイルを指定することになります。

これらを一つ一つ手作業で入力するのは大変なので、カレントディレクトリにあるマッピングファイル (map-*.txt) と、指定フォント名を、対にして出力するシェルスクリプトを作りました。

引数でフォント名を指定すると、"マッピングファイル フォント名 ..." という文字列が出力されるので、それをコピーして使ってください。

[mapfile.sh]

#!/bin/sh

if test "$1" = "";then
    echo "need fontname"
    exit 0
fi

o=""
for f in map-*.txt;do
    o="$o $f \"$1\""
done

echo "$o"

$ sh mapfile.sh SourceHanSansJP-Regular.otf

問題なければ、指定した出力ファイル名 (out.cff) で、CFF 形式の CID フォントが出力されます。

この状態ではまだ、各 CID に対して、対応するグリフデータが割り当てられただけなので、ここからさらに、フォントの詳細な情報を設定して、OpenType フォントを作成する必要があります。