dviout の欧文フォントの話

TeX Forum での話題 に余計な口を挟まさせていただいたお蔭で、これまで避けて通っていた dviout における欧文フォントの扱いが少しだけ分かったような気がしますので、自分でも簡単にまとめておこうと思います。

その前に、まずは、ZR さんのまとめをご紹介しておかないといけません:

※ このページでは具体的な設定には触れませんので、実際の作業手順については ZR さんのページをご参照ください.

さて。

TeX Forum での 山本和義さん と ZR さんによるご説明と、上掲の ZR さんの記事を読みますと、dviout で一般の欧文フォント、特に TrueType フォントを使おうとすると、以下の方針が考えられます:

  1. TTNFSS 方式に準じる (vf を使って dviout-T1 を dviout-8r に帰着させる)
  2. vf を使って、LY1 エンコーディング (8y) を Windows1252 (8w) に帰着させる
  3. サブフォントの仕組みを応用する (ZR さんおっしゃるところの裏技)

I. 〜 III. いずれについても、既に ZR さんが解説をなさってらっしゃるのですけれど、ここで再度同じ話題を取り上げるのは、I. について、ほんのちょっとだけ ZR さんと違う解釈をしているからです。 II. と III. については、簡単にコメントをするだけにします。

I. TTNFSS方式を使う

TTNFSS のやり方について、ZR さんは、“謎が解けた! (2) ” において、

「Windows + TrueType フォントの世界」 では 「Postscript + Type1 フォントの世界」 とは異なる 「常識」 があるはずで、それならば dviout + TTNFSS は dvips + PSNFSS の方法論を盲従するのでなく、「Windows の常識」 に従った方法論を模索するべきである。

と乙部先生が考えられたのではないか、と推測してらっしゃいます。

それに対して、以下は、私が理解した範囲での TTNFSS による欧文 TrueType フォントのエンコーディングの扱いです。

dviout では、map ファイルで enc ファイルを使って実フォントを reencoding するということが出来るようになっていないようで、そのため、サブフォントを使う方法をとらない限りは、アクセス出来るグリフは Windows CP 1252 の 0x20 0xFF の範囲ということになるようです。つまり、以下のようなグリフ群です:

※ この table では 0x8E0x9E に Zcaron と zcaron が入っていますが、TTNFSS が作られた頃には、この 2 つのグリフはまだ CP1252 には入っていなかったらしいです.あと、glyph table のデザインは ZR さんの真似 です.

TTNFSS ではこの Windows CP1252 を疑似的に 8r エンコーディングと呼んでいます:

table の中のグレーのグリフは、T1 エンコーディングとコードが同じグリフで、青いグリフは、T1 に含まれているけれどコードが異なるグリフ、そして赤いグリフは T1 には含まれていないグリフを表わしています (Zcaron/zcaron と SHY は抜いてあります)。TTNFSS では、vf を介して、疑似的な T1 エンコーディングを、この疑似的 8r エンコーディングに帰着させています。

TTNFSS の疑似的 T1 エンコーディングは、以下のような配置になっています:

黒いグリフは疑似的 8r とコードが一致している T1 のグリフで、青いグリフは疑似的 8r とコードが異なる T1 のグリフ、そして、赤いグリフは、疑似的 8r には含まれているけれど、本来 T1 には入っていないグリフです。

この疑似的 T1 で、本来の T1 の 0x800xBF の範囲と合致するグリフは ScaronYdieresissectionscaronydieresisexclamdownquestiondownsterling の 8 個のみとなっています。本来の T1 の 0x800x8F0xA00xAF に相当するグリフは疑似的 8r には含まれていないので、飽くまで T1 に揃えようとすると、ここのスロットが丸々空いてしまいます。

他方で、本来の T1 に含まれていないからといって、せっかくアクセス出来る赤いグリフ 31 個を捨ててしまうのは、ちょっともったいない気がします。それで、疑似的 T1 の 0x800x8E 0xA00xAF のスロットに、これらの赤いグリフをキレイに並べて入れてある、ということなのではないでしょうか。

なお、この疑似的 T1 で入力するには、fontenc パッケージで T1 を指定、というわけにはいきませんので、TTNFSS では別途 “winenc.sty” が用意されています。

一般の欧文 TrueType フォントを利用する際に TTNFSS 方式を採用する場合には、win8r.encECwin.encwinenc.sty が必要となりますが、winenc.sty は TTNFSS に同梱されており、win8r.enc と ECwin.enc は、乙部先生のページの、「生成キット」 というアーカイブの中に入っています。

また、ZR さんが CP1252 から Zcaron や SHY を抜いたり winenc.sty を参照したりして再現された win8r.encecwin.enc が、ZR さんのページに aencdviout.zip として置かれています。

II. LY1 エンコーディングを使う

ZR さんが、“謎が解けた! (3) ” において、「『dviout 流』 を再解釈してみる」 として、

「dviout の 8r」 についてだが、これは表(LaTeX)から見えないので 8r と呼ばれる必然性がない。だから素直に「Windows-1252」を表す名前を用いればよい。fontname の資料を見ると、「8w」 が Windows-1252(WinANSI) を指すとみて間違いない。

(中略)

「dviout の T1」 と同様の考えをもち、かつ TeX コミュニティにもっと受け入れられているエンコーディングが存在する――それは LY1 エンコーディングである。これも Windows-1252 の文字セットをもつフォントを可能な限り 「効率的に」 用いることを目的として設計されている。

ということから、LaTeX 側では LY1 を使って、それを Windows-1252 に帰着させるのが、「『dviout 流』 のより筋のよい実現方法」 とおっしゃるのは、もっともだと思います。

T1 エンコーディングの特徴は、0x800xBF のヨーロッパ各国語のグリフだと思いますので、そこが抜けているものを敢えて 「T1」(ないし 8t) と称する必要はなさそうですし、LY1 エンコーディングの 0x800xBF はほぼ Windows CP 1252 と一致していて、ly1enc.def にもちゃんとこれらのグリフに対応する \DeclareTextSymbol が宣言されているので、fontenc パッケージで LY1 を指定するだけで、上掲の赤いグリフも使えます。

この方針を採用する場合には、winansi.enctexnansi.enc、あと fontenc パッケージが必要ですが、いずれも W32TeX には含まれています。

なお、texnansi.enc にはリガチャの設定が入っていなかったり、texnansx.enc では重複しているグリフの削除の仕方が ly1enc.def とズレたりしているようですので、Windows-1252 の範囲で可能なリガチャを補ったり ly1enc.def とのズレを修正したりした “bx-ly1.enc” というファイルを ZR さんが aencdviout.zip に入れてらっしゃいます。

III. サブフォントを使う

最後に、dviout はサブフォントには対応しているので、ZR さんが 「裏技」 とおっしゃっている、サブフォントの仕組みを応用するという方法があります。

この方法を使えば、Windows CP 1252 の範囲にないグリフにもアクセス出来ますし、当該フォントがグリフを持ってさえいれば、本当の T1 も dviout でも実現できます

【訂正】 「本当の T1」 が実現できたように思ったのですが、0xA7 のグリフが何故か section になっていますね… (added: November 28, 2011)

ただ、ttf2tfm で .sfd を使ってサブフォントを作成する場合には、リガチャやカーニングを有効に出来ないようですので、リガチャはまぁ諦めるとしても、カーニングがない欧文組版というのはちょっと厳しいかも知れません (otftotfm を使えばカーニングの設定も可能みたいですけれど → SFD 編-8

Since: November 16, 2011.


【訂正】

上の最後に書いたことは、また早とちりでした…。キチンと ZR さんの (SFD 編-8) を読めば分かることでした。

リガチャやカーニングは tfm ファイルの受け持ちで、サブフォントは dviware/driver の話のわけですから、ちゃんとリガチャやカーニングの設定を含んでいる tfm ファイルを用意して、それをサブフォントの一員として使えば、リガチャやカーニングが有効な dvi ファイルを dviout で表示出来ますよね。

試しに、ttf2tfm で .sfd ではなく .enc ファイルを使って作った tfm ファイルを、.sfd を使う場合のように rename して、この  tfm ファイルを使って、以下のような原稿をタイプセットしてみました (fontenc パッケージで T1 にして、あと、\parindent0pt にしています.紙の幅を狭くしているので、\sloppy にもしてあります)

\begin{document}
>>{\AA}ngel\aa\ Beatrice Claire
Diana \'Erica Fran\c{c}oise Ginette H\'el\`ene Iris
Jackie K\=aren {\L}au\.ra Mar{\'\i}a N\H{a}ta{\l}{\u\i}e {\O}ctave
Pauline Qu\^eneau Roxanne Sabine T\~a{\'\j}a Ur\v{s}ula
Vivian Wendy Xanthippe Yv{\o}nne Z\"azilie<<

\bigskip

\begin{tabular}{|l|l|l|}
AV   & AT   & AY\\ 
A{}V & A{}T & A{}Y\\ 
\end{tabular}

\bigskip

fi fl ffi ffl ``'' -- ---
\end{document}

生成した dvi ファイルを、サブフォントを使うように設定した dviout で表示してみます:

 

リガチャもカーニングもうまくいっているように見えます。尤も、合成グリフばかりで、T1 の 0x800xBF のグリフが 2 〜 3 個しか含まれていないので、あんまりいい例ではなかったですけど…。

Added: November 17, 2011.


【訂正・追記】

上の 「III. サブフォントを使う」 という部分に載せた画像をよく見てみましたら、0xA7gbreve ではなく section になってしまっています TeX Forum に余計な投稿をしてみた ところ、山本和義さんからご指摘いただいて、ようやく気付きました…)

上で使っているフォントは mplus-1p-medium.ttf というものなのですが、他の、Windows に付属のフォントで試してみましたら、0xA7 だけではなく、0xAF0xB8 も、dviout では T1 のグリフが表示できませんでした:

これは century.ttf で試してみたものですが、0xA7gbreve ではなく section となり、0xAFracute でなくて macron、そして 0xB8ydieresis ではなく cedilla になってしまっていますね…。

この 3 つのスロットのグリフは Windows 1252 や TeXBase1 と一緒ですが、どうしてこうなってしまうのか、分かりません…。

ちなみに、dvipdfmx で pdf にすると、ちゃんと表示されます:

うーん、やっぱり dviout は難しいなぁ…。

Added: November 28, 2011.


home