Hatena::ブログ(Diary)

アセトアミノフェンの気ままな日常

2015-10-04

TeX で OpenType Collection フォントを扱ってみると(その2)

昨日の記事

幸い OTC フォントでもこの方法が使えたので、マッピングさえ誤らなければ pTeX / upTeX + dvipdfmx で日本語 PDF を出力することができる

と書いた。しかし、これは考えてみれば不思議である。だって「未知のフォント形式に偶然対応していた!」なんてことがあるわけがない! というわけでちょっと調べてみた。

pTeX / upTeX + dvipdfmx の場合(続き)

dvipdfmx が知らない間に OTC に対応していたのはなぜか? その答えは

である。XeTeX というエンジンは、見かけ上 TeX ソースから直接 PDF を出力するが、実は XDV という DVI の拡張形式のファイルから xdvipdfmx を使って PDF を出力している。この xdvipdfmx こそが dvipdfmx の拡張版なので、xdvipdfmx は pTeX / upTeX で使われる dvipdfmx と同一ソースを共有して一体になって開発されている。そこで、調べてみると TeX Live のメーリングリスト(ここここ)が見つかり、r37053r37054 で「CFF な TTC」すなわち OTC をサポートする修正がなされたことがわかる。これは2015年4月26日の変更で、バイナリが更新されたのは TeX Live 2015 以降ということになる。

XeLaTeX + xdvipdfmx では?

実際に以下のソースを XeLaTeX (+ xdvipdfmx) でタイプセットしてみよう。

\documentclass{bxjsarticle}
\usepackage{fontspec}
\setmainfont{SourceHanCodeJP-Regular}
\begin{document}
これは源ノ角ゴシックCode JP Rです。
\end{document}

すると、TL2015 では正常終了*1するのに対し、TL2014 では

xdvipdfmx:fatal sfnt: table not found

というエラーを吐く(ソース中で敢えて PostScript Name にしてあるのは、TL2014 ではスペースを含むフォント名が禁止だったため)。

これと同じような現象が pLaTeX + dvipdfmx でも起こり、実際にヒラギノフォントを TeX Live 2014 以下の環境で(jfontmaps と OTC へのシンボリックリンクの新規作成を行ったうえで)埋め込もうとすると同じく

dvipdfmx:fatal sfnt: table not found

というエラーが出て失敗する。Source Han Code JP で似た状況を再現したい場合は以下のソースを upLaTeX + dvipdfmx でタイプセットすればよい。

\documentclass[uplatex]{jsarticle}
\AtBeginDvi{\special{pdf:mapline uprml-h unicode :3:SourceHanCodeJP.ttc}}
\begin{document}
これは源ノ角ゴシックCode JP Rです。
\end{document}

Adobe-Identity-0 なフォントで ToUnicode が働くようになったのは TL2015 以降なのでかなり最近であるのはさておき、埋め込み以前の問題で TL2014 はエラー終了となる(なお、TL2015 では正常終了するが PDF 自体が文字化けしてしまった…*2)。

続く

*1:ただし PDF での文字表示は正常だがコピペが文字化けする。ToUnicode の補完ができていないようである。

*2:mapline に unicode の代わりに UniSourceHanCodeJPR-UTF16-H を ZR さんによる zrmakecmap.lua で作成して指定する方法でもダメだった。游明朝Source Han Sans の OTC は正常に埋め込めるそうだが、何かまちがったかな…

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証