platex の日本語フォントの問題

2012/03/04
2012/03/14 改訂
2012/03/17 改訂
2012/03/28 追加

この春休みはフォント問題と格闘していた。 来年度の講義の準備のために Python のテキストを改訂した。その過程でフォント問題に時間が取られた。これまでのテキストは pLaTex で書かれていた。そのために今回も pLaTex であるが、前回(第5版)と今回(第6版)では僕の環境が変わっている。その間に、ハードウェアの変化、OSX のバージョンの変化、それから配布されている pLaTex の変化がある。 pLaTex は、前回は teTeX で配布されていたが、今回は TeXLive2011 である。要するに再出発である。

前回のテキストでは bf にはヒラギノ角ゴの W6 フォントが使われていた。ところが、今回はどうした訳か、ヒラギノ角ゴの W3 フォントになっており、全然目立たない。W6 に変更したいのだが、やり方を忘れてしまっており、時間を取られた。そこで、メモをとっておく。

コマンドでは

platex と dvipdfmx を組み合わせた新たなコマンドを作る。ここでは xplatex とする。

~/bin/xplatex

注意: PATH と chmod を忘れるな

TeXShop の設定

TexShop.app を使う場合
「内部設定」→「TeX + dvips + distiller」→ 「Latex」 で

texmfの設定

/usr/local/texlive/2011/texmf/dvipdfmx/dvipdfmx.cfg


最後の方にある。もう設定済みかも...

/usr/local/texlive/2011/texmf/fonts/map/dvipdfmx/cid-x.map


初期設定は。コメント(%)で潰してある。 この書き方のサンプルは、
/usr/local/texlive/2011/texmf/fonts/map/dvipdfmx/ptex-hiragino.map
を見れば分かる。

なお、rml,rmlv,gbm,gbmvは platex が使用するメタフォント名である。uplatex の場合には、urml,urmlv,ugbm,ugbmvのように、uが先頭に付く。HとかVとかは horizontal と vertical の意味であろう。

kpsewhich

TeXは ls-Rを通じてフォント関係のファイルの場所を見つける。kpsewhich が今も使われているとすれば

以下の説明では /usr/local/texlive/2011$TEXRT で表す。 $TEXRT は Mac の TeXLive が TeXLive 2011 をインストールした場所である。

この書き方で言えば、kpsewhich は ls-R の場所を

  $TEXRT/texmf-config
  $TEXRT/texmf-var
  $TEXRT/texmf
  $TEXRT/texmf-local
  $TEXRT/texmf-dist
の順に探す。そして platex も kpsewhich の案内に従って cid-x.mapを探索し、見つかり次第、そこに書かれている設定を採用すると思える。そうだとすれば、$TEXRT/texmf下で設定を変更する必要はなく、もっと適切な変更方法があるかも知れない。

注意: システムファイルだけが表示されているのは変なので、僕の設定にまだ問題があるのだろう。

mktexlsr

今回、頭の中が ????? になったのは、 /usr/local/texlive/2011/texmf/fonts/opentype
HiraKakuPro-W6.otf が含まれていたので、lr-R に反映されているだろうと思い込んでいたからである。ところが実際は違っていた。

を実行して、ようやく生成された PDF がヒラギノ角ゴ-W6 になった。めでたし、めでたし。でも疲れた。

その他

使用されたフォントの確認

生成された PDF ファイルにどのようなフォントが使用されたかは Adobe Reader を使えば分かる。
ファイル → プロパティ → フォント

SpotLightとmdfind

Mac の SpotLight は Mac のコマンド mdfind の初心者用インターフェースである。文字列を与えて、その文字列がファイルの内容やファイルの名前に含まれるファイルの場所の探索に使われる。殆ど一瞬のうちに結果が出るのですばらしい。

使い心地は mdfind の方が、僕には良い。GUI は、見た目には良いが、実際には使い心地は良いとは言えない。

mdfind の出力は grep でフィルタリングして使うと、さらに快適である。例えば cid-x.mapをファイル名として含むファイルの一覧を知りたい時には

  mdfind cid-x.map | grep cid-x.map
で得られる注1。 grep の「.」は任意の1文字を表すので、過剰に得られる可能性を否定できないが、実際上は問題はないだろう。

mdfind で出力されたファイルの中の cid-x.map が含まれている行の内容は

  grep cid-x.map `mdfind cid-x.map`
で得られる。 こうして大雑把なフィルタリングを行った上で、エディタでファイルの内容を実際に確認すれば効率が上がる。

SpotLight も mdfind も、頼りすぎると落とし穴に陥り、そのために、問題解決の方向を見失う。これらはインデックスされたメタデータを探索するので、インデックスされていないファイルは表示されない。この事は実験的に簡単に確認できる。 例えば、新たに生成された、真新しいファイルを探索してみればよい。表示されないはずである。

注1: 2012/03/28
  mdfind -name cid-x.map
でも OK.