(前回の続き)
実は以下の資料・文献の中に答えが含まれている。(dviout のインストール先ディレクトリを $DVIOUT であらわす。)
- $DVIOUT/map/ttfonts.map の冒頭にあるコメントおよびそこで直接(
%input
を介してでなく)定義されたマップ行。 - $DVIOUT/FONT/winttf.lzh に含まれる「TTNFSS パッケージ」。
- そして、トニイ氏のサイトの「TeX Q and A」のページの末尾にある「dviout for Windows がフォントを表示する仕組み」の文書。1 と 2 についての解説もこの文書にあるので、要するにこれを読めばよい。
この中の 2.2.2 節に「通常の Windows 欧文 TrueType フォントを TeX で使う方法」が述べられているが、これが探し求めていた「想定の方法」であると確信している。結果的には前回に述べた「1. VF 利用」に相当する訳だが、もっと深い事情がある。
TeX の欧文フォントの扱いに詳しい人なら、LaTeX 標準の PSNFSS バンドル(helvet パッケージ等)における TFM の構成について知っているであろう。すなわち、Times-Roman 等の Type1 フォントを「TeXBase1 エンコーディング(8r エンコーディング*1)」で再エンコードした TFM (ptmr8r)を生成し、LaTeX で用いる OT1(ptmr7t)、T1(ptmr8t)等のエンコーディングの TFM は 8r の TFM を参照する VF として実現する、というものである。これの詳細については、件の質問スレッドの中で挙げられている ut 氏の「LaTeX のフォントの話」を参照されたい。*2以下では、「TeXBase1」を介した設定方法を知っているという前提で話を進める。
そういう前提で、2.2.2 節の説明を読むと、まさにその「TeXBase1(8r)の原エンコーディングの TFM を介在させて T1(8t)の LaTeX エンコーディングの TFM を VF として構成する」手順を述べているように見える。($DVIOUT/map/ttfonts.map のコメントについても同様である。)しかし、細部(特に脚注)まで見てみると、何やら様子が異なることが判る。例えば、本文で「Windows のエンコーディング “8r” に変換します」とあり、そこに付された脚注には
“8r” の “8” は 8bit を表し、 “r” は “raw” を表します。raw(無加工)とは、この場合 TTNFSS の ‘win8r.enc’ で定義されている Windows のエンコーディングを表します。PSNFSS の文脈では、Adobe のエンコーディングを指すことが多いです。
とある。つまり、TTNFSS パッケージに含まれる TFM の「8r」は本当は「8r (= TeXBase1 *3)」ではなく Windows-1252 のことを最初から意図しているという意外な事実が判る。*4さらに、件の TTNFSS パッケージ($DVIOUT/FONT/winttf.lzh の中身)の texmf/tex/latex/ttnfss/winenc.sty を見ると、更なる驚愕の事実を目の当たりにすることになる。
\DeclareTextSymbol{\textyen}{T1}{'203} \DeclareTextSymbol{\textcopyright}{T1}{'207} \DeclareTextSymbol{\textregistered}{T1}{'206} \DeclareTextSymbol{\P}{T1}{'211} \DeclareTextSymbol{\textbullet}{T1}{'215}
なんと、T1 エンコーディングの定義を改変している!((\textyen
、\textcopyright
、\textregistered
等の「Latin-1 の記号」の多くは T1 でなく TS1 の方に含まれているのであった。))
何故、dviout の開発者はこんな極度に強引とも思える方法を採っているのだろうか。*5例の 2.2.2 節の内容を熟読すると、その意図の一端が感じ取れる気がする。恐らくはこんなことなのであろう。
「Windows + TrueType フォントの世界」では「Postscript + Type1 フォントの世界」とは異なる「常識」があるはずで、それならば dviout + TTNFSS は dvips + PSNFSS の方法論を盲従するのでなく、「Windows の常識」に従った方法論を模索するべきである。*6
こう考えると、「8r」や「T1」等の「エンコーディング名の濫用」もその意図を納得できる(容認するかは別の問題だが)。*7
さらには、前回の「可能な方法」の議論の「1. VF 利用」(結果的にこれが正解なのであるが)に書いた次の「不可解な点」も払拭できる。
ただ、この方法は「dviout のための特別な方法」という印象が強い。確かに、この方法で設定したものは他の DVI ウェアでも通用するのであるが、他の DVI ウェアでは全く一般的でない方法(と私はこでまで認識していた)なので、「dviout のためにわざわざ変な方法を採っている」という印象を持っていたのである。
つまり、dviout は敢えて dvips と異なる方法―Postscript の方法―を採ったのであり、その後に登場した DVI ウェアは dvips を踏襲したので、そちらの方法に慣れた視点から見ると dviout が特異に見えるわけだが、果たしてそれも意図されたことであり、「全部同じ方法が採れるべきだ」という考え自体が否定されるべきものであったということである。
ただし、正直なところ、私はこの「思想」に賛成する者ではない。現状の TeX システムの構成は「DVI ウェアの間の差異を軽減する」方向に向かっているし、また実際に DVI ウェアごとに別の手順を採るのは面倒だから、結局「故意に別の方法をとる」のは受け入れ難い。そもそも dviout しか使わないのであれば、「dviout 流」を進むのもいいだろうが、恐らくは dviout のユーザの多くが、PDF 文書を得るために dvipdfmx を併用しているのではないか。そうすると、結局は多数派である「Postscript 流」に従うしかないのではないかと思う。従って、私が自作パッケージで dviout をサポートする場合には、これからも「4. ttf2pk を使う」或いは「2. Unicode SFD + VF」の方法を採ることになるだろう。*8
積年の疑問を解決する手がかりを頂いた 山本和義 氏と ut 氏に深く感謝したい。
そして、最近公開された ut 氏による解説資料を改めて紹介したい。
以前に紹介した eggtoothcroc 氏の資料および私のブログ記事と比べると、かなり体系的に説明されていて、この類の話を「整理した形で」身につけたい人に適していると思う。
(でもまだ続く)
*1:Berry 命名規則での識別子が 8r だからこの別名がある。直接 LaTeX で使うエンコーディングでないので NFSS 名はない。
*2:なお、この構成方法は現在でも用いられるとは思うが、「OpenType する件」では敢えて取り上げなかった。一番の理由は、「それを行う必然性がないから」で、ただでさえ複雑な概念理解をさらに無益に複雑化すると判断したからである。
*3:fontname パッケージを見る限り、8r は TeXBase1 という特定のエンコーディングを指すことで間違いないようだ。
*4:なお、当該の文中にある「PSNFSS の文脈の 8r」は当然 TeXBase1 を指すと思われるが、これは「Adobe のエンコーディング」ではなく TeX コミュニティが策定したものである。恐らくは AdobeStandard エンコーディング(Berry 名識別子 8a; 8r に再エンコードする前の Type1 フォントの既定のエンコーディングは多くの場合これである)と混同していると思われる。
*5:TeX の初級者が強引で破壊的な方法を使うことは多いが、もちろん dviout の開発者は決して TeX の初級者ではない。
*6:TTNFSS の開発が始まったであろう 15〜20 年前の状況を前提にしている。
*7:なお、件の質問スレッドの中での議論の中で、私は、「Windows-1252 を近似的に TeXBase1 と見做して処理しようとしているのでないか」という推測を述べた。実際、TeXBase1 自体が Windows-1252 と互換になるように設計されている(8r.enc のコメントを見れば判る)のでこの 2 つは非常に似ている。しかしその後に山本和義 氏から「TTNFSS の 8r は TeXBase1 を意図したものでない」ことの指摘があった。「表示する仕組み」の資料を見れば、この推測は的外れであったことが解る。T1 エンコーディングについても、実際には少し相違があるものを T1 だと思う(そこから生じる齟齬には目をつぶる)ことはよく行われるが、わざわざ T1 の定義の改変まで行っていることを見ると、「TTNFSS 流の T1」―TTNFSS の仕様は dviout のそれに直結しているので「dviout 流の T1」といってもよい気がする―を「正なもの」として認めていたことが推定できる。