（テスト中＆超手抜き）pTeX を UTF-8 入力に対応させる試み †
アスキーの pTeX は、
ソースの漢字コードとして JIS, SJIS, EUC の三通りをサポートしていますが、
最近よく使われるようになってきた UTF-8 には対応していません。
そこで、内部処理に影響しない範囲で、UTF-8 を扱えるよう改造をしてみました。
nkf でソースの漢字コードを EUC に変換して platex でコンパイルするという、
二段階の手順が、一度ですむようになることを目指しています。
EUC で表現できない文字は、やはりうまく処理できないことに変わりはありません。
| ./configure 指定 | UTF8 | EUC | JIS | SJIS | -kanji オプションで変更可能 |
|---|
| 入力（TeXソース） | JIS | |
|---|
| UTF8 | EUC | SJIS |
| 内部 | EUC | SJIS | fmt と一致させる必要あり |
|---|
| バナー文字列 | UTF8 | EUC | JIS | SJIS | This is pTeX, Version 3.141592-p3.1.9 (???) |
|---|
| 出力 (メッセージ等) | 画面のメッセージやログファイル |
|---|
| 出力 (DVI) | JIS | |
|---|
- ./configure に JIS を指定した場合、内部処理は EUC ながらも、
入出力は JIS に変換されます。
今回の UTF-8 拡張は、この JIS 対応と同じ方式をとっています。
すなわち、入出力のみを UTF-8 に変換し、内部処理は既存の EUC そのままです。
- ./configure に UTF8 と指定できるようになりました。
（ttk 氏にご協力いただきました。）
ただし、pltotf, tftopl, jmpost は未対応です。
需要は少ないでしょうから、当面は対応しなくてもいいでしょう。
ダウンロード †
ptetex3
の 2006/05/24 以降に仕込みました。
パッチのみが必要な方は、この中の以下のファイルをお使い下さい。
archive/ptex-src-3.1.10-fmtutil.diff
archive/ptex-src-3.1.10-utf8.patch
archive/ptex-src-3.1.10-jbibutf8.patch
archive/mendexk2.6d-utf8.patch
やったこと †
pTeX のファイルを読んでいる部分に、
UTF-8 -> EUC 変換の処理を追加しただけの、単純なものです。
内部処理は EUC のままなので、fmt も使いまわせます。
- 内部処理は EUC と同じですので、EUC で表現できない文字は、
やはり UTF-8 で書いたとしても処理できないことに変わりはありません。
- JIS で書いた TeX ソースは、そのまま使えます。
platex-euc/-sjis とマクロ類を共有できるわけです。
- メッセージ出力や hoge.out などのファイル出力も
EUC -> UTF-8 に変換するようにしました。
ターミナルが Unicode のままでよくなりました。
想定する用途 †
FC なんかの世界共通のディストリビューションでは、
標準の文字コードが Unicode になってて、
普通にエディタを使うと Unicode で保存されるし、
ターミナルも Unicode がディフォルトだと思います。
こういう環境で（文字コード変換せずに）使えればよいと思います。
もっとも、「はしご高 (髙)」なんかを書いた人から、
「なぜ処理できないんですか」などと苦情が来てしまいそうですが。
\西暦 はちゃんと動いているようです。
TeX Q&A 37587
想定しない用途 †
Babel を使った多言語処理で Unicode が使える、ということには
ならないと思うのですが、どうでしょうか。
JIS に変換できない UTF-8 文字は、^^ab 形式に変換するようにしましたので、
\usepackage[utf8]{inputenc}
と書いておくと、元々の LaTeX の機能で出せるウムラウト付きの o (ö)
などと日本語が混在できるようになりました。
^^ab 変換の副作用で、
JIS に変換できない文字が、警告なく無視されるようになりました。
上のように \usepackage[utf8]{inputenc} を書いておけば、警告してくれます。
ウムラウトを使わなくても、必須ということになります。
安田功氏の Utf82TeX
とは狙いが違って、日本語以外の文字にはあまり手を加えない方針です。
ただし、Utf82TeX の後に必要であった iconv による漢字コード変換は不要になるので、
便利にはなるかもしれません。
関連情報 †
TODO †
- 内部処理は本当に EUC でよい？
- SJIS のほうが JIS X 0213 にはよさそう?
- Unicode テーブルは自前で持つべきか、iconv を使うべきか。
- 今のテーブルは teTeX-3.0 に含まれている、VFlib2（ライセンスは LGPL）由来のものを include している（パッチ自体にテーブルは入っていない）
- iconv は環境によって微妙に異なるものの、
UTF-8→JIS へ多対一変換を行えば、微妙な差は吸収できそう
- iconv はコンパイル時にうまくリンクできるかどうかという問題がつきまとう
（pTeX が autoconf を使ってくれてりゃ簡単に対応できるのだが）
- 自前テーブルを持つと、ptex, jbibtex などで共有したくなる→ライブラリにしてしまう？
- 自前テーブルでも iconv でも、結局はライブラリを作るはめになる？
- 入力時の合成文字の処理。Macでは「が」が「か」と濁点に分解されることがあるとのこと。
- 読み込み時のBOMの無視。
- JIS X 0213化に備えUTF-8の4バイト拡張を形だけでもしておきたい。
今後の開発の方針 †
私としては未来永劫パッチのメンテナンスをしよう、
などとは考えてるわけではありません。
適当なタイミングでアスキーさんに取り込んでもらえたらよいと思っています。
上流に取り込んでもらいやすくするために、
わざと凝った作りにせず、単純な仕掛けにしています。
このような単純な拡張をなぜ誰もされないのか疑問だったので、
何か致命的な問題でもあるのかと思って自分で試してみたら、
あっけなく動いてしまった、というのが真相です。
もっとも、やってみて、Unicode テーブルをどうやって手に入れるかが
最大の問題であることに気づきました。
ptex, jbibtex, mendex などと、個別のコマンドが
Unicode の巨大なテーブル、あるいは複雑な UTF-8 を読み込むルーチンを、
別々に持つのは無駄に感じています。
漢字コード変換のライブラリを作るのがスジでしょうか。
これは想像していたよりも面倒に思えてきました。
ご意見をどうぞ †
- プラットフォーム間や色々な実装でファイルを使いまわすことを考慮すると、変換表に神経を使う必要がありそうです。例えばうぇーぶだっしゅ
。XMLの解説。MSの解説。問題の発生しそうな文字はUTF8→EUCで多対１の変換をする案もあります。 -- ttk?
- JIS X 0213に関心を持って下さったようで有り難うございます。JIS X 0213の変換表にはJIS X 0213:2004改正の情報を含んでいない旧いものでは、かっこつきUCSなどいろいろ問題がありますのでご注意下さい。 -- ttk?
- いろいろ解説ありがとうございます。UTF-8→EUCで多対１の変換をするよう、テーブルを作ってみました。これさえちゃんと動けば、巨大なテーブルを持たずに iconv を使ってもよさそうですね。JIS X 0213 はどのように対応したらよいのか、まだよくわかっていません。iconv で SHIFT_JISX0213 が使える環境は、まだ少数派でしょうか。こちらにもゆらぎがあるでしょうか。 -- 土村?
- ともかく iconv を使ってみるように書き換えてみました。パッチのサイズも小さくなって、それなりにちゃんと動いているようではあるのですが、環境によってはコンパイル時のライブラリの指定が面倒そうです。環境検査して自動判定にしたいところですが、pTeX は autoconf を使ってないので、どう対処すべきか、非常に頭が痛いです。 -- 土村?
- また変更して、iconv をやめて teTeX 配布物中のテーブルを使うようにしました。本命は iconv とのハイブリッド（あれば iconv、なけりゃテーブル）でしょうか。 -- 土村?
- 申し訳ありませんがTODOを追加させてもらいました。いろいろ考えるとまだ先が長そうですね。協力しますのでよろしくお願いします。-- ttk?
- 更新ありがとうございます。ところで、UTF-8の4バイト拡張とはどのようなことか、不勉強にしてわからないので、解説いただけるとありがたいです。 -- 土村?
- JIS X 0213だとU+2xxxxの文字が303字あるので、それらは、UTF-8だと4バイト(UTF-16だとサロゲートペアの4バイト)になります。例えばこことか。 -- ttk?
- Mac では，ちゃんと設定をすると，バックスラッシュと円記号を区別して入力・表示できるので，これらをどう扱うか，考えないといけないかもしれません．すでに考慮済みの場合，このコメントは忘れてやってください (m__m) -- kuroky?
- 「U+00A5 (Yen Sign) → EUC 0x5c の片側変換をした方がいいかどうか」ということになりますが、将来内部がUnicode化された場合思わぬ禍根を残すような気がします(同じソースが動かない or U+00A5が処理できない、のどちらかになる)。0x5cはTeXで基本中の基本なので、波ダッシュよりもはるかに危険性が高そうです。Macユーザーの方には、今回のUTF-8対応の際にはpTeXの外での対応のご協力をお願いしたいと思っています。 -- ttk?
- UTF-8の4バイトがでてくれば、対応文字なしとして〓に変換するだけでよいのでしたら、おそまきながら少し前に実装しておきました。
JIS X 0213 のための追加的な処理があるのかと思ってしまったのですが、そういうわけではないのですね。
BOM もやっておきました。合成文字はちょっと時間がかかりそうです。 -- 土村?
- 合成文字も JIS の範囲でやっておきました。対応文字がないときに〓に変換するのはやめにして、^^ab 形式に変換するようにしてます。 -- 土村?
- ご苦労さまです。ご対応ありがとうございます。TODOは半分以上済みましたね。pltotf, tftoplももうじきご提供出来ると思います。そろそろ「超手抜き」は降ろすべきのような気がします。最大の課題は、どの表を使うか、どう実装するか?でしょうか。ところで細かいようですが、「JISの範囲」という言い方はやめにしませんか。JIS X 0221(≒Unicode)の範囲だとしたら変換すべき字はなくなってしまいます ^^;; -- ttk?
- 内部コードは EUC のままなので、「超手抜き」であると思っています。外部仕様はようやく固まりましたが、これから内部仕様の大幅な変更を行います。pltotf 等に手をつけていただくのは、もっと先にしていただかないと、無駄になってしまいそうです。 -- 土村?
- 私のpTeXへのパッチはJIS X 0212(JIS補助漢字)対応になりましたので、ご報告(というより「宣伝」)いたします。将来UTF-8対応と接続していただけることを夢見ています。 -- ttk?
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
