データベースのかきかた:
- 【必須】Name エントリには「TEXMFLOCAL に作りたい symlink 名(dvipdfmx 用 map などにある名称)」を書く。
- PSName エントリは、Name エントリの内容と実フォントの PostScript Name が異なる場合に書く。
- 【必須】Class エントリは Adobe-ナントカ1-[Supplement] の「ナントカ」を書く(Japan / GB / CNS / Korea)。
- Provides エントリは、当該の実フォントを代表的な PostScript 標準フォントへのエイリアスに採用したい場合に書く。
- 複数の実フォントに対して同じエイリアスが考えられる場合は、Provides(数値) と書いておくと、数値の小さいものが優先される。
- 【必須】Filename エントリは候補となるファイル名を書く。
- ファイル名が複数ありうる場合は Filename(数値) と書いて列挙しておくと、数値の小さいものが優先される。
symlink / snippet のつくりかた:
- Name / Class / Filename が最低限そろっていることを確認して処理開始。
- フォントデータベースをパースし、内部的に一旦保存する。
- 個別フォントのインデックスは PSName エントリ(なければ Name エントリを流用)
- 以下これは realfontname と呼ばれる
- 特定のフォントに対しては、以下の項目を取得する:
- origname = Name エントリ(つまり TEXMFLOCAL に作りたい symlink 名)
- class = Class エントリ
- files = Filename すべて
- provides = Provides すべて
- 個別フォントのインデックスは PSName エントリ(なければ Name エントリを流用)
- files のリストをすべて kpathsea で探索
- 内部的にデータベースに追記
- target = 見つかった実ファイルの場所
- 内部的にデータベースに追記
- 見つかったファイルに対して実際の処理
- gs の Resource/CIDFont に symlink を張る (realfontname => target)
- gs の Resource/Font に realfontname-encoding というファイル名の snippet を多数作成
- 中身は realfontname と encoding を使って書かれる
- 当該フォントが最優先の provides ならば、gs の Resource/Font にエイリアス用 snippet も作成
- 中身は realfontname と encoding を使って書かれる
- TEXMFLOCAL に symlink を張る (origname.otf => target)
データベースのかきかた:
- 【必須】Name エントリには実フォントの PostScript Name を書く。
- このため PSName エントリはそもそも要らないし使われない。
- 【必須】Class エントリは Adobe-ナントカ1-[Supplement] の「ナントカ」を書く(Japan / GB / CNS / Korea)。
- Provides エントリは、当該の実フォントを代表的な PostScript 標準フォントへのエイリアスに採用したい場合に書く。
- 複数の実フォントに対して同じエイリアスが考えられる場合は、Provides(数値) と書いておくと、数値の小さいものが優先される。
- 【必須】Filename エントリは候補となるファイル名を書く。
- ファイル名が複数ありうる場合は Filename(数値) と書いて列挙しておくと、数値の小さいものが優先される。
- 最も小さい数値を持つファイル名がそのまま TEXMFLOCAL の symlink 名に採用される。
- したがって、TEXMFLOCAL に PostScript Name な symlink を作りたい場合は敢えて最小の値を与えて登録しておく。
symlink / snippet のつくりかた:
- Name / Class / Filename が最低限そろっていることを確認して処理開始。
- フォントデータベースをパースし、内部的に一旦保存する。
- 個別フォントのインデックスは(そもそも PSName エントリがないので)自動的に Name エントリ
- 以下これは realfontname と呼ばれる
- 特定のフォントに対しては、以下の項目を取得する:
- origname = Name エントリ(つまり PostScript Name)
- class = Class エントリ
- files = Filename すべて
- provides = Provides すべて
- ttfname = 最小の数値を持つ Filename エントリ(拡張子 .ttf 込み)
- 個別フォントのインデックスは(そもそも PSName エントリがないので)自動的に Name エントリ
- files のリストをすべて kpathsea で探索
- 内部的にデータベースに追記
- target = 見つかった実ファイルの場所
- 内部的にデータベースに追記
- 見つかったファイルに対して実際の処理
- gs の Resource/CIDSubst に symlink を張る (ttfname => target)
- gs の Resource/Font に realfontname-encoding というファイル名の snippet を多数作成
- 中身は realfontname と encoding を使って書かれる
- 当該フォントが最優先の provides ならば、gs の Resource/Font にエイリアス用 snippet も作成
- 中身は realfontname と encoding を使って書かれる
- TEXMFLOCAL に symlink を張る (ttfname => target)
より詳しく具体例で上の問題を説明する。
cjk-gs-integrate の database を parse するコードを、全体的に書き直しました。今までのコードには、以下の問題がありました。
[1] OTC と TTC が区別できない。たとえば、database が以下の内容だとします。
スクリプトを OS X Yosemite で実行すると、コンピュータから「ヒラギノ明朝 ProN W3.otf」と「ipaexm.ttf」が見つかります。この場合、Ryumin-Light の alias は「HiraMinProN-W3」になるので gs は ok です。
しかし、スクリプトを OS X El Capitan で実行すると、コンピュータから「ヒラギノ明朝 ProN W3.ttc」と「ipaexm.ttf」が見つかります。この場合、Ryumin-Light の alias は「HiraginoSerif-W3.ttc」になりますが、gs は OpenType Collection (OTC) を使えないのでよくないです。だから、OTC の場合は alias を決めるときに無視するほうがよいです。
[2] symlink が .ttc → .ttf に張られる場合がある。たとえば、database が下のようになっているとき
コンピュータに YuGothR.ttc だけが見つかると、symlink は yugothic.ttf => YuGothR.ttc になります。このような TTF → TTC の symlink ができるのはよくないです。
この問題を解決するために、スクリプトを書き直しました。
[1] database の
Filename:
entry を廃止(backward compatibility のため、database を parse する関数はFilename:
entry を解釈できるように残す)。新しくOTFname:
OTCname:
TTCname:
TTFname:
のどれかを使う。[2] priority number で symlink を決めるとき、TTF / TTC / OTC の名前を別々に save する。複数見つかったら、その中でいちばん小さな priority number の type で決められた symlink の名前を使う。
[3] OTC フォントの場合は、gs の Resource に何も作らない(単にスキップする)。alias を決めるときもスキップする。