pTeXでEUC-JISX0213, EUC-JIS-2004, ISO-2022-JP-3, ISO-2022-JP-2004を使うための拡張 pTeXでJIS X 0212 (JIS補助漢字) を直接使うための拡張 pTeX + UTF8でJIS X 0212, JIS X 0213のレパートリーを直接使うための拡張 [libkanji版] 2006.2.5 作成 2006.10.17 更新 KXD02663(at)nifty(dot)ne(dot)jp TANAKA, Takuji (( 1 )) はじめに JIS X 0213パッケージ[1]は、JIS X 0213(JIS第1〜4水準)の文字を 直接LaTeXで扱えるようにするパッケージであるが、 ASCII pTeX[2]とShift-JISX0213エンコーディングの組合せを前提に開発され、 EUC-JISX0213エンコーディングも第1面については先日対応していただいた。 今回、pTeXを少しだけ拡張し、EUC-JISX0213, EUC-JIS-2004, ISO-2022-JP-3, ISO-2022-JP-2004エンコーディングの いずれの場合でもJIS X 0213パッケージで第2面の文字を含めて使えるようにした。 さらにjbibtex, pdvitypeもJIS X 0213対応とし、エンコーディングによらず 使えるようにした。 さらにJIS X 0212(JIS補助漢字)がEUC-JPエンコーディング、ISO-2022-JP-{1,2} エンコーディングで扱えるような拡張も追加した。 さらに「pTeX を UTF-8 入力に対応させる試み(2)」[3]と接続し、 UTF-8でもJIS X 0213, JIS X 0212 のレパートリーが直接扱えるようにした。 (( 2 )) 改造の要点 主な拡張点は、 内部コードの問題とエスケープシーケンスの問題への対処である。 (2.1) 内部コード まず、内部コードの問題。 JIS X 0213パッケージは、Shift-JISX0213エンコーディングを用いて pTeXで漢字コードにShift JISを指定した場合に動作するようになっている。 このとき、JIS X 0213の第2面(第4水準)の文字には、 dviファイルへの書き込みにJISを拡張した95区〜120区に相当する コード値(0x7f21〜0x987e)が用いられる(下表の「拡張区」「拡張JIS」)。 pTeXで漢字コードにJISもしくはEUCを指定すると内部コードはEUCになる。 その場合、JIS X 0213の第1面の文字は現状でもpTeX内部で扱えるが、 第2面の文字は対応させるべき領域が内部コードに存在しないため、 現状のままでは動作しない。 また、JIS X 0213の第2面は、EUC-JISX0213エンコーディングでは3バイトになるため、 そのままのコード値でpTeXの内部処理を通るように改造するのは障壁が非常に高い[4]。 そこで、今回、内部コードがEUCのときの第2面の文字の対応関係を 下表1の「内部EUC区」「内部EUCコード」のように定め、内部処理を「内部EUC」とし、 pTeXの入口と出口のところでコード変換をするようにした。 この「内部EUCコード」は、規格外の不正なコードであるが、 内部処理にしか用いられず入出力のテキストファイルに現れることは通常ないので 特に問題はないであろう。 その上欧文TeXでは内部コードが公的規格と異なることはよくあることでもある。 なお、同様の内部EUCコードはWnn, CannaやMicrosoftのcp20932など他にも例がある。 pTeXのプリミティブ\jis, \euc, \kuten では、第二面の文字の場合、それぞれ 下表の拡張JISコード, 内部EUCコード, 拡張区と点を引数に取ると動作する。 例えば、2面-1区-1点は \char\euc"A121, \char\jis"7F21, \char\sjis"F040, \char\kuten"5F01 と対応する。さらに、 \euc についてはSS3を使用した本来のコード値 \char\euc"8FA1A1 でも、 \kuten については面区点 \char\kuten"20101 でも動作するようにした。 また「`」でコード値を取得すると内部処理用のコードが得られるが、 EUC出力時とJIS出力時は内部EUCコードになる。 2面相当部分の拡張JIS、拡張区点、内部EUCは規格外にはなるが、 今後アスキーpTeXに正式に取り込んでいただけるよう働きかけていきたい。 (2.2) エスケープシーケンス 次に、エスケープシーケンスの問題。 特に第1面の指示に使われるエスケープシーケンスが ISO-2022-JP(1990JIS), ISO-2022-JP-3(2000JIS), ISO-2022-JP-2004(2004JIS)で 異なっている。そして、pTeXで出力漢字コードにJISを指定した場合の 出力時のエスケープシーケンスをどうするかが考えどころである。 今回は、ISO-2022-JP, ISO-2022-JP-3, ISO-2022-JP-2004の各々の入力について、 自動的に出力もそれぞれに応じたエスケープシーケンスで行われるようにした。 それらが途中で混在したら後者を優先するように切り替えていく仕様とした。 このような混在自体は、後発規格で許容されているものである。ここで、 包摂規準の異なる文字が混在した場合の出力は必ずしも規格通りにならないが、 その場合は入力で混在していること自体がすでに規格通りではない。 JIS出力時のエスケープシーケンスの初期値は、デフォルト1990JISであり、 pTeXの起動時のオプションで "-kanji=jis2000", "-kanji=jis2004" と指定すれば それぞれ2000JIS, 2004JISとなるようにした。 特に入力ファイルがEUC-JISX0213の場合には、ISO-2022-JP系の場合とは異なり、 このオプションで明示的に指定する必要がある。 (入力文字列のみから2000JIS, 2004JIS等の差異を判定するのは不可能なため。) (( 3 )) JIS X 0212(JIS補助漢字)対応 JIS X 0212 (JIS補助漢字)にも(( 2 ))で述べた問題に対処すれば、 JIS X 0213パッケージと同様の手法(virtual font)やその他の手段で 対応することも可能なはずである。 そこでJIS X 0213と同様に、内部EUCコードを表2のように定め、実装した。 入力は、JIS X 0212の部分を含むISO-2022-JP-1, ISO-2022-JP-2やEUC-JPが 利用可能になった。 さらにvirtual fontを試作したところ、良好に動作している。 このJIS X 0212(JIS補助漢字)対応パッケージ(jishojoパッケージ)も合わせて 公開する。 過去にもJIS補助漢字をTeXで使えるようにしたアプローチは何種類もあり[5〜8]、 確かな需要の存在が読みとれる。 今回、普通の文字として直接エディタで文字を入力でき、直接pTeXが扱える ようになった点は大きいと思う。 EUC-JP, ISO-2022-JP-1で標準の「JIS X 0208 + JIS X 0212」はもちろん、 JIS X 0212とJIS X 0213が混在した場合でも適切に処理できる。 後者の混在はやや特殊であるが、例えばmule-ucsを導入したemacsでは、 文字コードを"euc-jisx0213"や"iso-2022-7bit"と指定すれば編集可能である。 なお、このJIS X 0212対応部分は、pTeX処理時の漢字コードSJISの場合には 対応していない。 (( 4 )) UTF-8への対応 今回(2006年10月)さらに、ptetex3の土村氏による 「pTeX を UTF-8 入力に対応させる試み(2)」[3] へのパッチとすることにより UTF-8入出力にも対応した。JIS X 0212/JIS X 0213のレパートリーを正しく 扱えるようにするために、上記の拡張を加えた上、[3]からさらに、 (1) Unicode←→JIS変換表の強化、 (2) Unicode→JIS変換時の同一視テーブルの強化、 (3) BMP超(CJK Extension B)対応、 (4) 合成文字(鼻濁音、アイヌ語用カナ等)の合成・分解対応、を行なっている。 ここでは、音声記号の合成の問題に対処するため、[10]で述べられた ZERO WIDTH NON-JOINER を入力時に解釈し、出力時に付加する実装を行った。 但し、内部処理は拡張EUCなので、JIS X 0208/JIS X 0212/JIS X 0213の範囲 にない文字は和文として扱うことは出来ない。 オリジナルの[3]では、\usepackage[utf8]{inputenc} でかなりの非英語 ラテン文字が出力できたが、それらの字のほとんどがJIS X 0212/JIS X 0213にも 対応を持つ。本パッチをそのまま適用した場合、JISへの変換を優先しているため、 \usepackage[utf8]{inputenc} で出力できる文字が激減する副作用がある。 とりあえず、PREFER_UTF8_INPUTENC を #define して kpathsea + libkanji を コンパイルすればJISではなくラテン文字を優先するようにしておいた。 この方法はいかにもad hocであるが、この問題の根本的解決には 実装を大幅に変更する必要があるため、今回は手を付けていない。 また、JIS X 0212とJIS X 0213の両方に1つのUnicodeのコード値が対応する場合 にはJIS X 0213を優先するようにしている。このためpTeXの漢字コードを `EUC'や`JIS'に指定した場合と微妙に結果が異なる場合がある。 なお、オリジナルの[3]では、Unicode変換の際、iconvを使用することも出来るが 今回のパッチでは未対応である。 (( 5 )) pTeX周辺ツールへの対応 UTF-8対応と同時に、対応ツールは、ptex以外にも、 pltotf, tftopl, pdvitype, jbibtex, mendexにも及んでいる。 但し、jbibtex, mendex は、JIS X 0213の第1面(JIS第3水準まで)の制限がある。 jbibtexは、オリジナルではJIS X 0208の範囲の文字に制限されていたが、 Shift-JISX0213環境でもこの制限がなくなりJIS X 0213の範囲の文字が 1面(第3水準まで)使えるようになった。 前回まで(2006年8月)は、jbibtexでは内部コードを特殊な値にすることで、 JIS X 0213の第2面(JIS第4水準)とJIS X 0212(JIS補助漢字)も使えるように 拡張していたが、libkanjiの汎用ルーチンを採用したため 現在利用できなくなっている。 tftopl, pltotfはオプションで "-charset=jisx0213" と指定すれば JIS X 0213対応、しなければ従来通りの動作とした。 jmpost, pdvitomp でも今回の拡張は有効のはずであるが、 PostScriptファイルには表1,2の拡張JISが使われることになる。これに 対応した特殊なCMapなどが必要になりそうだが、詳細はまだ検討していない。 (( 6 )) その他 今回の拡張は、従来のJIS X 0208やISO-2022-JP等を前提とした入力に対しても 動作が変化することはなく、上位互換になっている。 入力に内部EUCコードの拡張部分が含まれた場合に、エラーにならず 第2面の文字として処理されてしまうが、通常有り得ない入力であると思われる。 JIS X 0213/jishojoパッケージを使用しない場合に副作用を生じるようなことは、 通常ないはずである。 (( 7 )) 今後 将来見通しについて。 MacintoshのヒラギノやAdobeの小塚明朝、MicrosoftのMS明朝などで JIS X 0213やJIS X 0212のレパートリーが標準の日本語フォントとして 次々採用され、文字拡張の環境は一昔前と比べるとはるかに整ってきた。 その反面、エンコーディングとしてのJIS X 0212系やJIS X 0213系の 普及状況は淋しい限りで、今後の見通しも明るくはない。 今回(2006年10月)、「pTeX を UTF-8 入力に対応させる試み(2)」[3]との 接続が実現しUTF-8の入出力が可能になったたので、 この拡張も生きてくることになると思う。 (( 8 )) 本パッチの利用について 思いつく範囲でテストを行っている最中だが、ほぼ意図通りの動作をして いるようである。今後もしばらくテストを続けていく。 意図通りの動作を期待して作成しているが、結果については一切保証しない。 このパッチの著作権は一切主張しないので、 拡張部分の使用、再配布、転載、改造、流用などはご自由にどうぞ。 表1: JIS X 0213の第2面と各コードの対応関係 面-区 EUC-JISX0213 拡張区 拡張JIS 内部EUCコード Shift-JISX0213 2-1 0x8fa1a1〜 95 0x7f21〜 0xa121〜 0xf040〜 2-8 0x8fa8a1〜 96 0x8021〜 0xa821〜 0xf09f〜 2-3 0x8fa3a1〜 97 0x8121〜 0xa321〜 0xf140〜 2-4 0x8fa4a1〜 98 0x8221〜 0xa421〜 0xf19f〜 2-5 0x8fa5a1〜 99 0x8321〜 0xa521〜 0xf240〜 2-12 0x8faca1〜 100 0x8421〜 0xac21〜 0xf29f〜 2-13 0x8fada1〜 101 0x8521〜 0xad21〜 0xf340〜 2-14 0x8faea1〜 102 0x8621〜 0xae21〜 0xf39f〜 2-15 0x8fafa1〜 103 0x8721〜 0xaf21〜 0xf440〜 2-78 0x8feea1〜 104 0x8821〜 0xee21〜 0xf49f〜 2-79 0x8fefa1〜 105 0x8921〜 0xef21〜 0xf540〜 2-80 0x8ff0a1〜 106 0x8a21〜 0xf021〜 0xf59f〜 2-81 0x8ff1a1〜 107 0x8b21〜 0xf121〜 0xf640〜 2-82 0x8ff2a1〜 108 0x8c21〜 0xf221〜 0xf69f〜 2-83 0x8ff3a1〜 109 0x8d21〜 0xf321〜 0xf740〜 2-84 0x8ff4a1〜 110 0x8e21〜 0xf421〜 0xf79f〜 2-85 0x8ff5a1〜 111 0x8f21〜 0xf521〜 0xf840〜 2-86 0x8ff6a1〜 112 0x9021〜 0xf621〜 0xf89f〜 2-87 0x8ff7a1〜 113 0x9121〜 0xf721〜 0xf940〜 2-88 0x8ff8a1〜 114 0x9221〜 0xf821〜 0xf99f〜 2-89 0x8ff9a1〜 115 0x9321〜 0xf921〜 0xfa40〜 2-90 0x8ffaa1〜 116 0x9421〜 0xfa21〜 0xfa9f〜 2-91 0x8ffba1〜 117 0x9521〜 0xfb21〜 0xfb40〜 2-92 0x8ffca1〜 118 0x9621〜 0xfc21〜 0xfb9f〜 2-93 0x8ffda1〜 119 0x9721〜 0xfd21〜 0xfc40〜 2-94 0x8ffea1〜 120 0x9821〜 0xfe21〜 0xfc9f〜 表2: JIS X 0212と各コードの対応関係 (Shift-JISは未対応) 区 EUC-JP 拡張区 拡張JIS 内部EUCコード H-2 0x8fa2a1〜 130 0xa221〜 0xa221〜 H-6 0x8fa6a1〜 134 0xa621〜 0xa621〜 H-7 0x8fa7a1〜 135 0xa721〜 0xa721〜 H-9 0x8fa9a1〜 137 0xa921〜 0xa921〜 H-10 0x8faaa1〜 138 0xaa21〜 0xaa21〜 H-11 0x8faba1〜 139 0xab21〜 0xab21〜 H-16 0x8fb0a1〜 144 0xb021〜 0xb021〜 H-17 0x8fb1a1〜 145 0xb121〜 0xb121〜 H-18 0x8fb2a1〜 146 0xb221〜 0xb221〜 ... H-75 0x8feba1〜 203 0xeb21〜 0xeb21〜 H-76 0x8feca1〜 204 0xec21〜 0xec21〜 H-77 0x8feda1〜 205 0xed21〜 0xed21〜 参考URL [1] http://psitau.at.infoseek.co.jp/jisx0213.html [2] http://www.ascii.co.jp/pb/ptex/ [3] http://tutimura.ath.cx/ptetex/?UTF-8%C2%D0%B1%FE%282%29 [4] http://minakanusi.ns.musashi-tech.ac.jp/%7Einoue/Pages/TeX/ptex.sjisx0213.html [5] http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/program.html [6] http://www2.kumagaku.ac.jp/teacher/herogw/x0212.html [7] http://itohws03.ee.noda.sut.ac.jp/~matsuda/ttf2pk/ [8] http://www.yuasa.kuis.kyoto-u.ac.jp/~hiraisi/jishojo/jishojo.html [9] http://tutimura.ath.cx/ptetex/?UTF-8%C2%D0%B1%FE [10] http://wakaba-web.hp.infoseek.co.jp/table/jis-note.ja.html 変更履歴 2006.2.5 初版作成。ptex-src-3.1.9.tar.gzベース。 2006.2.18 修正。オプションでjis2000, jis2004を指定可能にした。 2006.2.28 修正。内部EUCの範囲を0x8E, 0x8Fを避けたものに変更。 2006.6.9 微修正。 2006.8.3 大幅な更新。ベースをptex-src-3.1.10-Beta3.tar.gzに変更。 第2面の内部EUCの範囲を0xA121〜0xAE7Eに変更。 JIS X 0212に対応。 Shift JISでも区毎にkcatcodeを指定可能にした。 \euc, \kuten を拡張。 2006.10.17 「pTeX を UTF-8 入力に対応させる試み(2)」[3]ベースの パッチへと大幅な更新。UTF-8入出力に対応。 新しくmendex, jmpostにも対応しているはず(詳細未検討)。 但しjbibtexでは、使える文字の範囲がJIS X 0213の第1面 (第3水準)までに縮小してしまっている。 仕様、既知の問題点、要検討事項 [1] jbibtexでオリジナルでは、不正な文字を検出したとき「■」に変換 　　する機能があるが、libkanjiの汎用ルーチンを利用するように変更し 　　たため引っかからなくなった。オプションを追加することでも対処可 　　能であるが、もともとチェックはゆるいし、pTeX→dviwareの過程の 　　どこかでも検出可能なので、特に対処する必要はないと思う。 [2] EUCの第2面のSS3を使用した本来のコード値→内部EUCの変換を 　　libkanjiで行うものと、ptex-base.chで行なうものを試作した。 　　前者はほぼうまく動いているが、入力に内部EUCの第2面部分が現れる 　　とエラーにならずそのまま処理してしまう。 　　後者はまだまだいろいろ問題がある。将来、内部Unicode化する際は 　　後者に似た方式を採ることになると予想しているので後者も動くよう 　　にしたいのだが。 [3] 前回まで(2006年8月)は、jbibtexでは内部コードを特殊な値にするこ 　　とで、JIS X 0213の第2面(JIS第4水準)とJIS X 0212(JIS補助漢字)も 　　使えるように拡張していたが、今回(2006年10月)libkanjiの汎用ルー 　　チンを採用したため現在利用できなくなっている。mendexでも同様に 　　JIS X 0213の第2面(JIS第4水準)とJIS X 0212(JIS補助漢字)は使用で 　　きない。 　　将来、jbibtex, mendexの内部Unicode化が実現されれば、同時にこの 　　ような制限を自然な形で撤廃できるようになると思うので、今回は対 　　応をあきらめた。 [4] jmpostのPostScript出力のJISコードが独自拡張JISになっているため 　　特殊なCMapファイルを必要とすると思われるが未検討。