pTeX を UTF-8 入力に対応させる試み(6) †
pTeX を中心に改造してきましたが、
今後の開発方針について考察してみます。
ptexenc の意義 †
一連のページのタイトルは「UTF-8 対応」となっていますが、
今となっては UTF-8 対応はほんの一部という気がします。
ptexenc の最大の意義は
「NKF を経由して、文字コードを自動判定できる」
ことであると認識しています。
ですからこれからは、このことを強調して行こうと思います。
文字コードの自動判定が不必要だと感じている方には、
次のクイズを考えていただきたいと思います。
- UTF-8 で書いたソース "hoge.tex" を、EUC が前提のシステムに持ってきました。
- platex コマンドを（ディフォルトの EUC で）動かしたところ、
タイプセットはできたのですが xdvi で文字化けしました。
- そこで TeX ソースが UTF-8 であることを思い出して "platex --kanji=utf8 hoge.tex" を
実行しなおしたところ、やっぱりエラーでうまくいきません。なぜでしょう。
文字コードの自動判定を行っていれば、このようなトラブルは起こりません。
もしたいていの人がこのクイズに正しく答えられるというのであれば、
文字コードの自動判定は不要でしょう。
しかし現実には、正解率は１〜２割ではないでしょうか。
答えは 動作報告/93 をどうぞ。
ちなみにファイルをフィルタ経由で読み込む拡張は ptexenc 独自のものではなく、
実装が異るものの XeTeX でも類似のものが見られ、
特殊というよりかはむしろ正常な改造だと思っています。
CTAN †
以前から libkanji や ptexenc をアスキーさんに寄付したい、
と書いてきていましたが、状況が変化したので、方針を転換します。
世界の TeX 関連ソフトの中で、ちゃんと開発していますよと認めてもらうには、
CTAN に登録されることが非常に重要です。
この事実に近頃ようやく気がつきました。
pTeX も CTAN に登録されましたので、
ptexenc も CTAN に登録されることを目指そうと思います。
これには英語ドキュメントの整備が急務で、
ptexliveWiki:ptexenc に慌てて書いています。
また単独で配布できるよう、構成も変えて、
必要なパッチをまとめて tar に放りこむことにしました。
ptexenc の更新作業は、今後は ptexlive を主体にして行い、
ptetex3 への反映はそれなりのタイミングで行うことにします。
PDF 直接出力 †
PDF を直接出力できない TeX エンジンを探してみます。
pTeX はもちろんですが、Omega も PDF 出力できません。
たぶんこの２つが大きなものでしょう。
例えば TeX には pdfTeX の拡張があります。
teTeX-3.0 以降 latex のディフォルトのエンジンは pdflatex に置き換わっており、
latex コマンドに "-output-format=pdf" のオプションを付ければ、
DVI を出力せずに代わりに PDF を出力してくれます。
世の中進んでいます。
Omega が PDF 出力できないといって安心していられません。
LuaTeX というものがどうもその役割を担うようです。
pTeX の周辺には、いまだに PDF 出力のできるエンジンが現れません。
これはこれで問題であろうと思っています。
もっとも、日本語特有の事情、例えばフォントをどうやって PDF に埋め込むのか、
というような問題でもあって、
そもそも PDF を直接出力するには向いてないのかもしれません。
しかしながら、そのような説明を私は聞いたことがありません。
世の中には ConTeXt という、LaTeX の代替品となるマクロがあるようです。
このマクロの下で動くエンジンには、pdfTeX、XeTeX、Aleph、LuaTeX が
使えるようですが、例によって pTeX は使えません。
単なる想像ですが、PDF 出力できれば pTeX も
使えるようになるのかなぁと思っています。
というのは間違いで、e-TeX 拡張が必要だそうです。
少なくとも pTeX は、世界の TeX の開発状況から
かなり取り残されてしまっている という認識を持つべきでしょう。
ということで、pTeX 周辺では、PDF 出力に向けた開発を行うか、
あるいは PDF 出力が無理である理由を説明しておくか、
どちらかをやっておくべきだろうと思っています。
（誰がやるべきかという点には踏み込まないことにします。
少なくとも ptexenc のような小さな枠組での開発は不可能です。）
内部 Unicode †
ttk さんが ptetex3 をベースに upTeX を開発されていますが、
これとは無関係に「内部処理が Unicode になった pTeX」の姿を
想像したいと思います。
ここでは、私の想像する「影も形もないソフト」について
勝手に書き並べるわけですから、
実際に開発が行われている ttk さんの upTeX と比較して
どうこうというようなコメントはお控え下さい。
とは言いながらも、考慮している構成要素をようやく列挙しつくしたつもりなので、
誤解を生む可能性は低くなったと思います。
そこで ttk さんの upTeX について言及していただいても良いことにしたいと思います。
（動いているソフトを開発されていることに対する敬意は忘れないつもりです。)
互換性 †
内部処理を Unicode にしたぐらいで pTeX との互換性が
維持できなくなると想像する人は、ほとんどいないでしょう。
しかし現実には、組版結果の同一性を保証することは不可能です。
- 縦書文字の回転
- 結論から先に書きますと、CMap の "V" が古い(?)ため、
縦書きの時に回転してもよさそうな文字が回転してくれませんでした。
これを Unicode 時代に持ち込むのは無駄だということです。
サンプルを載せておきます。
\documentclass{jsarticle}
\usepackage{plext} % for minipage
\usepackage{utf} % for \UTF{}
\begin{document}
\begin{minipage}<t>{12zw}
□→，．□（普通の文字）\newline
□\UTF{2192}\UTF{ff0c}\UTF{ff0e}□（UTF 命令）
\end{minipage}
~~~~~~
\begin{minipage}{12zw}
□→，．□（普通の文字）\newline
□\UTF{2192}\UTF{ff0c}\UTF{ff0e}□（UTF 命令）
\end{minipage}
\end{document}
同じ「→，．」の３文字を、普通の文字としてと \UTF{} 命令を経由しての２通りで
出力して比較します。横書はほぼ同じ出力になっていますが、
縦書きでは異っています。なぜこういうことが起こるかを、以下で説明します。
pTeX は JIS X 0208 を前提にタイプセットを行います。
出力した文字は、dvips や dvipdfmx が "H" や "V" の CMap 属性を付加して
更に下流に流れて行くことになります。
"H" と "V" の CMap はアドビ社が配布している、
JIS X 0208:1997 の文字セットで、
ISO-2022-JP のエンコーディングのものです。
Unicode で出力しようとすると、
CMap は "UniJIS-UTF16-H" や "UniJIS-UTF16-V" を使うことになるでしょう。
問題なのは、"H" と "V" の差異と、"Uni..-H" と "Uni..-V" の差異を較べると、
後者の差異の方が大きすぎることです。
"Uni..-V" は "V" よりも新しく、当然文字集合も増えています。
縦書き文字で回転するものが多く登録されてて当然です。
その増えたものが "H" にない文字ばかりであれば
大丈夫であったのですが、"H" にありながら "V" では回転しないのに、
"Uni..-V" では回転することになってしまった文字があります。
現状でも、縦書きで普通の文字として書くか、
UTF/OTF の \UTF{} で書くかによって、
回転するかどうかが変化しています。
このような文字には、先のサンプルで示したように矢印や全角コンマなど、
よく使われる文字が該当します。
pTeX の内部を Unicode 化したらこれが日常的に問題になるというわけです。
（文字の間隔が \UTF{} では異っていますが、
これはそういう設計になっているからでしょう。
普通の文字と同じにすることもできると思われます。）
互換性を優先して、回転する文字を苦労して制限することは可能です。
それには縦書き文字の CMap を V か "Uni..-V" か、
文字によって切替えることになるでしょう。
しかし、そこまでして互換性が必要でしょうか。
このような些細な問題のために
組版結果の 100% の互換性に全力投球するのはばかげたことと言わざるを得ません。
ではソースレベルの互換性はどうでしょうか。
つまり、pTeX 用に書いたソースを一切変更することなく、
内部 Unicode で（組版結果は同じにはならないにしても）
とりあえず処理できるようにすべきかどうか。
私は、ここはわざとエラーにして止めてしまうのがよいと思います。
同一のソースを組版する手段が２つあって、
しかも出力が微妙に異なるとなれば、
同一性を重要視する TeX の世界においては迷惑この上ないでしょう。
そして、組版結果にも影響を与えるもうひとつ別の問題も存在します。
- 漢字マクロ名
- pTeX では "\西暦" のような、漢字のマクロ名を使うことができます。
そして "\α" のように、ギリシャ文字も、日本語の２バイト文字なので、
同様にマクロ名として使えてしまいます。
以前の TeX には、マクロ名にはもちろん普通の文章としても漢字は使えませんから、
対応する機能は当然ありませんでした。
しかしながら Unicode 時代になり、
teTeX-3.0 の latex で \usepackage[utf8]{inputenc} を使えば、
"ö" のような文字が普通に使えるようになりました。
内部では {\"o} のようなアスキー文字に置き換えて処理しているようです。
では、pTeX ではマクロ名に使える２バイト文字であり、
しかも \usepackage[utf8]{inputenc} でもそのまま表記できる文字は、
pTeX が UTF-8 対応になった場合にどのように扱えばよいでしょうか。
pTeX との互換性を維持すればマクロ名として使えることを優先することになりますが、
それには latex との互換性を犠牲にして、内部でのアスキー文字への置換機能を
無効にせねばなりません。
ptexenc の対処としては、pTeX との互換性を維持する方向を選びました。
このことは qa:45027 の「ptetex3がラテン文字を全角文字に変換？」のように、
波紋を呼ぶことにもなりましたが、避けようがありません。
この時は主に見た目の問題が取り上げられていましたが、
マクロ名に使えるかどうかとおそらく表裏一体の問題で、
タイプセット中にエラーになるかどうかという意味では、
こちらの側面も重要です。
従って、pTeX 用のソースと、内部 Unicode 用のソースは、
見て明らかに異なり、間違っても入れ換えて組版できないように
しておくことを提案します。
\documentclass{hoge-article} のスタイルの名前で区別すれば、
簡単に実現できることです。
この２つの問題から、ptexenc での UTF-8 対応が、
pTeX との互換性を 100% 維持しながらできる
最大限の拡張であったことがわかります。
何を捨てるか †
pTeX との100%の互換性を、組版レベルでも、ソースレベルでも維持しないとなれば、
何の互換性を維持し、何を捨てるかを決めなければいけません。
ここでも TeX の習慣に従うとすれば、
最大限の互換性を維持するよう努力することになるでしょうが、
私はこれには反対です。
ほとんど使われていないような機能の維持は、次の開発の足かせになります。
せっかく 100% の互換性がなくなるのですから、
無駄な機能を切捨てる絶好の機会ととらえるべきでしょう。
今まで互換性を維持するがために、
捨てるに捨てられなかったものが pTeX 周辺に沢山あります。
min10 は jis で置き換えるべきでしょうし、
jarticle も jsarticle に乗り換えたほうがよいでしょう。
こういうものは積極的に切捨てるべきだと考えます。
文字コードの扱いも、もっと簡略化できるだろうと思っています。
pTeX では内部コードが EUC と SJIS の２通りあって話が複雑になっていました。
これを Unicode で統一すれば当然ながらすっきりします。
外部ファイルの扱いも簡単にできると思っています。
今回 ptexenc で統一的な処理を行ったので、
随分とすっきりしたのですが、
同時に NKF のようなフィルタで変換するという
処理が非常に強力であることにも気づきました。
内部 Unicode にするならば、
「ファイルはすべて UTF-8、文字コード変換が必要ならフィルタで」
という方針は大いに検討すべきだと思います。
うまくいけば、内部 Unicode には ptexenc の機能は、
ほとんど使わなくても大丈夫のような気がしています。
もちろん pTeX 用には必要ですが。
pTeX との互換性のために、内部が Unicode になったとしても
スタイルファイルで良く使われる JIS の外部ファイルを
読み込めるようにしておくべきだという考え方もあるかもしれません。
しかしながら私は以前に、ptexenc 側の拡張として、
スタイルファイルに限定すれば BOM 付き UTF-8 の読み込みを
自動判定できるだろうと提案したことがあります。
従って pTeX/内部 Unicode 両用のスタイルファイルを UTF-8 にしておくことは、
不可能ではないと考えています。
それよりも気になるのは、近頃の Fedora 等では、
pTeX 添付のドキュメントも UTF-8 に変換されていることです。
スタイルファイルに限って JIS にしておくことがこの先も許されるのでしょうか。
pTeX のスタイルファイルであっても UTF-8 になることを覚悟しておく必要を感じます。
pTeX からどこまで乖離するか †
内部 Unicode にしたら、ついでに捨てられるものは捨てて、
pTeX からどんどん離れることを提案しました。
しかしながら、pTeX の下流に位置するソフトとして開発した場合、
pTeX の更新には追従しなくてはいけません。
この追従を楽にするためには、むやみに pTeX から離れるわけにはいきません。
従って、次のどちらかを選ぶ必要があるでしょう。
中途半端では紛らわしいだけです。
- pTeX にぴったりくっついて、大幅な改造は控える
- pTeX から離れ、別ソフトとして独り立ちする
dvipdfm の拡張として、
dvipdfm-jp（日本語パッチ）と dvipdfmx が存在しますが、
まさにこの２つのどちらの路線を選ぶか、という問題と同じです。
pdfTeX や Omega との合流、あるいは中韓対応なんかを目指すなら、
pTeX から分かれた実装もありだろうと思っています。
今すぐ合流しなくても、少なくとも下準備というか、
コード整理・機能整理はやっておいて損はないと思っています。
問題はマンパワーです。
誰が手間のかかる開発をやるのか、という点に尽きます。
手間をかけるのであれば pTeX ではなく XeTeX, LuaTeX などの開発に
協力したほうがよいかもしれません。
中韓からの需要は、今度韓国に行って話をするので、
ある程度情報収集できると思っています。
世界で通用する日本語 TeX 環境に向けて †
pTeX は teTeX や TeX Live には含まれていません。
DVI ware で（日本語パッチはあるものの）オリジナルで pTeX に対応しているものは、
dvipdfmx, TeX-Guy の
gxdvi など極めて少数です。
この意味で「世界で通用する」とは言いがたいでしょう。
「世界で通用する」システムでなければ、
上で述べたように PDF 出力や e-TeX 拡張など
世界の TeX の進歩から取り残されてしまいます。
pTeX が、たとえ CTAN に入り、TeX Live に取り込まれたとしても、
それが対応する DVI ware が増えることに貢献することはあっても、
世界の TeX の進歩から取り残されてしまうことには変わりがありません。
本ページ執筆中に jfm と e-TeX 拡張についてコメントいただきました
→コメント(1)。
pTeX の拡張である jfm については日本語処理には必要なものとの思い込みがあって、
あまり深く意識していませんでした。
e-TeX については pdfetex コマンドがあることから存在は意識していましたが、
どこかに書こうと思いつつも、どういう拡張かは理解できていませんでした。
pTeX 拡張が「世界で通用する」ようになるには、どうしたらよいでしょうか。
私は pTeX が日本だけで使われているのではまずくて、
まずはアジアで使われる状況が必要であろうと考えます。
ヨーロッパ言語では縦書きは不要ですが、
アジアでは必要とする国がいくつかあります。
これらの国で縦書きのできる TeX としての地位を確立すれば、
「世界で通用する」までの道のりが見えてくるものと想像します。
（もっとも XeTeX でも縦書きはできるそうなので、
この特長を前面に出すだけでは不十分かもしれません。）
pTeX がアジアの国々で使われるには、
縦書きができるだけではもちろん不十分で、
UTF-8 対応、PDF 出力などなど、さまざまな拡張に対応することも必要でしょう。
それ以外にも 過度な日本語依存 を排除することが必要でしょう。
例えば \documentclass には、日本語使用を表すクラス名を書くか、
あるいはオプションに [japanese] を指定するような仕様にする必要を感じます。
エンコーディングも EUC-JP, Shift_JIS が使えるとすれば、
Big5 や EUC-KR も扱えるのでない限り、まずい気がします。
そうでないと、他の国のユーザから「なぜ日本語だけ優遇されているのか」
という苦情が来るでしょうから。
想像してみて下さい：逆に中国や韓国から、縦書きもできて、禁則処理もできて、
アスキー文字とそれ以外の間のスペーシングも適切な TeX 拡張が出てきたとして、
加えて開発した国に都合のよい拡張がたくさんあったとしたら、
「アジアで通用する TeX」と言われたところで日本人が使おうとするでしょうか。
例えばハングル処理のプリミティブがたくさんあって、
今後の開発の重荷になりそうだとしたら、我々は pTeX から乗り換えるでしょうか。
プリミティブでの拡張は避けてマクロで処理して欲しいと言うことでしょう。
このように考えてくると、pTeX 拡張が生き長らえるためには
「少々の日本語サポートを犠牲にしてでも、
自然に TeX の進歩に追従できる仕組みを作る」
という選択肢がある（かもしれない）ことになります。
それには例えば、縦書きや jfm の仕様を英文で明らかにし、
DVI ware からのアクセスに便利なライブラリを整備することなんかも
必要だろうと思います。
jfm から日本語依存色を排除する必要はあるかもしれません。
そして、この作戦がうまくいくかどうかは、
アジアの他の国の事情も大きくかかわってくることでしょう。
同時に、生き長らえられる「pTeX 拡張」には、
恐らくエンコーディングの扱いは含まれず、
UTF-8 一本で行くことになるでしょう。
ここまでは pTeX についてだけ考えてきましたが、
翻って日本語を組版できる TeX 環境について考えれば、
pTeX に固執せず XeTeX や LuaTeX の改良に力を注ぐと言う手もあります。
そうすれば PDF 出力（XeTeX ではダメですが）
や e-TeX 拡張は自動的に手に入ります。
pTeX か CJK-LaTeX か XeTeX かあるいは LuaTeX か、
どれに肩入れするかは慎重に考慮せねばならないと思います。
現実的な開発 †
実現できるのかどうかまったく分からない、
理想的な開発の方向を長々と書いてきました。
ここでは逆の方向、
すなわち小手先の拡張の積み重ねで pTeX を利用し続けることも少し考えてみます。
これには既に、
UTF/OTF パッケージと inputenc を組み合わせるという現実的な手段が
存在しています。
→qa:46067, platex-utf8 と UTF/OTFパッケージの組み合わせで色々な文字セットのためのdfu
\documentclass{jarticle}
\usepackage[utf8]{inputenc}
\usepackage{utf}
\DeclareUnicodeCharacter{9AD9}{\UTF{9AD9}} % ��
\DeclareUnicodeCharacter{FA11}{\UTF{FA11}} % ��
\begin{document}
高�盧褶�
\end{document}
ソースを UTF-8 で上のように書けば "platex -kanji=utf8" でちゃんと処理できます。
あるいは \input{hoge.dfu} としたとしても hoge.dfu も一緒に配れば
組版結果の同一性を保つことができるはずです。
これは 現状の ptexenc の機能だけで達成 されています。
もちろん拡張に次ぐ拡張のため、例えば "\高" というマクロは作れますが、
梯子高ではマクロが作れないといった、いびつなことが起こってしまいます。
（梯子高は内部で \UTF{} 命令に置き換えて処理をするので、
マクロ名には使えません。）
壮大な開発と、小手先の拡張の間に、現実的な落としどころがあるのか、
両極端のどちらかがよいのか、まだ見通せていません。
アスキー社さんの活動について †
ここまでの話の流れだと、ひょっとすると pTeX を開発して下さっている
アスキー社さんの活動を非難しているような印象を与えてしまうかもしれません。
もしそうだとすれば、私の意図とはまったくの正反対です。
むしろ、日本には TeX に関するユーザのグループがないにもかかわらず、
日本語 TeX が開発され続けているのは、
ひとえにアスキー社さんのおかげと思っています。
外国を見れば、国にひとつ TeX Users Group (TUG) と名のつく団体があり、
国に依存する開発の取りまとめを行っているように思えます。
日本には公式な TUG はありません。
代わりにアスキーさんを中心に開発者グループがあり、
また奥村先生の Web を中心に緩やかな人脈があります。
pTeX の開発は前者のグループに大きく依存しているように思います。
（事実誤認があれば申し訳ありません。）
これまでのアスキー社さんの活動には感謝していますし、
今後もできれば主導していただきたいと思っています。
一方で世間での (p)TeX の利用状況を鑑みれば、
過度な期待をするのも失礼であろうという気もしています。
pTeX で組版した本がどんどん増えているというのであればよいのですが、
現実には限られた分野で根強く利用されている、
という程度になっている思っています。
まとめ †
このページで言いたかったことを、もう一度まとめておきます。
- ptexenc の最大の成果は「文字コード自動判定」
- 内部 Unicode 処理になれば pTeX との 100% 互換動作は不可能
- ptexenc の UTF-8 対応は 100% の互換動作の上では最大限の拡張
- pTeX は世界の TeX 開発状況から取り残されている
- 今後の日本語 TeX を何に依存して開発するかは悩ましい
- アスキー社さんの開発活動に感謝
コメント(1) †
このページを執筆中にご意見をどうぞにコメントをいただきました。
整理のために以下に移動しました。
- latex engine が pdfTeX になっている話での、オプションに関するタイプミスです。 -output-comment=pdf ではなくて、 -output-format=pdf。 -output-comment は DVI 出力時に、コメントをデフォルトから変更するのに使います。このオプションは、大元の TeX にもあります。 -- kakuto
- ご指摘ありがとうございます。修正しました。 -- 土村
- 「UTF-8対応(6)」の「内部 Unicode」は興味を持って拝見しました。「upTeX と比較してどうこうというようなコメントはお控え下さい。」のあるのに、コメントしてしまいます。ご了承下さい。「何を捨てるか」で「min10」とか「jarticle」とかは些細な問題で、一番の壁は「jfm」だと思います。これがために、DVIwareの改造その他もろもろ、欧文TeX環境との距離が離れる最大の原因になっています。jfmを捨てて日本語組版規則をどう扱うのか、Omega, XeTeX, luaTeX それぞれアプローチは行われていると思います。upTeXはjfmを維持するアプローチであり、pTeXとの距離をキープしているものの、足かせともいえます。-- ttk
- 「UTF-8対応(6)」の解離とあるのは乖離ですね。 -- 通りすがり
- ありがとうございます。修正しました。 -- 土村
- PDF の直接出力の他に、私が pTeX について懸念していることは e-TeX を持たないということです。pdfTeX ではかなり以前から e-TeX が既定で有効になっています。つまり、欧米では e-TeX 拡張有効が既定の環境になっているということです。先日、CTAN にあるパッケージを調べていたら、それは(作者は何も注意していないに関わらず) e-TeX 拡張命令が使われていました(つまり pTeX では使えない)。恐らくは、「e-TeX 拡張を前提とする」考えが徐々に広まってゆくものと思われ、これは pTeX ユーザに多大な不便をもたらすことになるでしょう。(有名なパッケージが改版で「e-TeX 前提」となったら?) ちなみに、XeTeX と LuaTeX では e-TeX 拡張は仕様上常に有効です。 -- ZR
- なお私自身は LuaTeX に期待しています(cf. qa:49183)。これも絵空事ですが。 -- ZR
- e-TeX の参考文献は The e-TeX Short Reference Manual あたりでしょうか．TeX に primitive な命令を追加しようといった拡張という理解でよろしいでしょうか? -- kuroky
- W32TeX にはマニュアルの PDF 版(etex_man.pdf)が含まれます。基本的に、マクロの作成とデバッグを容易にする為の primitive 命令と、あと TeX--XeT 拡張(RTL 文字の処理)からなると見受けられます。TeX 本体以外(DVI 等)の仕様拡張はありません。 -- ZR
コメント(2) †
お待たせしました。一段落つきましたのでコメントよろしくお願いします。
- ConTeXt では dvi を出力するモードもあり、pTeX が engine として使えないのは pdf を出力できないからではありません。 e-TeX 非対応が主とした原因です。以前 e-TeX 対応が条件でないときは、pTeX でも format 作成が可能で、使用もできました。現在は不可能です。 -- kakuto
- たとえば、Aleph は Omega と e-TeX をマージしたものですが、 pdf 出力はできません。 (Aleph と Omega は現状で開発はストップされている. -- kakuto
- 解説ありがとうございます。表にするとこんな感じになるのでしょうか。e-TeX の拡張なら pTeX に取り込めるような気もしてしまいますが、大変なのでしょうか。 -- 土村
| -pdfTeX | | +pdfTeX |
|---|
| -e-TeX | +e-TeX | | -e-TeX | +e-TeX |
|---|
| -Omega | TeX
pTeX | e-TeX
XeTeX
e-pTeX | | (pdfTeX) | pdf(e)TeX |
|---|
| +Omega | Omega | Aleph | | | LuaTeX |
|---|
（単語の先頭の "+" は拡張機能があること、"-" はないことを示す）
- pdfTeX は、現在では e-TeX 対応したものだけがあり、古いものを除いて e-TeX 対応していないものはありません。(pdfetex は互換性のために残してある、 pdftex へのリンク)。 pTeX の e-TeX 対応は、TeX implementor にとっては、難しいことではないのではないかと思います。 -- kakuto
- ありがとうございます。表を更新しました。 -- 土村
- 北川さんの e-pTeX を表に加えてみました。pdfTeX のオリジナルの位置を書いておいた方が分かりよいような気がして表に()で加えてみましたが、目ざわりだったら削除してください。-- ttk
- 「PDF の直接出力への対応」の指す意味が曖昧であるような気がします。XeTeX のコマンド(xetex, xelatex)は確かに既定で PDF を出力しますが、内部では DVI (独自拡張)を作ってそれを xdvipdfmx コマンドに渡しているだけです。これを「PDF 直接出力」と呼ぶなら、pTeX をそうするのは極めて容易です―単に内部で dvipdfmx に渡せばよい。意図しているのは「pdfTeX の機能を持つこと」なのかも知れませんが、それなら XeTeX もその機能を持っていません。(少し邪な見方をすれば、XeTeX は「自前で用意した DVIware しか対応していない独自拡張の DVI を吐く」ということもできます。) 勿論、XeTeX と pTeX には一つ大きな違いがあります。前者は世界中で使われていて、後者はそうでないということです。 -- ZR
- 確かに、XeTeX が PDF 出力するというのは、私の（かなり前からの）勘違いでした。表を直しておきました。 -- 土村
- pTeX を Big5 や EUC-KR 対応にするのは(文字コードの面だけなら)簡単です。しかし、日本語向けに調整された組版アルゴリズム(jfmなどを含めて)がckにも通用するのかどうか(文字を単に並べる位のレベルではなくて、組版の品質が各国語の慣習に合っているのかというレベル)、中韓の人にもご利益があるのか、は良く分かりません。pTeX を中韓でも受け入れてもらえるようにするには、そのあたりを詰める必要がありそうです。しかし、pTeXの中韓対応が試されなかった最大の理由は、pTeXの情報が日本語しかない、という言語の壁だと思います。pTeX の仕様の英語の説明といえば、奥村さんの http://oku.edu.mie-u.ac.jp/~okumura/texfaq/japanese/ptex.html がありますが、もっと詳細なものが要るでしょうね。HLaTeX中心でここまで来た韓国語ユーザー、CJK-LaTeX中心でここまで来た中国語ユーザーから見て pTeX なり jfm なりは魅力があるか? 漠然とした疑問はあります。 それはさておき、お話を伺っていると、e-TeX拡張 + pTeX拡張というのは、日本の国内事情だけを考えても有り難味はありそうですね。これさえあれば、ConTeXt に対応できるのでしょうか? -- ttk
- DVIPDFMx, an eXtension of DVIPDFM, CID-keyed font support for dvipdfmあたりを見ると、dvipdfmのcjk対応に当たって、変更した点で重要なものは、(1a) subfont対応, (1b) jfm対応, (1c) ofm対応、(2) CID-keyed font 対応ということになりそうです。中韓の CJK-LaTeX, HLaTeX などは、8bit 欧文の TeX 内で動くのが利点だという反面、そのためにフォントを多分割しているので、それをまとめるのが一仕事ということらしいです。(2)についてはcjkの課題は一緒なので、pdfeTeXのcjk対応ということでは、(各国の事情を言わずとも)共同開発しやすそうです。新しいcjk向きTeX実装を作って移行することを考えるよりそっちをがんばる方が現実的かもしれません。-- ttk
- 開発方針をいろいろ検討して下さってありがたいです。
日頃から漠然と思っていることをまとめてみたつもりですが、私自身、どういう方針で開発を行えばよいのか、かえって分からなくなってしまいました。(^^;) -- 土村
- 新年おめでとうございます。このページの陰の目的(の一つ)は、AsiaTeX 08に向けての話題収集ではないかと勝手に想像しています。折角集まる機会ですから、出来る範囲で状況を知っておくことは有用だと思います。もし、大掛かりな開発をやるとなるなら、無駄な開発にならないためにも事前調査はちゃんとしたほうがいいでしょうし。-- ttk
- おめでとうございます。ttkさんのご想像に乗っかって、余計なことを書かせていただきます。日本語をTeXで処理しているときに、不便を感じることがいくつか有ります。1つは、日本人は罫線付きの表がやたらと好きであると言うことです。それも幕の内弁当の仕切りのようにかなり入り組んだ物です。わたし自身はいちいち罫線で囲むのは嫌いなのですが、仕事場で流通させるドキュメントにはかなりこういった物が有ります。TeXを使わない方々は表計算ソフトを一種のテーブルエディタとして使われているようですが、これはあまりよい習慣ではなく、出来栄えもいまいちです。TeX使いとしては、美しい組版をめざして、TeXで奮闘するのですが、かなり不自由を感じることがしばしば有ります。こういった事情は中韓ではどうなっているのでしょうか?もし同じような習慣があるのならば、共同開発の余地が有るでしょう。また、不便のもうひとつは、丸数字です。OTFパッケージでかなり美しい丸数字を書けるようになりましたが、まだ、マクロの中に採り入れようとすると、うまくいかない事が多いようです。(丸数字による自動番号づけはできるのですが、それを自動的にラベル参照して丸数字をとりだそうとするマクロを書くと失敗します。)こういった例は他の国々ではどうなのでしょうか? -- 通りすがり2
- 新年おめでとうございます。AsiaTeX08 とはたまたま時期が一致しただけで、狙ったつもりはありません。役立つとは思いますが。qa:49188, qa:49189 あたりの議論でお返事差し上げようと思いながら、仕事が忙しくなって放置してしまった罪滅ぼしのつもりはあります。早速角藤さんが pTeX の eTeX 拡張を始められたようで、ありがたく思っています。 -- 土村
- 土村さんの方から upTeX の話題が振られたので、upTeX との比較云々の規制はもう無しと解釈します(^^;)。以下、ここの議論も踏まえて、私見を述べます。もし pdfeTeX のような、欧米でホットな TeX 拡張を日本語 TeX にも欲しい、というのが重要な開発動機なら、「pTeX の内部 Unicode 化」という技術課題は、あまり本質的でない、と思います。何しろ欧文 pdfeTeX も 8bit なのですから。日本語 TeX の ConTeXt 対応という課題には pTeX 拡張 + e-TeX 拡張で解決できそう、ということは、ここで私は始めて知りました。upTeX の開発動機は、「目の前にある pTeX の不便な部分を内部 Unicode 化とともに解決可能な部分を解決する」のが主な目的であり、pTeX 互換性は(100%は無理にしても)重視しています。ck対応について「cjk 標準 TeX に近づきたい」というのは、宣伝文句的な意味合いが強くて、本当のところは、日本人ユーザーが日本語中心でckを混ぜて使う用途は想定できても、このままの形でckの人が主要な部分で利用することは想定しにくいと思います。upTeX で\jis などを残した点について異論を頂きましたが、私が思うに\euc や\jis を削ったところで日本ローカル色はそうそう消えるものではないと思います。\xkanjiskip など"kanji"をcjkに公平にするには、\xhanziskip や\xhanjaskip を追加するかまたは、\xcjkideographskip に変更するなどしないといけません。それ以前に jfm を使うこと自体が日本に都合が良すぎると非難されるかもしれません。新たなcjk標準TeXコンパイラをつくるなら手当ての必要があるかもしれませんが、手早く pTeX を Unicode化してオイシイところを享受するという upTeX が想定している主要な役目とはかなり距離があるように思います。\bigfive などは台湾の人が本当に必要なら彼らが入れればいいし、「先手を打って削っておいて ck に文句言われないようにしておこう」という考えはありません。再度になりますが、CIDフォントやCMap関連はcjkでも需要が共通で協調し易く、開発の狙い目として適切かもしれません。(p.s.丸付き数字など機種依存文字問題はupTeXでは解決済みです>通りすがり2さん)長文失礼しました。 -- ttk
- 日本の TeX 環境が世界の TeX の進歩から取り残されている原因として、e-TeX 拡張がないとか pdfTeX 機能がないとかいう個々の事項よりもっと本質的なのは「pTeX が事実上日本でしか使われていないに等しい」という事実そのものであると私は感じています。これが真である限りは、pTeX の改良は日本人がするしかなく、世界の進歩に追随できるだけの開発力を日本のコミュニティが持っていなければならないわけですが、現実はそうなっていません。将来的に、この状態が改善されて、日本独自の TeX の開発が世界に追随できるということには疑問を感じます。「日本独自の TeX を世界(東アジア)に普及させる」ということにも私は悲観的です。(今使っているものからそう簡単に移行するか? Omega はなぜ成功しなかったか?) 世界の流れとしては、LuaTeX は将来 pdfTeX と統合される―つまり標準の TeX となる―ことがと予定として既に決まっています。(pdfTeX の開発は現在の版の 1.50 で打ち止めで LuaTeX が pdfTeX の 2.00 版となる。) その時、日本は日本語化した LuaTeX を作るのでしょうか。きっと、LuaTeX 上で日本語機能を実装する方が現実的な策となるでしょう。もしそれが現実になるのであれば、最初からそちらの策をとった方が少ない開発力を有効活用できるのでは…というのが今の私の考えです。 -- ZR
- LuaTeX が pdfTeX の後継になるとは知りませんでした。Lua 言語のことばかりに気が行ってて、Omega との関係に気づいたのもつい最近です。ZR さんが LuaTeX を本命視されている理由が少しわかった気がするのですが、こういう情報のソースはどこにあるのでしょうか。http://www.luatex.org を見てもあんまりちゃんとは書いてないようですし。 -- 土村
- 私は cjk 対応の宣伝文句に踊らされていた気がします。それはともかく、cjk だけでなくモンゴル語にも縦書きがあるのですよね？
漠然とですが、pTeX 拡張のプリミティブのうち、マクロやフィルタで処理できるものは徐々に実装を移行していって、TeX コンパイラでの拡張を小さくしておくのが今後の拡張に都合がよいと思ってました。
（LuaTeX 上で日本語機能を実装するのと、方向性は似ている気がします。） -- 土村
- 誇大広告で騙したようでしたらすみませんでした。しかし、周辺事情(日本ローカル色が強すぎるなど)は無視して、単純な性能で見た場合にはそんなに誇大広告でも無いのではないか、と個人的には思っています。現実にはOmega/Aleph, XeTeXなどライバルも多いことですし。「かつてNTT JTeXの初期の頃はマクロだけで作られていて速度の面からチェンジファイルへ移していった」と聞いたような気がします。pTeX 実装をマクロなどへ、というと丁度その逆ですね。ただ、8bit欧文TeXへ載せるとなるとsubfontなど別の面で苦労せねばならなくなりそうなので、Omega/Aleph などをベースにした方がいいのかもしれません。縦書きに関しては、確かdvi命令255番がpTeXの独自拡張だったはずですが、せめてこれだけでも国際化を狙えないのものでしょうか。Omega, XeTeX, LuaTeXではどうなっているのでしょうか。 -- ttk
- Omega の縦書き(\textdir RTT)では DVI の拡張はなく、従って putchar と down で下に進んでいます。（実際は少し複雑で、また標識として RTT 部分の前後に special を出すが、これは消しても問題なし…のようである。）そういえば、e-TeX の right-to-left の処理でも、最初に Knuth が考えた実装は DVI 拡張を伴うものだったそうですが、e-TeX での実装は無拡張でやっています。（前者を TeX-XeT、後者を TeX--XeT と呼ぶ。）ちなみに、LuaTeX は Omega の拡張なのでこの部分では（DVI モードでは）Omega と同じで、XeTeX は横書きのものを graphicx と同じ方法で回転させるということを考えているように見えます。 -- ZR
- 従って、日本語 TeX でも「自分で縦に並べる」処理を行えば、DVI の拡張は避けられます。あと、データ部分の日本独自拡張として残るのが JFM でしょうが、これも OFM で代用可能な気がします。現状の pTeX でも、横書きの DVI については rml と jis を JFM と等価な OFM に置き換えて Omega 対応の dviware で処理することは可能なはずです。日本語 TeX 本体の処理では JFM 独自の GLUEKERN や TYPE の情報が必要ですが、これも Level 1 OFM で代用できるのではないかと期待しています。もしこれが可能なら、世界標準の仕様のデータを用いた日本語 TeX の可能性が開けます。（追記：縦書き用のフォントを用いようとするとグリフの回転の問題がありますね。）問題は、Omega のデータや（標準のはずの）set3 等への dviware の対応が現在進んでいる、あるいは将来進むのかどうかです。DVI が廃れた存在になるなら、進まないのかもしれません。もっともその場合は日本語 TeX も必然的に PDF 直接出力になるでしょうからデータの問題は自動的に消滅することになるのでしょうかね…。 -- ZR
- ZRさん、コメントありがとうございました。お話を伺っていると、pTeXのdvi命令255番の仕様の方がよっぽど単純明快と思ってしまいますが、国際的に認知されそうにないならあきらめるしかなさそうです。set3対応はupTeXでやってみて、xdvi, dvips, dvipdfmxのいずれも未対応だったので少々驚きました。中国の人には特に需要があると思うのですが。Omega対応かつpTeX未対応のdviwareはどの位あるのでしょうか? pTeXのPDF直接出力は、最近の角藤さんのpeTeXとdvipdfmxの一部を組み合わせれば、実現可能な距離にあるのではないかと想像しているのですがどんなものでしょう。 -- ttk
- petex はソースを見ていただくと Unix や uptex に簡単に適用できると思いますので、よろしくお願いいたします。私は TeX インプリメンタではありませんので、間違いなどがあったらなおしてください。最初に発表した後、東大の北川弘典さんという方も e-TeX 拡張をされたということで、ファイルを送っていただきました。ちゃんと調べていませんが、浮動小数点計算機能を付加されているということです。TeX--XeT 機能は除いてあるということです。私は簡単のため、また面白いため eTeX のままで残してあります。 \beginR と \endR の間にはもちろん日本語は使えません。 -- kakuto
- pTeX-DVI での縦書きの表現が今のように（down で左に動く…）なっているのは、その方が pTeX 自身の実装が単純になるからだと想像します。Omega の様に書字方向が多数ある状況だと話が異なるのかも知れません。set3 が実装されていない理由は簡単で、DVI では TFM/OFM の使用が前提となりますが、3 バイト以上の符号値に対応した TFM がない（Omega は 2 バイトまで）ので dviware を 3 バイト符号値対応にする術がなかったからでしょう。（もっとも DVI の仕様上は "set3 65" のような命令もあり得るので、set3 だけ対応するのも無意味ではないのですすが、現実に set3 を吐く TeX がなかったから…。）XeTeX は set3 を吐くので、xdvipdfmx は set3 対応です。LuaTeX も set3 を吐かせられますが、先の理由で、set3 を含む DVI は役に立ちません。最後に「pTeX の PDF 直接出力」については、結局それが何を指すのかに依るでしょう。単に「ptex が PDF を出力する」のことなら、XeTeX の真似をすればいいだけです。「pdfTeX の機能を入れる」のはそんなに簡単ではないと感じます…。 -- ZR
- 活発に議論いただいてありがたいです。DVI 命令の 255 番の縦書きですが、もし漢字文化圏で有用だという説明ができれば LuaTeX に機能拡張提案してみるものありかなぁと思っています。
ただ縦書きにも改行時に左右のどちらに進むかで２通りあると思うのですが、（日本語の）左だけではまずい気はします。pTeX にはない（ですよね？）右に進む改行の拡張を含めたほうがよいとは思いますが、そうすると拡張せずに putchar + down でも悪くない気もします。
ところで PS や PDF の命令での縦書きはどうなってるでしょうか。255 番のような direction 命令があれば機能拡張提案をしやすいと思います。 -- 土村
- petex の拡張ありがとうございます＞角藤さん。ソースはこれから見させていただこうと思うのですが、petex の拡張は単独のコマンドにするのがよいのか、pTeX に組み込まれるのがよいのか、どちらでしょうか。完全な上位互換で一意的な拡張なら pTeX に合流する手もあるかと思うのですが、他の方の拡張もあって一意でないのなら合流するわけにはいかない気もします。個人的には合流できた方がユーザから見て単純でよいと思うのですが。 -- 土村
- pTeXに合流するのが自然な流れだと思います。そこから、ConTeXt(あるいはLuaTeX)への統合の道も見えてくるのではないでしょうか?もちろんTeXliveの2008年版の成り行きにも左右されますが... -- 通りすがり2
- ［LuaTeX の機能拡張提案?］縦方向への変位で DVI の拡張を使うか否かの議論に関わらず、LuaTeX には既に Omega の書字方向処理機構が備わっているので、これを使わずに新たに日本語縦書きの機能を付加するという考えはあり得ないと思います。それはともかく、独自拡張でなく今ある LuaTeX や XeTeX の枠内で日本語組版の充実を図るならば、発展途上の現段階において、日本語に必要な機能の要望を伝えておくことは重要だと感じます。相手もそれを（どこかの段階で）必要とするに違いないので。 -- ZR
- 以前に Omega は DVI 拡張を伴わないと書きましたが、考慮不足でした。\textdir の第 3 パラメタはグリフの向きを定めるもの（縦書きフォント使用時は RTR でないといけない?）ですが、これが T でない場合、dviware はグリフを回転させる必要があり、従って以前に言及した special は有意のものでした。もっとも dvipdfmx も odvips もこの special には未対応でした。LuaTeX の PDF 出力は横書き（左右）以外にはまだ対応していません。だから Omega 系統の正しい縦書き出力はまだ「見る」ことができません。 -- ZR
- ［LuaTeX の情報源］ 私も、luatex.org にある情報しか見ていません。開発状況とかは、そこにあるスライド資料が参考になります。LuaTeX の使用例については、Haralambous 氏（Omega の作者の一人）による The Joy of LuaTeX に幾つかあります。 -- ZR
- ［PDF での縦書き］PDF の仕様書を見ると、「文字を出力した時の参照点の変位はフォントに依存する」とあり「特に日本語のフォントは 2 種類の変位を "writing mode" により切り替えられる」とあります。このモードの指定は CMap にあり、よってフォント選択の時に決まるということでしょう（あまり理解していません）。座標の取扱等のその他の要素は書字方向とは無関係です。とにかく pTeX-DVI の dvipdfmx の変換結果では単に "set char" の連続です。PS の方は、dvipsk の出力を見る限り、rotate 等が使われていますが…。（日本語縦書きフォントの構造をもう少し習得しなければ…。） -- ZR
- e-TeX拡張の件で状況を複雑にさせてしまったようで申し訳ありません，北川と申します．こちらで独自に行ったe-TeX拡張+浮動小数点のソース類をhttp://www.ms.u-tokyo.ac.jp/~kitagawa/においてみました．TeX--XeTも通る（日本語も「通るには通る」）ようにしてあります． -- 北川 弘典
- petex+upTeXはもうちょっとしてe-TeXについてもっと勉強してから取り組みたいと思います＞角藤さん。私の前回の発言での「pdf対応」は「pdfTeX の機能を入れる」の意味のつもりでした＞ZRさん。Omegaの縦組みの対応状況を改善する、という課題も無駄にならない仕事のように思えて来ました。それに加え、pTeX-DVI → Omega-DVI の変換機能さえあれば、dviwareのpTeX専用拡張も縮小できそうです。「日本語(cjk)に必要な機能」でしかもOmegaやLuaTeXやXeTeXが備えていない機能が何なのか、もっと検討する必要がありそうだと思いました。ckの人はどう思っているのかも興味があります。 -- ttk
- 「pTeXに合流する」のが自然だといったののは、これまでのpLaTeX2eの下位互換を維持しつづけ、かつ、世界的な潮流に乗る用意ができた、という意味で言ったことです。pTeX拡張+eTeX拡張を施したTeXエンジンが我々の手に入ろうとしているのですから(これは角籘さんに感謝!)日本のTeXユーザーはこれまでのpLaTeX2eの資産を継承しつつ、また異なったenvironmentで日本語使用ならびに縦書きができる基礎条件を手に入れたことになるわけです。ここからは、過去の遺産を利用しつつ、たとえばConTeXtのような新しい環境にもコミットメントできる(これは開発+利用も意味します)地位を手に入れたことに他なりません。あるいは日本産の統合的TeX環境を構築する(もちろん、その中にはすくなくともcjk(v)の人々が貢献できる余地があるわけです)というような稀有壮大な選択肢もあるわけです。なんか、開発に参加できない人間がこういうことを言うと、反発を買いそうですが、日本をめぐるTeXの状況がワクワクするようなものになってきた気がします。 -- 通りすがり2
- petex: kitagawa さんによる epTeX が公開され、こちらのほうが歴史も古く信頼性が高いので、私が試作したものは、廃棄することにしたいと思います。W32TeX では (今極端に忙しいのでちょっと時間がかかりますが) kitagawa さんのものを勉強し、わかったら build したいと思っています。 -- kakuto
- [LuaTeX & cjk] LuaTeX関連ドキュメントやソースを斜め読みしてみたのですが、2007-12-31に私が述べた機能のうち、subfont, ofm, Type0 fontあたりは実装済みor予定のようで、足り無そうなのはCMapを解釈する機能とAlephの縦書きがテスト不足 (jfmは有るはずがない…) ということぐらいに見えました。但し、CJKが手薄であることは確かなようです。ドキュメントに現れる"OrientalTeX project"とは何でしょうか? CJKは含まれているのかどうか? -- ttk
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
rotate.png