さて、いよいよ TeX Live で日本語を扱うための設定を行っていくわけですが、最初にまず、フォントに何を使うかを考えましょう。
フォントの選択をする場合には、そのフォントの適用範囲に関しても考慮する必要があります。たとえば、出版関連の仕事をされていて、モリサワパスポート等のような、膨大、かつグリフ数の充実したフォントを持っている方の場合と、我々の大多数（もちろん僕もこれに属します）のように、フォントに多額の出費をするのがはばかられるような生活をしている人では、この辺りの事情は大分変わってきます。
日本語フォントの収録文字数を知る目安が、そのフォントが Adobe-Japan 1-X のどの辺りに位置するのか、ということです。Adobe-Japan 1-X は、Adobe Systems 社が日本語組版目的に開発したコード体系で、Apple、NEC、富士通、IBM等の外字、共同通信の K-JIS や U-PRESS、写研 SK コード等にも対応しており、Unicode では区別されない異体字なども区別して、漢字を取り扱うことができます。Adobe-Japan 1-X の詳細に関しては、以下の論文を参照されることをお薦めします：
『Adobe-Japan 1-6 と Unicode—異体字処理と文字コードの現実』：安岡孝一, 情報管理 48[8] (2005), pp.487-495.この論文の著者である安岡氏は、Adobe-Japan 1 収録の漢字を異体字毎に分類した PDF ファイルを公開されています：
（PDF ファイル）
『Adobe-Japan1の漢字(部首画数順)』： http://coe21.zinbun.kyoto-u.ac.jp/~yasuoka/publications/Adobe-Japan1kanji.pdf
Adobe Reader に付属する「小塚明朝 Pr6N-Regular」「小塚ゴシック Pr6N-Medium」は、現在最も収録文字数が多い Adobe-Japan 1-6 を（ほぼ）満たしています。macOS にも付属する「ヒラギノフォント」は、リリース当初はこれに準ずる Adobe-Japan 1-5 (Pro)、もしくは Adobe-Japan 1-4 を (Std) 満たしていましたが、現在のヒラギノフォントは Adobe-Japan 1-6 準拠となっています。
これはあくまで僕の個人的印象ですが、小塚フォントにはやや癖があります。文字がぎゅっと詰め込まれているような感じがあります。しかし、決して見苦しいものではなく、むしろその癖は見出しなどにおいていいアクセントになってくれるようです。こういう印象を得ているので、僕は普段は Linux 端末上での TeX / LaTeX 使用時には小塚フォントを常用しています。
これに対してヒラギノフォントは、バランスの良さと格調高さを感じます。書体も明朝・ゴシック合わせると6書体あるので、フォントマップで場所によるフォントの使い分けも細かく設定できます。ただし、特に小さな文字を使う場合には、小塚フォントと比較するとやや線が細いという印象も受けます。僕の場合は、教育目的の文書や書類を作成する場合には、Mac OS X （諸事情から macOS ではないんです）上の TeX / LaTeX でヒラギノフォントを埋め込んだ PDF を作成し、印刷などに供しています。
フォントを使うときに注意しなければならないのが、このライセンスの問題です。フォントは一種の知的財産で、それを所有するということは、フォント供給者との間の契約条項に違反しない形態での利用権を得る、ということですから、
そんなの持ってる人の勝手でしょという理屈は通らないのです。
前述の Adobe Reader 付属の小塚フォントや、Mac OS X 付属のヒラギノフォントの場合について調べてみると、小塚フォントは「Adobe Reader を用いた日本語文書の表示・印刷」、ヒラギノフォントは「Mac OS X 上での日本語文書の表示・印刷」に、その使用範囲が限定されているようです。
特に TeX / LaTeX の場合、PDF 内にフォントを埋め込むことができますから、この使用範囲に関しては注意が必要です。フォントを埋め込んだファイルは、そのフォントがインストールされた端末上での閲覧・印刷（小塚フォントに関しては Adobe Reader による閲覧・印刷）に、その用途を限定しておくのが安全だと思われます。特に、作成した PDF を配布する場合には、この限定の範囲外となってしまう可能性があるので、配布する PDF には IPA フォント等の配布可能なフォントを埋め込むようにするか、あるいは日本語フォントを埋め込まないようにするか、いずれかの措置を講ずるのが安全だろうと思われます。
ただし、モリサワフォントに関しては、モリサワのサイトのコンテンツである『製品情報 商業利用に関して』中の Q & A に、以下のような記述があります：
これを書かれている通りに解釈するならば、モリサワのライセンスを得ている人が、フォントデータの埋め込まれた PDF ファイルを作成して公開・配布することは問題ない、ということになります。PDF へのフォント埋め込みに関してこのように明示されたのは、商用フォントではひょっとしたら初めてのことかもしれませんね。Ｑ４：モリサワフォントを使用して作成した成果物は、モリサワパスポートの契約期間終了後も使えますか？
Ａ：
モリサワフォントを使用して作成した成果物が、例えば、アウトライン化もしくは画像化されたデータまたはフォントデータが埋め込まれたデータ（PDF等）のような、機器にインストールされた当該フォントデータ無しにその表示および出力が可能な形式によるもの、または、紙もしくはフイルム等の媒体に出力された成果物である場合には、契約終了後でも使用出来ます。
契約期間中、終了後を問わず、モリサワフォントのライセンスを持たない方がその成果物を使用することも出来ます。
知的財産としてのフォントに対する弁理士の見解としては、以下の文書が、過去の経緯を含めて簡潔にまとめています：
『著作権実務ガイドライン 3 ——著作物—— フォント・タイプフェイスの保護』：丸山温道，月刊「ぱてんと」59[1] (2006年1月10日発行)，pp.24-6．特許庁の見解も以下に示しておきます：
『タイプフェイスの保護』：特許庁，（社）発明協会アジア太平洋工業所有権センター，2009．
とは言うものの、実際に、商用フォントを埋め込むことがそこまでシビアな著作権上の問題になるものなのでしょうか。また、問題にすべきものなのでしょうか。
僕の身近にいる印刷媒体の関係者（この人はイラストレーターで、文字情報の流し込みを含む組版まで込みで仕事をしています）に聞くと、即座に「アウトライン」と返ってきます。文字情報が中心でない場合には、こういう解を選択すればいいのでしょう。しかし、アウトラインをかけるということは、文字情報を失うということですから、TeX / LaTeX の文書の場合にはこれは現実的ではありません。
では、公に公開されている PDF 文書ではどのようになっているのでしょうか。たとえば、
https://www.jpo.go.jp/shiryou/toushin/chousa/pdf/zaisanken/1905typeface_all.pdfこれは、特許庁の外郭団体である一般財団法人 知的財産研究所が平成20年3月に出した「平成19年度特許庁産業財産権制度問題調査研究報告書 『タイプフェイスの保護のあり方に関する調査研究報告書』」という文書です。まさにそのものずばりの文書ですねえ。この文書を斜め読みしていると、pp.59 脚註にこのような記述を見つけました：
この記述を以て、フォント埋め込みに目くじらを立てられることはない、と断ずるのは、いささか拙速だと思います。しかし、ここで注目すべきなのは、この記述よりもむしろ、この PDF 文書で使用されているフォントに関して、です。Adobe Reader でプロパティを見ると……108 本調査研究委員会においては、上述の問題のほかに、電子文書にフォントを埋め込み、インターネット等を介して当該文書を送受信することにより、当該文書を受け取ったユーザーにおいてその埋め込まれたフォントを使用することが可能となることから、こういった行為をも問題として採り上げるべきとの指摘もあった。しかしながら、国内アンケート調査及び国内ヒアリング調査結果からは、このような問題は顕在化しなかった。
実は、世間で公開されているほとんどの PDF 文書において、このように OS にバンドルされているフォントが埋め込まれています。おそらくこれらは、フォントの商用利用までが制限されているわけではない、という判断によるものだと思います。
たしかに、紙媒体で使用したり、アウトラインをかけたかたちで利用することに関しては、たとえばヒラギノをバンドルしている Apple や、Microsoft Windows のバンドルフォントの版権を持つ Microsoft やリコー等は OK との判断をしているようです。しかし、フォントを埋め込むことは、それらと同じ商用利用の括りで同一視できるかどうか……これは、やはりグレーなところです。埋め込まれたフォントはフォントとしての電子的情報を残したかたちでファイル内に存在しているわけで、これは厳密に解釈するとファイルの複製と言えないこともないわけです。
個人的意見を述べるなら、フォントが埋め込まれた PDF からフォントファイルを生成し、不法に用いるような輩が現れない限り、フォントの埋め込みに関しては問題ないものと考えています。また、そういう行為が為されたとき、その責めを負うのが、フォントファイルを「埋め込んだ側」か、「逆生成した側か」ということを考えると、「埋め込んだ側」に責めを向けるのはいささか問題があると言わざるを得ません。ですから、僕自身は、他人に渡すことのないファイルに対しては、比較的安易にフォントの埋め込みを行っていますし、それで法的問題が生じたことはありません。
ですから、ここでは、自家用等の（二次利用でないと言い切れる使用状況下における）商用フォントの埋め込みと、著作権的にツッコまれる危険がないフォントの埋め込みの双方に関して、解説を行っていこうと思います。
2011年10月29日に、TeX Live 2011 の配布パッケージに "ipaex" がマージされました。このパッケージに収録されているファイルを以下に示します。
その後、これらのフォントマップは更に種類を増やし、また、便利な設定用スクリプトも収録されるようになりました。ここではそれらを使ったフォントマップの設定方法と、オリジナルのフォントマップを書き、使う手順について示していきましょう。
まず、日本語フォントが使えるようなセットアップを行っていきましょう。まず、TeX Live のインストールディレクトリを見てみます。
$ ls -l /usr/local/texliveとすると、TeX Live 2021 が入っている 2021 というディレクトリと共に、texmf-local というディレクトリがあるのがお分かりでしょうか。
google などでネット上のコンテンツを探すと、TeX Live の改変を行うのに、/usr/local/texlive/2021 内のファイルを直接書き換えている例を散見します。しかし、先に書いた通り、TeX Live は tlmgr というユーティリティでオンラインアップデートをかけることができます。このアップデートが、改変したファイルに対して適用されると、そのファイルの改変部は消えてしまうことになります。また、TeX Live 2022 が出たときに、ここでこれから行うような改変を改めてやり直す、というのは、あまり効率のいい話ではありません。
こういう場合のために、TeX Live では /usr/local/texlive/texmf-local というディレクトリが用意されています。この中に追加する部分を構成しておけば、アップデート時に消えてしまうことや、次年度の TeX Live に改めて改変しなければならないような状況を回避することができます。
また、TeX Live の新しい年度のリリース直後にしばしばあることなのですが、tlmgr によるシステム更新が上手くいかず、それ以降の更新が滞ったままになる場合があります。もちろん、原因をきちんと究明する（そしてそれを開発者にフィードバックする）のがベストなのは言うまでもありませんが、texmf-local を有効に活用している場合には、/usr/local/texlive/texmf-local/ をそのままにして /usr/local/texlive/2021 をばっさり消去→再インストール→システム更新、という緊急措置を講ずることができます。これはあくまで副次的効果と言えるでしょうけれど、時間がないときにトラブルが発生した場合などに、こういうことができると助かるものです……
フォントのインストール先は、
/usr/local/texlive/texmf-local/fonts/です。僕の場合は、
/usr/local/texlive/texmf-local/fonts/opentype/public/kozuka/というディレクトリを作成し、この中に小塚フォントのシンボリックリンクを張っています。
小塚フォントは、僕のシステムの場合は、
/usr/lib/Adobe/Reader9/Resource/CIDFont/KozGoPr6N-Medium.otfの二つです。ですから、
/usr/lib/Adobe/Reader9/Resource/CIDFont/KozMinPr6N-Regular.otf
のようにして、リンクを作成しておきます。$ sudo mkdir -p /usr/local/texlive/texmf-local/fonts/opentype/public/kozuka/ $ cd /usr/local/texlive/texmf-local/fonts/opentype/public/kozuka/ $ sudo ln -fs /usr/lib/Adobe/Reader9/Resource/CIDFont/Koz*.otf ./
尚、Linux 版の Adobe Reader のパッケージには、どういうわけか KozGoPr6N-Medium.otf が入っていません。通常の Adobe Reader の使用時にですら、これが原因で、ゴシックが指定された文字列の表示がおかしくなることがあるので、僕は暫定的に同じ端末の Windows 版 Adobe Reader に添付される KozGoPr6N-Medium.otf を /usr/lib/Adobe/Reader9/Resource/CIDFont/ にリンクして使用しています。
許諾条項的にグレーなんじゃないか、という話もあるんですが、これで訴えられるんだったら訴えてみろやゴルァ……という感じですね。だって、小塚ゴシックが入っていないせいで、見出しが明朝になるだけならばまだしも、ゴシックの文字列が「・」の集合体になったりするし、これが先の小塚ゴシックのコピーでピタリと治まる、ということは、明らかに Linux 版の Adobe Reader が KozGoPr6N-Medium.otf の存在を前提にしている、ということでしょうから。
（これは Mac OS X 端末での話です。ヒラギノを購入された方の参考にはなると思います）
/usr/local/texlive/texmf-local/fonts/opentype/public/hiragino/というディレクトリを作成し、この中にヒラギノフォントのシンボリックリンクを張っています。
ヒラギノフォントの場合に注意しなければならないのは、元々のフォントファイルが日本語のファイル名になっていることです。そのままリンクを張ると、後々フォントマップの作成等で面倒なことになるので、
のように、英字のファイル名にしてリンクしておきます。$ sudo mkdir -p /usr/local/texlive/texmf-local/fonts/opentype/public/hiragino/ $ cd /usr/local/texlive/texmf-local/fonts/opentype/public/hiragino/ $ sudo ln -fs "/Library/Fonts/ヒラギノ明朝 Pro W3.otf" ./HiraMinPro-W3.otf $ sudo ln -fs "/Library/Fonts/ヒラギノ明朝 Pro W6.otf" ./HiraMinPro-W6.otf $ sudo ln -fs "/Library/Fonts/ヒラギノ丸ゴ Pro W4.otf" ./HiraMaruPro-W4.otf $ sudo ln -fs "/Library/Fonts/ヒラギノ角ゴ Pro W3.otf" ./HiraKakuPro-W3.otf $ sudo ln -fs "/Library/Fonts/ヒラギノ角ゴ Pro W6.otf" ./HiraKakuPro-W6.otf $ sudo ln -fs "/Library/Fonts/ヒラギノ角ゴ Std W8.otf" ./HiraKakuStd-W8.otf
上記以外のフォントを使用されたい場合も、/usr/local/texlive/texmf-local/fonts/ 以下にシンボリックリンク、もしくはフォントファイルを配置し、適切なフォントマップを用意して ls-R データベースを更新すれば、使用することができます。フォントは TrueType フォントも OpenType フォントも使用できますが、/usr/local/texlive/texmf-local/fonts/truetype と /usr/local/texlive/texmf-local/fonts/opentype というサブディレクトリを切って、その中に配置するといいでしょう（上の小塚フォント・ヒラギノフォントの場合はそうしています）。
TeX / LaTeX ではおなじみの、ls-R データベースの更新をしておきます。
$ sudo mktexlsrもしくは、
$ sudo texhashとすることで、ls-R データベースが更新されます。更新時のメッセージをよく見ていると、texmf-local 内にもちゃんとデータベースが作成・更新されていることが分かります。
フォントの設定、というからには、フォントを使うユーティリティがあって、それがこちらの希望のフォントを扱えるように設定する、ということでしょう。ところが、困ったことに、TeX / LaTeX 上でフォントを扱うソフトはひとつではありません。単純に DVI ファイルを処理するものを挙げても、
この問題を解消するには、いくつかのフォントを扱うソフトに対して統一的に設定を行えるソフトが必要になるわけですが、まさに updmap というソフトがそれにあたります。
updmap に関しては、『美文書作成入門』の c.5 updmap (pp.325) にシンプルな解説がありますので、ここではごく簡単に補足をしておきます。
updmap は、dvips あるいは dvipdfmx 用に書かれたフォントマップを読み込み、それを反映させるかたちで、フォントを扱う種々のソフトに対する設定を行うことができます。ただし、updmap で設定した内容は ~/.texlive2021 以下に保持されます。つまり、updmap で設定した内容は、ユーザ個人にしか反映されません。
システム全体の設定を行うためには、updmap-sys を使用します。updmap-sys の使い方は updmap と全く同じですが、設定内容は TeX Live のシステムそれ自体に反映されます。
これらの設定の詳細に関しては以下のようなドキュメントが公開中されています：
"updmap and kanji embedding": http://tug.org/texlive/updmap-kanji.html体系的、かつ実践的にまとめられていますので、英語はちょっと……という方も、じっくり目を通されることをお薦めします。
実は、現行の TeX Live には updmap-sys のラッパーである perl スクリプト kanji-config-updmap(-sys)（当初は updmap-setup-kanji(-sys) という名称でした）が収録されています。これを使用すると、オプション等でミスをすることなしに、システムのデフォルトフォントセットを設定することができます。
kanji-config-updmap(-sys) は、システムに収録されている "otf-" から始まる名前のフォントマップを読み込み、これをシステムのデフォルトセットとして登録することができます。詳細は、
のサブディレクトリを御参照下さい。/usr/local/texlive/2021/texmf-dist/fonts/map/dvipdfmx/ptex-fontmaps
これらの中からひとつを選択して、設定を行うわけですが、たとえばここでは otf-ipaex.map をデフォルトにするように設定してみましょう。設定は非常に簡単で、
と入力するだけです。フォントセットの名前は、頭の "otf-" を取った残りの部分を（拡張子を付けずに）指定します。$ kanji-config-updmap ipaex
コマンドを実行すると、ずらずらーっとメッセージが出てきますけれど、その中に、
というメッセージが出ています。このように、漢字の埋め込み用フォントが ipaex に設定されているわけです。kanjiEmbed replacement string : ipaex (/home/foo/.texlive2021/texmf-config/web2c/updmap.cfg)
kanjiVariant replacement string : (/home/foo/.texlive2021/texmf-config/web2c/updmap.cfg)
次に、埋め込みをやめたい場合はどうするか、というと、
と入力します。こうすると、otf-noEmbed.map の内容が反映され、$ kanji-config-updmap noEmbed
のように、日本語フォントの埋め込みを行わないようにセッティングされます。kanjiEmbed replacement string : noEmbed (/home/foo/.texlive2021/texmf-config/web2c/updmap.cfg)
kanjiVariant replacement string : (/home/foo/.texlive2021/texmf-config/web2c/updmap.cfg)
updmap 同様、kanji-config-updmap も、設定した内容はユーザ個人にしか反映されません。システム全体の設定を行うためには、kanji-config-updmap-sys を使用します。kanji-config-updmap-sys の使い方は kanji-config-updmap と全く同じですが、設定内容は TeX Live のシステムそれ自体に反映されます。
フォントマップに関しては『美文書作成入門』の第13章にも説明がありますので、ここではふれません。前述のとおり、TeX Live 収録のフォントマップも充実しているので、新たにフォントマップを書く必要性はどんどん低くなっている状況です。ただし、後にふれるような理由で、自分でフォントマップを作成したい、という方もおられるかもしれませんので、ここでは僕が以前使っていた4種類のフォントマップにリンクしておきます。
埋め込みなしのフォントマップは、ptexlive のフォントマップを流用させていただいています。それ以外のフォントマップは『美文書作成入門』 pp.238-241 の記述を参考に作成しました。これらの4種類のフォントマップは OTF パッケージにも対応した内容にしてあります。上記4ファイルはいずれも dvipdfmx 用に書いていますので、
というディレクトリを作成して、このディレクトリ内にフォントマップを配置します。$ sudo mkdir -p /usr/local/texlive/texmf-local/fonts/map/dvipdfmx/
上にリンクしたフォントファイルを、僕は結構長い間使っていました。というのも、当初 TeX Live にはこのようなフォントマップは収録されておらず、収録開始後も、フォントマップに /AJ16 オプションが付与されていない、等の不備があったためなのですが、現在ではそのような不具合もほぼ皆無なので、japanese-otf や jfontmaps に添付されるフォントマップを先のような方法で指定して使っています。
そういうわけで、現在はあまりこのような使い方をされる方も多くないかもしれませんが、ここではフォントマップを明示的に指定して、DVI ファイルを処理する手順を書いておきます。一般的な TeX / LaTeX の処理に関しては、『美文書作成入門』等を御参照いただければよろしいかと思いますが、上記のようなフォントマップを使用する場合でも、そのプロセスは基本的には変わりません。
で、foo.tex から foo.dvi が作成されます。問題は、この DVI ファイルから最終的な出力ファイルを得るプロセスですが、ここでは例えば、$ platex foo.tex
のように、明示的にフォントマップを指定して dvipdfmx を起動します。そうすると、$ dvipdfmx -f hiraginoEmbed.map foo.dvi
のようにメッセージが出て、foo.pdf が生成されます。$ dvipdfmx -f hiraginoEmbed.map foo.dvi foo.dvi -> foo.pdf [1][2][3][4][5][6][7][8][9] 231096 bytes written