（簡易版）pTeX を UTF-8 入力に対応させる試み(2) †
アスキーの pTeX は、
ソースの漢字コードとして JIS, SJIS, EUC の三通りをサポートしていますが、
最近よく使われるようになってきた Unicode (UTF-8) には対応していません。
そこで、内部処理に影響しない範囲で、UTF-8 を扱えるよう改造をしてみました。
NEW: 以前の UTF-8対応 とは異なり、
jmpost なども含めたすべてのツールを UTF-8 対応にしました。
同時に、共通な漢字コード変換処理をライブラリとして独立させました。
動作確認も以前より網羅的に行っています。
ダウンロード †
ptetex3
の 2006/08/27 以降に仕込みました。
パッチのみが必要な方は、この中の以下のファイルをお使い下さい。
archive/tetex-3.0-libkanji-0.84.patch
archive/ptex-src-3.1.10-utf8.patch
archive/mendexk2.6d-utf8.patch
archive/jmpost-0.04b-utf8.patch
基本的には、teTeX-3.0 の ./configure に次のオプションが増えます。
--enable-kanji=KANJI Default Kanji code
(KANJI=no/JIS/EUC/SJIS/UTF8, default no)"
--enable-kanji-iconv use iconv for kanji <=> unicode conversion"
詳しい利用方法は 2extract-src.sh などをご覧下さい。
想定する用途 †
昨今の UNIX/Linux ディストリビューションでは、
標準の文字コードが Unicode (UTF-8) になりつつあり、
Unicode の使えないアプリケーションは obsolete されつつあります。
pTeX が obsolete されないためにも、
UTF-8 対応は必須であろうと思います。
ひとまず、エディタやターミナルが Unicode になっていても、
文字コード変換をせずとも自然に pTeX が使えるようになったと思います。
jbibtex, mendex も含めて、同じ漢字コード変換ルーチンを共有していますので、
信頼性も確保できているはずです。
現状では、UTF-8 で入力できるのに
「はしご高 (髙)」のような文字が処理できません。
直感的ではないので利用者を混乱させるマズイ仕様だと認識していますが、
解決には内部コードの変更が必要になり、大変な手間がかかりそうです。
ここでは、ともかく UTF-8 対応をアスキー社に取り込んでもらうため、
大きな変更は避け、単純で見通しのよい実装にとどめておくことにします。
（その意味では、以前の実装の方が単純ではありました。
ただし、一つのツールを改造するだけならそれでよいのですが、
いくつものツールをまとめて改造するとなると、
今回のライブラリ化は避けて通れないでしょう。）
やったこと †
- 漢字コード変換に関する処理を、ライブラリとして独立させました。
- ptex/jbibtex/mendex/jmpost などのソースコードからは、
漢字コードに依存して処理を切替える部分がほぼなくなり、
短く見通しよくなりました。
- 共通のライブラリを呼び出すので、信頼性の向上が期待できます。
- 機能追加も比較的容易になります。
- 共有ライブラリを有効にして make していれば、
実行ファイルのサイズも節約できます。
- 切り出したライブラリは kpathsea の一部になるようにしました。
- 単独のライブラリにしてもよかったのですが、
kpathsea がよく整備されているので、流用して実装を楽にすませました。
- かなりの部分は pTeX のソースから切り出したので、
ライセンスは pTeX に準じたものになるのでしょう。
- ディフォルトの漢字コードは、
ライブラリ（というか teTeX-3.0）の ./configure 時に --enable-kanji=EUC
などと指定します。
- ptex, mendex の ./configure 時に必要であった漢字コードの指定は、
不要になりました。
- ptex, mendex, jmopst はこれまで teTeX-3.0 とは別に make install する
必要がありましたが、適切なパッチを当てて展開しておけば、
teTeX の make install だけで一緒にインストールされるようになりました。
| ツール | 入力ファイル | 内部バッファ | 出力ファイル | 使用関数 |
| ptex | EUC系 | EUC | JIS
(DVI) | EUC系 | input_line2() toJIS()
putc2() |
|---|
| SJIS | SJIS | SJIS |
| pltotf | EUC系 | EUC | JIS (tfm) | input_line2() toJIS() |
|---|
| SJIS | SJIS |
| tftopl | JIS (tfm) | EUC | EUC系 | fromJIS() putc2() |
|---|
| SJIS | SJIS |
| pdvitype | JIS (DVI) | EUC | EUC系 | fromJIS() putc2() |
|---|
| SJIS | SJIS |
| jbibtex | EUC系/SJIS | EUC | EUC系/SJIS | set_internal_euc_only()
input_line2() putc2() |
|---|
| mendex | EUC系/SJIS | EUC | EUC系/SJIS | set_internal_euc_only()
input_line2() putc2() |
|---|
| jmpost | EUC系 | EUC | JIS
(PS) | EUC系 | input_line2() toJIS()
putc2() |
|---|
| SJIS | SJIS | SJIS |
| pdvitomp | JIS (DVI) | EUC | EUC系 | fromJIS() putc2() |
|---|
| SJIS | SJIS |
- 上段の 'EUC系' は、-kanji= オプションに EUC or JIS or UTF8
を指定した場合です。
下段の 'SJIS' は、-kanji=SJIS を指定した場合です。
- jbibtex と mendex は、SJIS の場合も EUC系と処理が共通なのでまとめて書いています。
- JIS の入力ファイルは、EUC系と SJIS の双方から正しく読み込めます。
出力ファイルは、ツールの漢字コード設定に依存しますので、
JIS 入力で UTF-8 出力ということもありえます。
- 出力ファイルには、log や画面のメッセージ出力も含んでいます。
個別に異なる漢字コードを指定することはできません。
- '使用関数' は、独立させたライブラリの関数です。<kpathsea/kanji.h> に
定義されているものです。
- Unicode <=> JIS の変換テーブルは、
teTeX-3.0 内蔵の gd のテーブルを流用しています。
- teTeX-3.0 の ./configure に --enable-kanji-iconv オプションを
付ければ (lib)iconv 対応になります。
Linux ではちゃんと動くようですが、ちゃんと動かない環境も多いようです。
- iconv 対応のような変更は、ライブラリ側だけを変更すればよく、
ptex などのツールにはまったく影響がありません。
デグレ †
処理を共通にするために、
個々のツールにあった特殊機能のいくつかが犠牲になっています。
しかしおそらく、現状では不要な機能ばかりだと思います。
不都合がありましたらお教え下さい。ものによっては復活も可能です。
- jbibtex は JIS コードの微妙に違うもの 6 種類を
（出力としても）使い分けられましたが、
今回は pTeX 本体と同じ 1 種類のみをサポートします。
環境変数による漢字コード指定もできなくなりました。
ターミナル出力とファイル出力は、独立して漢字コードが指定できましたが、
その機能もなくなりました。
- mendex は kpathsea なしでもコンパイルできましたが、
kpathsea3（というか teTeX-3.0）が必須になりました。
以前から引き継いでいること †
各ツールの、ファイルを読んでいる部分に、
UTF-8 -> EUC 変換の処理を追加しただけの、単純なものです。
ptex の内部処理は EUC のままなので、fmt も使いまわせます。
- 内部処理は EUC と同じですので、EUC で表現できない文字は、
やはり UTF-8 で書いたとしても処理できないことに変わりはありません。
- JIS で書いた TeX ソースは、そのまま使えます。
platex-euc/-sjis とマクロ類を共有できるわけです。
- メッセージ出力や hoge.out などのファイル出力も
EUC -> UTF-8 に変換するようにしました。
ターミナルが Unicode のままでよくなりました。
- 入力時には、UTF-8 にまつわる特殊な加工を行います。
出力時にはこのような加工の逆変換は行っていません。
（加工されたままで出力されます。）
- Unicode でのバラツキを同一視する多対一変換
- BOM の無視（ファイル先頭に限らず）
- 濁音・半濁音の合字処理
- JIS に変換できない文字を ^^ab 形式に変換
多言語処理について †
pTeX + Babel を使った多言語処理で、すぐに Unicode が使えるわけではないようです。
EUC に変換できない UTF-8 文字は、^^ab 形式に変換するようにしましたので、
\usepackage[utf8]{inputenc}
と書いておくと、元々の LaTeX の機能で出せるウムラウト付きの o (ö)
などと日本語が混在できます。
しかし、元々の LaTeX の機能で出せる文字は、そう多くはないようです。
^^ab 変換の副作用で、
EUC に変換できない文字が、警告なく無視されるようになりました。
上のように \usepackage[utf8]{inputenc} を書いておけば、警告してくれます。
ウムラウトを使わなくても、必須ということになります。
安田功氏の Utf82TeX
とは狙いが違って、日本語以外の文字には手を加えない方針です。
ただし、Utf82TeX の後に必要であった iconv による漢字コード変換は不要になるので、
便利にはなるかもしれません。
想定しない用途 †
前述のとおり、UTF-8 では入力できるのに EUC で表せない文字は、
やはり処理できません。
もっとも、齋藤修三郎氏の UTF/OTF パッケージを前提にして、
\UTF{1234} 形式に変換する拡張も可能ではありますが、
ptex コンパイラが特定のマクロ/仮想フォントに依存するのは
どうかという気がして、控えています。
また、ウムラウト付きの o (ö) を {\"o} に置き換えるような拡張も可能ですが、
誰がこのようなテーブルを用意するのかと言う問題があります。
日本語が専門の ptex ではこのような変換は行わずに ^^ab 形式に変換して素通しし、
オリジナルの LaTeX に任せておくことにします。
これからできそうなこと †
文字コード変換部分を独立させたので、
内部コードを変更することが容易になりました。
- ptex の内部コードについて
- 内部コードを -kanji=SJIS の場合も含めて EUC に統一することは簡単です。
- 逆に SJIS に統一するのは、ほんの少し手間がかかりますが、すぐにできます。
- -kanji=UTF8 の内部コードを EUC でなくて SJIS にするのも簡単です。
- 外部ファイルについて
- JIS のファイルは -kanji の指定に関わらず正しく読み込めますが、
これと同じことが BOM 付き UTF-8 でも実現できそうです。
つまり BOM 付き UTF-8 のファイルが -kanji=SJIS, EUC, JIS のいずれでも
正しく読めるような拡張も簡単です。
- 用途は $TEXMF 以下のスタイルファイルを想定しています。
今は JIS がその役割りをしています。
- UTF-8 ファイルの先頭は ASCII (7bit) 文字である、という条件も必要なようです。
- いただいたアイデアなのですが、
外部ファイルの漢字コードの自動判別も、
100% の性能を要求しなければ可能であろうと思います。
個人的には、上流に取り込んでもらうことを目標にしているので、
あまり凝ったことをするつもりはありません。
今後の開発の方針 †
私としては未来永劫パッチのメンテナンスをしよう、
などとは考えてるわけではありません。
適当なタイミングでアスキーさんに取り込んでもらえたらよいと思っています。
上流に取り込んでもらいやすくするために、
わざと凝った作りにせず、単純な仕掛けにしています。
これは以前の UTF-8対応 から何ら変化していません。
ライブラリ部分は kpathsea に取り込んでもらうのがよいのか、
アスキーさんに管理してもらうのがよいのか、
コミュニティ（我々）でメンテナンスするのがよいのか、
迷うところです。
内部処理の Unicode 化も必要だと感じていますが、
まずは今のパッチを上流に取り込んでもらうことが先で、
内部処理はその次の段階になって考えればよいことだと思っています。
どうやって思い付いたか †
ptex の内部には iskanji1(), iskanji2() という関数があります。
これらは内部バッファの文字が漢字かどうかを判定するものですが、
内部バッファの文字コードは EUC と SJIS の二つの可能性があります。
これらの関数は、現在処理中の文字コードに従って動作を切替えるという、
賢い動作をしてくれます。
半面、JIS との文字コード変換では、
現在処理中の文字コードによって EUCtoJIS() や SJIStoJIS() を使い分けると言う
繁雑な実装になっており、ソースコードは読みにくくなっています。
そこで、iskanji1() などの動作の真似をして toJIS() のような関数を新設し、
現在処理中の文字コードに従って
EUCtoJIS() と SJIStoJIS() を使い分けるようにしました。
更に入出力の関数を切り出して共通化した、というのが今回の作業です。
現在処理中の文字コードに従って動作を切替える関数は
kpathsea/kanji.h に集約しました。
これらは ptex, jbibtex などのツールから直接使ってよい関数でもあります。
動作を切替えない単純な関数は kpathsea/kanjicnv.h に、
更に Unicode に関するものは kpathsea/unicode-jp.h に分離しました。
これらは ptex などからは直接呼び出す必要がないものです。
謝辞 †
ttk 氏にいただいた jbibtex, mendex の UTF-8 対応パッチが大いに役立ちました。
奥村氏、井上氏にも BOM や ^^ab 形式についての助言をいただきました。
TODO †
- libkanji
(lib)iconv 対応 ある程度完了- ドキュメント書き
- ライセンス確認
- upstream に投げる？
- BOM 出力は可能か？
- mendex
- kpathsea2 対応も廃止
- autoconf 化？
ご意見をどうぞ †
- アクセント付きアルファベット（例えば ? ）を含んでいる .bib ファイルを jbibtex 処理した場合に，その出力の .bbl ファイル内では {?"o} となってくれると嬉しいのですが，そうなってくれるのでしょうか？ -- kkondo?
- 上記はウムラウトの � のことです --
- ウムラウトがあっても jbibtex で正しく処理できるはずなんですが、試してみると platex ごとエンバグしてしまったようです。直します。 -- 土村?
- 9/1 版で直しておきました。{\"o} の書ける場所なら、直接 � と書いて、jbibtex 経由で正しく文字が出ました。TeX ソースにはもちろん \usepackage[utf8]{inputenc} が必要です。 -- 土村?
- どうもありがとうございました． UTF-8 対応型 jbibtex は ウムラウトの � を {\"o} へ変換して，.bbl ファイルへ出力するのでしょうか？ そうでしたら .bbl ファイルとしての標準記法(?)だと思いますので，他人へファイルを渡したような場合にも特に問題発生しないような気がいたします． -- kkondo?
- {\"o} ではなくて ^^ab^^cd のようになります。だから \usepackage[utf8]{inputenc} が必要です。.bbl ファイルの漢字の部分は UTF-8 ですが、JIS にでも変換して他人に渡せば、確かに普通の platex でも処理できますね。 -- 土村?
- どうもありがとうございました．論文投稿等におきまして，^^ab^^cd という記法(?)を用いた .bbl ファイル等を投稿原稿として送った場合に，先方で latex (or platex) タイプセッティングを行った際に，トラブル(?)が起きるかもしれない(?)という気がしました． （ソースファイル（ .tex , .bib , .bbl ）に対して，{\"o} という記法への変換を行うコマンド(?)というものはどこかにあるものなのでしょうか？） -- kkondo?
- 上に書いてます安田功氏の Utf82TeX なんかはどうでしょうか。 -- 土村?
- どうもありがとうございました．普段の利用には ptetex3-UTF-8 がとても便利そうですね． 他人へソースを渡すような際には、{\"o} という記法（アクセント付きアルファベットを含んでいる場合）と shift jis or euc コード（日本語を含んでいる場合）へ変換してから渡す必要がありそう(?)ですので、Utf82TeX を用いて、^^ab^^cd （^^十六進数形式）という記法のソースを変換できるものなのか調べてみようと思います． --
- お世話になります。「BOM 付き UTF-8 のファイルが -kanji=SJIS, EUC, JIS のいずれでも正しく読めるような拡張」とありますが、先頭が"EF BB BF"で始まっても正しいEUCのファイルである可能性もあります(確率は低いですが)。例えば、"EF BB BF EE BB BF"はUTF-8としても正しいですが、同時にEUC-JPの「鏤随賛」となると思います。同様に半角カタカナ入りのShiftJISかも知れません(JIS X 0208領域外ですが)。 したがって完全な自動判定は不可能であり、ある程度ヒューリスティックな判定になるでしょう。 -- ttk?
- 細かな例外の指摘、ありがとうございます。まだ実装すると決まったわけではないので、深く考えてませんでした。BOM 付き UTF-8 ファイルの先頭（つまりファイルの 4byte め）には ASCII 文字が来ることを条件にしておけば、先頭 4byte を見て常に正しく判定できるでしょうか。TeX で扱うファイルが前提なので、半角カタカナ入りのShiftJIS は無視していいでしょう。 -- 土村?
- 確かに「先頭がBOM+ASCIIで始まる」なら100%正しく判定できそうですね。しかしそういう入力を要求する仕様は、表現をお借りして言うと「わかりにくい仕様」だと思うのです。また、「-kanji=レガシーエンコーディング系」な方でUTF-8が読めて喜ぶ人がどれだけいるのだろうか、という疑問もあります。逆に「-kanji=UTF8でも、99%以上の確率でSJISが読めます。」の方向を狙うなら喜ばれるかもしれません。(漢字判定用のバッファーをさらに追加すればできそうです。) もしご興味があれば、ここの解説と絵はお勧めです。-- ttk?
- 用途を先にちゃんと書いておくべきでした。$TEXMF 以下にインストールされるスタイルファイルに UTF-8 を使うことを想定してました。今は JIS がその役割りを担っていますが、BOM 付き UTF-8 も OK になればいいだろうというのが私の狙いです。ですから「-kanji=レガシーエンコーディング系」で、UTF-8 だと判定すれば絶対に UTF-8 である方法を考えました。TeX で扱うファイルの先頭は大抵 ASCII だと思うのですが、スタイルファイルはもっと顕著で、ほとんど % のコメントで始まっています。ヒューリスティックな自動判別は、また別段階で考えるのがよいと思います。 -- 土村?
- 角藤さんの utf8toutf (http://www.fsci.fuk.kindai.ac.jp/aftp/pub/ptex/utils/utf8toutf.zip) というもので，� --> {\"o} への変換ができるそうです． --
- 角藤さんの utf8toutf ソースの中身を少し調べてみますと，� --> \"{o} と変換しているようです．BibTex 処理の場合には， --> {\"o} であることが必要なので，ソースを修正する必要があります． --
- 新規の機能追加になってしまいますが、defaultの漢字コードを各ユーザーが指定する環境変数(例えば TEXKANJICODE のような)を作ってもらうわけにはいかないでしょうか。自前でソースからコンパイルする場合は当然不要ですが、コンパイル済みのバイナリーと自分好みの漢字コードが異なるケースが今後増えてきそうです。それから、variation表ですが、いくつか外すべきではないかと思うものもあったのでこちらにまとめてみました。もちろん、ポリシーとして別の考え方もあると思いますので、強い要望ではないのですが、ご検討いただけたら幸いです。 -- ttk?
- default の漢字コードを環境変数（というか texmf.cnf）で指定できるようにするのは、あれば便利だろうとは思っていました。環境変数名をどうするのか（TEX ではなくて PTEX の独自機能ですよね）と、どのタイミングで機能追加するかが検討課題です。同一視テーブルは改めて。 -- 土村?
- 私の拡張も、このlibkanjiへのパッチとすることでUTF-8でJIS X 0213(JIS第4水準まで)とJIS X 0212(JIS補助漢字)のレパートリーが直接扱えるようになりましたのでご報告します。まだまだ問題点もありますが、当面の目標まではほぼ到達しました。-- ttk?
- defaltの漢字コードの設定の件、角藤さんのW32TeXでは、PTEX_KANJI_ENCという環境変数をつくったとのことです(2006/10/19付)。 -- ttk?
- お知らせありがとうございます。ftp://jupiter.fsci.fuk.kindai.ac.jp/pub/ptex/win32/current/ChangeLog のことでしょうか。
ようやく見付けました。
よく考えると fmt 再生成が必要になるのですね。
これは UNIX 的には困った問題です。
システムの fmt をユーザが書き換えるのはまずいです。
ところが環境変数はユーザ所有のもので自由に変更できます。
ここの整合性をどうとればよいのでしょうか。 -- 土村?
- 探す手間をとらせてしまっったようで済みませんでした。リンクしておくべきでした。なるほど。Windowsでも管理者権限のないユーザーがTeXのバイナリーを更新できないケースはありそうですね。思いつき程度の案ですが、PTEX_KANJI_ENCがeucならp(la)tex-euc.fmtを、sjisならp(la)tex-sjis.fmtを、なしならp(la)tex.fmtをデフォルトとする、といったところでしょうか。この程度で上手くいきますかどうか。 -- ttk?
- 私もよく理解してないのですが、
fmt が「実行コマンド名＋.fmt」になるルールがどこかで入っていて、
これを上書きで変更することは、どの段階でやればよいのか、よくわかりません。
ptex の拡張としてはやりたくなくて、むしろ根本的に問題なのは、
ptex の内部コードに sjis/euc と二種類あることで、
これを sjis にでも統一すればよいのだと思っています。
現状、内部コード（というか 入力ファイルの sjis/euc ）の違いで ptex の DVI 出力に相違が出るのは、
hyperref （PDF の日本語しおりを作るとき）ぐらいだと認識しているのですが、他にも違いがあるでしょうか。
もっとも、内部コードの変更は、内部 UTF-8 化の時にでもならないとできないでしょうが。 -- 土村?
- platex をシンボリックリンクではなく、シェルスクリプトにしてしまう手がありますね。platex-euc なんかに振り分けるラッパーにしてしまうわけです。起動が遅くなる、なんて苦情が来てしまいそうですが。 -- 土村?
- fmt ファイルの生成コマンドが，updmap/updmap-sys みたいにユーザ用とシステム用に分かれていて，ユーザ用のものは，$TEXMFHOME 以下に作ってくれるという仕様にはなっていないということなんですね・・・． -- kuroky?
- ↓の kakuto さんのコメントを受けて，土村さんのコメントの意味を捉え切れていなかったことに気づきました．環境変数を変えればそれで一件落着じゃなくて，fmtutil をそれなりのオプションをつけて (?) 回してやるという操作も必要で，その作業を漢字コードの変更をしたいユーザがみんなやらなければいけないのか，というところが問題だと．環境変数という一瞬，すぐにでもユーザが切替えられそうなもので管理すると，実は落し穴があって，混乱を招きかねないということですね?! -- kuroky?
- 言葉足らずですいません。ご指摘の通り、
fmt はユーザの責任で生成できるけれども、根本的な解決にならないと思っています。
（むしろパッケージャとしては -sys なしの fmtutil/updmap の存在は忘れたいぐらいです。
なぜならシステムの fmt を更新してもユーザのものはそのまま放置されてしまいますから。） -- 土村?
- fmtutil-sys と fmtutil がありまして、fmtutil の場合はteTeXのデフォルトでは $HOME/.texmf-config/web2c/ におかれると思います。 ptetex3 で変更されていたら、そのかぎりではありません。 エンコーディング関係をすっきりしていただいてありがとうございました。( >土村さん、ttk さん) -- kakuto?
- kpathsea に手を入れたので賛否はあると思っていましたが、「すっきりした」と評価していただけたようで、ありがたく思います。 -- 土村?
- ご説明有り難うございました。私の思い付きより根が深い問題だと理解しました。角藤さんのW32TeXのソースでは、libkanji関連はkpathseaの外に出してあったと思います。 -- ttk?
- なるほど、libkanji は分離されているようですね。（リンクが役立ちました。）分離には手間がかかるだけで、技術的な問題は何もないので、これでよいと思います。UN*X を前提にすると、環境検査の必要から autoconf をまじめに書かないといけないので、手抜きをしたというぐらいです。Win なら環境決め打ちでよくて autoconf を書くほどでもないので、楽でいいですね。 -- 土村?
- bibtexソース（UTF-8; 日本語もウムラウト等も）を処理する際に，自家製のフィルタでウムラウト等は{\"o}へ変換させたいと思っております．このようなフィルタをかませることは可能でしょうか？ -- kd
- 「フィルタをかます」の意味をはっきりさせておきたいのですが、「変換後のファイルを作らずパイプでつなぐ」ということでよろしいでしょうか。このページでは libkanji を使った古い拡張機能を説明していて、現在では ptexenc とライブラリの名前が変わっています（→UTF-8対応(4)#j6b28e46）。
ptex, jbibtex などのツールにまとめてフィルタをはさむ拡張は UTF-8対応(3)#z1df24aa で行いました。しかし LaTeX 上の inputenc を使えばフィルタを使わずともウムラウトの変換は実現できますので、わざわざ自前で処理しようとされている意図・状況設定をつかみかねております。（なので私の拡張がお役に立てるのか判断ができていません。） -- 土村
- どうもありがとうございます．いろいろ悩んでいるのですが，下記の様に処理したいと考えておりますところです．（従いましてbibtexソースに対してウムラウト等をUTF-8 --> {\"{o}}形式へ変換するフィルタをかませたいと考えた次第です．） (1) texソース： 日本語: UTF-8, ウムラウト等: UTF-8（{\"{o}}形式も可） (2) bibtexソース： 日本語: UTF-8, ウムラウト等: UTF-8 (3) bibtexソースからptetex3のjbibtexによって生成されるbblファイル： 日本語: UTF-8, ウムラウト等: {\"{o}}形式 -- kkondo
- ですから、学会投稿のような他人とのデータ交換用途でしょうか、自分だけの閉じた環境で使うためでしょうか。Mac なら TeX Shop のように文字列置換を支援する環境もありますが、そういうものはお使いではないのでしょうか。人文系の多言語テキストのように Babel を必要とされているのでしょうか。 -- 土村
- UTF82TeX http://www.ceres.dti.ne.jp/~i-yasuda/tex/utf82tex.html を使えばいいのではないでしょうか -- wakakumo
- Utf82TeX はこのページでも２回ぐらい紹介しているのですが、問題はどの段階で変換するか、でしょうね。
bbl の出力時のみのフィルタを指定する機構は、ptexenc にもありません。
^^ab^^cd 形式になっても編集しないのであれば、LaTeX/pLaTeX を問わずちゃんと処理できるので、データ交換にも不都合はないんですけどね。 -- 土村
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
