upTeX, upLaTeX --- 内部unicode版 pTeX, pLaTeX の実装 2024.12.28 Ver2.00 TANAKA, Takuji ttk(at)t-lab(dot)opal(dot)ne(dot)jp ◇ upTeX開発のねらい upTeX Ver0.02 〜 Ver1.35 ASCII pTeX/pLaTeXは、高品質の日本語組版ソフトウェアとして、いくつ かあるTeXの日本語化の中でもデファクトスタンダードの地位にある。縦組 の機能や日本語組版の品質はもとより、信頼性の高さや周辺ソフトウェアの 充実、ユーザー層の厚さなど、多くの点で圧倒的な魅力がある。しかし、直 接使える文字集合は、原則的にJIS X 0208(JIS第1,2水準)の範囲に限定され ている。例えば丸付き数字などは、「機種依存文字なので使えません」とい うことになっている。その一方、昨今のコンピュータ周辺の環境では、 JIS2004ことJIS X 0213(第3,4水準を追加)や、Unicode、Adobe-Japan1-6の ような公的/私的な規格、Machintosh搭載のヒラギノ、Windows搭載のMS明朝、 Acrobatに添付の小塚明朝など、JIS第1,2水準を超える範囲の文字を容易に 利用可能な環境はどんどん整ってきた。もはや、JIS第1,2水準で我慢してい るのはつまらない。機種依存文字は使えませんといって済ますことができる ような時代ではないのである。 これを克服する努力も繰り広げられてきた。そのひとつにUTF/OTFパッケー ジがある。巨大なvirtual fontに多分割する方法で巧妙にpTeXの狭い文字空 間をかいくぐり、UnicodeやAdobe-Japan1-6といった大文字集合を利用できる ようにした功績は大きい。しかし、マクロベースであり、直接文字入力する こともできないしaux, logなどに直接文字として出力することもできないな ど、制限事項も多い。Utf82TeXでは、プリプロセッサを利用することで、 UTF/OTFパッケージの入力の繁雑さを克服しているが、内部はpTeXであること に変わりなく制限事項を完全に克服できたわけではない。ptex-utf8, platex-utf8 は、pTeX入力のUTF-8化の大きな一歩であるし、^^ab化などの 工夫で\inputenc{utf8}との親和性が向上してはいるものの、日本語の基本 部分はやはりJIS X 0208の範囲に留まっている。いずれのアプローチも、 JIS第1,2水準外の現代の新しい標準を普通の文字として直接普通に使えるよ うになるまでには至っていない。Omega/lambda, XeTeXなどTeXのUnicode拡 張はあるものの、日本語の組版品質の繊細な部分まで行き届いているとは言 いがたいようであるし、マクロ類の充実、ユーザー層の厚さや参考書の多さ などを含めた環境整備はまだまだである。 pTeXにも弱味はある。前述の文字集合の問題以外にも、二点挙げてみよう。 一つは、8bitの非英語欧文との親和性である。もともとpTeXは、8bit目が立 った文字コードがEUCやShift_JISのパターンにマッチすると、和文処理に回 す。その動作が固定されているために、8bitを使うような日本語以外の文字 コードが直接処理できない。近年のpTeX+babelは、その動作をかいくぐる工 夫を要しており、単純とは言いがたい上に8bit欧文の直接処理も困難である。 もう一つは、pTeXの利用が日本語に限られていることである。中国語/韓国 語との混植は、UTF/OTFパッケージで可能になったとはいえ、マクロベースの 不便さは否めない。Unicode時代にあって、ローカルなソフトウェアは国際的 なディストリビューションの中でobsolete扱いを受けるようになってきたと 聞く。pTeX内部の動作をよく見ると、中国語/韓国語を含んだI18Nを施すこと はさほど難しくないように思えるが、実際にそうした話は聞いたことがない のは実にもったいないことである。日中韓(CJK)混植という面ではCJK-latex のようなマクロベースのアプローチもあるが、和文の組版品質や各種制限の 多さは問題である。pTeXでCJKの文字を直接扱うような拡張法の方が遥かによ い解となることは間違いない。 本upTeXの目標は、pTeXの利点をそのまま受け継ぎつつ、上記三つの弱点 を克服したpTeXの無理のない自然な拡張により、新時代の日本語(+東アジア) 標準TeXの地位を目指すことにある。文字集合の面では、pTeXの和文がJIS X 0208の範囲だったのに対し、upTeXでは内部コードをUnicode化しその中の CJKのレパートリーの範囲を和文の組版に利用する。8bit欧文との親和性の 面では、プリミティヴの指定により、和文/欧文の切替えを可能にする。国 際化の面では、pTeXでは日本語限定だったのに対し、upTeXではUnicode化に より中国語/韓国語を強化する。これらの拡張により、全世界制覇は無理に しても東アジア(CJK)標準TeXの地位に近付きたい。そこまでいければ、中韓 のTeXユーザーや開発者の方々もこの拡張版pTeXの利用環境のさらなる改善 に力になってくれるかもしれない。壮大な目標ではあるが、土台のpTeXの申 し分のない高みを出発点として、無理のない自然な拡張を着実に行っていけ ば、成果を出しつつ目標に近づけるであろうと目論んでいる。 ◇ upTeX開発のねらい upTeX Ver2.00 〜 upTeX/upLaTeX Ver1.xx は、2007年の開発開始以来、私自身の作業に 加え多くの方のご協力を得て機能追加や周辺環境の充実、不具合の修正が継続 し、お蔭様でユーザー各位の幅広い支持を受けることができた。TeX Liveの 配布にも収録していただけるようになり、当初の目標だったpTeX/pLaTeXの 自然なUnicode拡張による和文+CJKの充実と、さらに、日本語(+東アジア) 標準TeXの中の一つとして地位を占めるところまで達成できたように思う。 関係各位に御礼を申し上げる。 一方、2007年の開発当時を振り返ってみると、XeTeXやLuaTeXの台頭は 予想できたものの、8bit欧文LaTeX(pdfLaTeX)までもUnicode化が進展し 規定の文字コードがUTF-8になるところまでは想像が難しかった。 upTeX/upLaTeXは今まで欧文の処理はKnuth TeX以来の伝統的な8bitの 範囲にとどめていたが、今となっては和文(またはCJK)との2階建て構造が 複雑でわかりにくい上、XeLaTeXやLuaLaTeXのUnicodeを前提とした処理 とupLaTeXの欧文8bit部分が馴染まずに苦労することが増えてきた。その 結果LaTeXの進化についていけないだけでなくupLaTeXそのものの存続を 危ぶむ声も出てきている。 そこで、upTeX/upLaTeXが欧文16bitを扱えるようになり和文と欧文の どちらも「Unicode 1文字1トークン」で扱えるようになれば、そのような 危機的状況を回避する鍵になりそうだ。それも、具体的にはkcatcodeの 拡張による追加オプションとして、従来の欧文8bit動作への副作用なしに 実装できそうだ。 しがらみのあるソフトウェアの延命措置のきらいがあることは否めないが、 pTeX/pLaTeX系列のUnicode版後継者としての役割をこれからも引き続き 担っていくことを目指したい。 ◇ 主な開発方針 <0> pTeX の基本的な機能はそのままで、内部の和文処理を EUC/SJIS から Unicode に変更する。 jfm の使用、dvi命令(255)の拡張など、pTeX 独自の特殊な拡張や 組版のアルゴリズム等は一切さわらずに、そのまま受け継ぐ。 このため、dviware などは pTeX 用拡張とほぼ同等の特殊処理が要る。 欧文用 dviware では対応できない場合がある点では pTeX と同じ。 <1> Unicode 化においては、pTeX の自然な拡張を行い、 pTeX のいくつかの弱点を克服する。 この点において、必要なら pTeX からの改造量が多少増えるのは厭わない。 <2> pTeX との互換性は出来るだけ維持する努力をする。その一方、 Unicode の文字集合や構造を前提として見たときにあまりに不自然な部分は、 互換性の維持をあきらめる。 例えば、kcatcode の default 値、 kcatcode の切替えのブロックの単位など。 <3> 8bit 欧文コードの処理が可能になるよう、和文/欧文の切替え用の プリミティヴを拡張、新設する。 pTeX では極めて限定的だった、欧文 Babel との整合性が向上する。 内部 Unicode 化を本当に行っているのは CJKトークンだけであり、 欧文部分はオリジナルの欧文 TeX と同等である。 pTeX から見ると欧文部分の機能が向上しているように見えるが、 欧文 TeX から見ると pTeX が欧文 TeX の機能を阻害していた部分を取り除いただけである。 <4> (upTeX-2.00新規、実験的) 16bit 欧文コードの処理が可能になるよう、 和文/欧文の切替え用にkcatcodeを拡張する。 このとき欧文の文字コードはUnicodeのみを想定し、最大値 U+2E7F までとする。和文のみならず欧文も「Unicode 1文字1トークン」 (catcode 4bit + charcode 16bit) となる。フォントのメトリック としては OFM Level-0 を読み込んで用いるように拡張する。 8bit 欧文との混在も、kcatcodeの切り替えにより可能である。 フォントまで含めた安定な環境として提供できるにはまだ時間が掛かりそう であり、当面「実験的」と位置づけることにする。 <5> pTeX の和文トークンを CJKトークンとして扱い、 中国語/韓国語対応を強化する。 <6> pTeX の和文トークンの 16bit を単純に Unicode (UCS2等) 化すると 欧文トークン (catcode 4bit + charcode 16bit) と衝突してしまう。 これを回避する手法は何通りか考えられるが、 CJKトークンの上限の拡張を行い、 CJKトークンを (kcatcode 5bit+charcode 24bit) で扱う。 pTeX からの改造量はやや大きいが、欧文 TeX との対称性は良くなる。 <7> U+2xxxx (Supplimentary Ideograph Plane, SIP) や U+3xxxx (Tertiary Ideograph Plane, TIP) の漢字など BMP以上かつ全角幅の文字をサポートする。 BMP以上かつ全角幅以外の文字は、jfmの拡張によりサポートする。 <8> 日本ローカル色を薄めるだけの目的での機能変更、整理、削除は行わない。 \xkanjiskip, \euc などはそのままの名称、機能で維持する。 理由は、少々の手当で日本ローカル色が払拭できるはずもなく、 pTeX との互換性を下げるだけに過ぎない結果になるであろうから。 この方針により、pTeX が抱えていた弱点はいくつか解消できるものの、 pTeX の特殊性 (全角等幅フォント前提の jfm 等) は保たれているし、 pdfTeX など欧文 TeX の近年の動向から遠く離れたままであるし、 OpenType の新技術などを駆使できているわけでもない。 世界の最新の TeX 環境や他の Unicode 拡張 (XeTeX, LuaTeX 等)と 比較すると、旧くさく中途半端な印象を受けるかもしれない。 しかし、pTeX との互換性がほぼ 100% の Unicode 版 CJK TeX となり pTeX を中心に推移してきた日本の TeX ユーザーが 過去の資産を利用しつつ手早く Unicode のおいしい部分を享受するために、 的確な solution になっていると思う。 正直なところ、日本ローカル色は依然非常に強く 中韓の TeX ユーザーが使いたくなるものになっているかどうかの点で あまり期待は大きく持てないかもしれないが、 日本の TeX ユーザーが中国語/韓国語を混植するような用途には向いていると思う。 ◇ 主な仕様 <0> 名前をupTeX, upLaTeX と命名する。 unicode版pTeXという主旨で。 出来ることは欧文TeX + pTeXの和文拡張部分のUnicode版なので、 uTeX とか universal TeX はおこがましい。 <1> CJKトークンの内部コードとしてUnicodeを使用する。 入出力バッファのエンコーディングはUTF-8。 内部エンコーディングはほぼUTF-32(註1)。 <2> 入力ファイル(.texなど)はUTF-8とISO-2022-JPの自動判定。 出力ファイル(.log, .auxなど)はUTF-8。 <3> tfm(jfm)のエンコーディングはほぼUTF-32(註2)、 エンコーディング名は JY2, JT2 とする。 U+FFFF以下の文字では、jfmのフォーマットは従来のpTeXと互換である。 U+FFFFを越える文字は、defaultではU+2xxxx(SIP)の漢字を想定し、 chartype が defaultの 0 の全角等幅文字として組版する。 U+FFFF超えかつ可変文字幅を扱えるようjfmのフォーマットを 文字コード24bitに拡張するが、拡張jfmに対応したdviwareを必要とする。 <4> dvi, vfにはUnicodeスカラー値を2〜3バイトで記録する(註2)。 U+FFFF以下の文字はset2で、U+FFFFを越える文字はset3で扱う。 和文として扱える文字コードの最大値はUnicodeの最大値U+10FFFF。 さらに、0x220000以上0xFFFFFF以下をUnicode合成文字用の 内部文字コードとして使用する(upTeX-1.35新規)。 <5> 和文、欧文の切替えは、コードレンジのチェックに加えkcatcodeを見て行う。 kcatcode=16,17,18なら漢字,かな,和文その他記号(pTeXと同様)で、 kcatcode=15なら欧文8bit、非CJKの文字(新規)。 kcatcode=14(latin_ucs)なら欧文16bit Unicode、 非CJKの文字(upTeX-2.00新規)。 kcatcode=19ならhangul(新規)。hangul直後の改行は欧文同様 空白と看做すが、それ以外の点では、漢字と全く同じ動作になっている。 kcatcode=20ならmodifier(upTeX-1.35新規)。Unicodeで合成用の文字 または異体字セレクタ。 <6> 欧文と判定されればUTF-8の8bit可変長文字列として内部処理する。 オリジナルの欧文TeXと完全に互換の処理ができる。 すなわち、欧文LaTeXの\inputenc{utf8}やBabelが障害なく利用できる。 <7> (upTeX-2.00新規) kcatcode=14(latin_ucs)が設定された状態で UTF-8の入力バッファで8bit文字コード列が正規のUTF-8として U+2E7F 以下と読み取れるとき、Unicodeの欧文であると解釈して 符号位置 0x80～0x2E7F の欧文文字ノードを生成する。 オリジナルの欧文Omega/Alephと互換の処理ができる。 <8> 和文と判定されればpTeXと同様の処理ができる。 すなわち、組版はもちろん、 漢字,かなをコントロールワードに使う機能等が障害なく利用できる。 <9> kcatcodeの切替えはUnicodeのBlock毎に可能。 ( http://www.unicode.org/Public/UNIDATA/Blocks.txt ) ( ちなみに、オリジナルpTeXでは2バイト文字のうち上位バイト毎。 ) <10> 和文の内部コードは、kcatcode 5bit+charcode 24bit で処理する。 内部コードが欧文(catcode 4bit+charcode 16bit)と重なることはない。 <11> 従来のpTeXでは、kcatcodeの参照を文字コードからkcatcodeの表を引き 間接的に行う方法を行っている。この方法を ファイルなどからの読み込み時と内部処理時の両方で行っている。 upTeXでは、ファイルなどからの読み込み時は同様であるが、 内部処理時には、<10>でCJKトークン毎に振ったkcatcodeを読み込むように 変更した。たとえ同じ文字コードでもkcatcodeの途中変更を行えば、 CJKトークン毎に異なるkcatcodeを割り当てることが出来るようになる。 <12> 新しく \ucs プリミティヴを新設。 \char\ucs"301C, \kchar\ucs"301C はU+301C(波ダッシュ)になる。 <13> uptex, uplatex などでは -kanji=uptex と指定して 動くように実装した。 その他の漢字コード指定の場合は、 基本的に従来のpTeXと同様の結果になるはず。 <14> 各文字が実際のフォントで利用可能な文字かどうかの判定は uptex 本体では行わない。この判定は dviware で行うことになる。 「任意の部分実装を容認している Unicode において 文字集合の範囲の固定的な判定は不可能だ」という理由もあるが、 この仕様は pTeX でも同様となっている。 <15> 新しく \kchar, \kchardef プリミティヴをを追加。 \char`<文字>, \chardef では kcatcode=14かつ文字コードが128〜0x2E7Fの場合には16bit 欧文動作、 その他文字コードが255以下の場合には8bit 欧文動作、 256以上の場合には和文動作となる。 \kchar`<文字>, \kchardef では文字コード範囲によらず和文動作となる。 <16> (upTeX-2.00新規) 新しく ^^^^pqrs 記法を追加。そのときの kcatcodeの設定の状態に依らず欧文16bit Unicodeの U+PQRS になる。 欧文Omega/Alephと互換。 <17> set3を含むフォント(vf)を含むフォント(vf)を標準とする。 <18> ISO-2022-JP{-3,-2004}, EUC-JISX0213, Shift_JISX0213などの JIS X 0213系エンコーディングも使用可能にする案もあったが 開発凍結する。 (註1) 32bitではなく24bitで扱っている点で厳密にはUTF-32ではない。 あるいは、正規のUnicodeスカラー値(≒コードポイント)を 24bitで表したものといってもよい。 (註2) 正規のUnicodeスカラー値(≒コードポイント)と 等しい値を16/24bitで表したもの。 すなわち、UTF-32の下位16bit/24bitと等しい。 ◇ 内部処理の流れ (1) pTeX入力 [8bit可変長(UTF8)] ↓ <1> ptexenc [8bit可変長(UTF8)] ↓ (2) 入力バッファー [8bit可変長(UTF8)] ↓ <2> multistrlen,kcatcode等で和文/欧文を判定して変換 ↓ (3) 内部レジスター [和文5+24bit, 欧文4+16bit] { 最大29bit 欧文と和文で別構成※1 } ↓ <3> マクロ展開 ↓ (4) 組版処理 [和文5+24bit, 欧文4+16bit] (4a) tfm, jfm, ofmへのアクセス [和文24bit, 欧文4+16bit] ※2 <4a> ptexenc (4b) dviへの入出力 [和文5+24bit, 欧文4+16bit] ※3 <4b> ptexenc ↓ (5) 出力バッファー [8bit可変長(UTF8)] ↓ <5> ptexenc ↓ (6) 出力 (log, 端末など) [8bit可変長(UTF8)] ※1: 欧文はcatcode 4bit + 文字コード16bit (最大0x2E7F)。 和文はkcatcode 5bit + 文字コード24bit。 オリジナルpTeXでは、和文は文字コード16bit, kcatcodeは、文字コードを引数として表を参照して求めていたが、 upTeXでは、欧文と同等に(k)catcodeと文字コードの組となるように変更した。 和文/欧文トークンは 29bit を重ならないように使用していることになる。 U+10FFFFのUnicode最大値までを和文として処理できることを想定している。 ※2: U+FFFF超の文字は全角同幅(U+2xxxxの漢字など)を想定した場合 U+2xxxxのchar typeをdefaultの0番と解釈し、 jfmは従来のpTeX(16bit)の仕様の範囲で処理が可能。 U+FFFF超かつ可変幅は拡張jfmで対応する。 (2), (3), (4)のあたりで欧文8bit(TeX),欧文16bit(Omega/Aleph)との 共存も可能。 さらにOTPインタープリターを突っ込めば upTeX + Omega = upOmegaが出来る??? ◇ 文字コード関連のまとめ [凡例] ○:欧文、△:欧文8bit多byteの擬似的な動作 ■:和文、—:使用不可 token:内部トークンでの文字コード text:SJIS/EUC/UTF-8など入出力の文字コード ( ):defaultではない [欧文TeX] token text ^^ab \char 〜0x7F ○ ○ ○ ○ 〜0xFF ○ ○[a] ○ ○ 0x100〜 — △[b] — — [pTeX] token text ^^ab \char 〜0x7F ○ ○ ○ ○ 〜0xFF ○ —[c] ○[f] ○ 0x100〜 — —[d] — — 0x8000〜 ■ ■[e] — ■[g] [upTeX(v.0.10〜)] token text ^^ab \char \kchar 〜0x7F ○■[h] ○ [i] ○ ○[l] ■[o] 〜0xFF ○■[h] (○)■[j] ○ ○[m] ■[o] 0x100〜 ■ (△)■[k] — ■[n] ■[o] [upTeX(v.2.00〜) で kcatcode=14(latin_ucs) のとき] token text ^^^^abcd \char 〜0x7F ○ ○ ○ ○ 〜0xFF ○ ○[p] ○ ○ 〜0x2E7F ○ — ○ ○ 0x2E80〜 — — — — [a] 8bit1byteで扱うのが基本。[b]のためにこの領域が使われることもある。 [b] 8bit多byteの処理をactive文字化で実現する手法(inputenc,CJK-LaTeX等)がある。 [c] SJIS/EUCのパターンに合わない場合のみ通る。欧文TeXから見ると制限事項になる。 回避には、^^ab, \char などでするしかない。 [d] [b]の方法が使えない。欧文TeXから見ると制限事項になる。 回避には、^^ab, \char などでするしかない。 [e] 入力では8bit2byte。SJIS/EUCのパターンに合う場合のみ有効。 [f] ここの不具合解消によりpTeX+babelが実現可能になった。 [g] 和文／欧文はコードレンジで簡明に区別できる。 [h] 和文の場合はkcatcode付きで管理されるので、欧文と区別できる。 [i] 欧文のみ可能。和文は不可。 [j] defaultは和文(**)。kcatcodeの切り替えにより和文欧文化が可能。 [k] defaultは和文(**)。kcatcodeの切り替えにより欧文の8bit多byte扱いが可能。 [l] 欧文のみ可能。和文は不可。 [m] 欧文のみ可能。和文は不可。一部(例えば\char\jis"215F(×)など)がpTeX と非互換になる。 [n] 和文のみ可能。欧文は不可。pTeXとの互換性のため用意。 [o] 和文のみ可能。欧文は不可。 [p] UTF-8の可変長多バイトのみ可能であり、文字集合はUnicodeのみを想定する。 active文字化してはならない。 (**) "Latin-1 Letters" (0xAA, 0xBA, 0xC0..0xD6, 0xD8..0xF6, 0xF8..0xFF), "Latin Extended-A" (0x100..0x17F) の文字はupTeX-1.23より、 また "Latin Extended-B" (0x180..0x24F), "Latin Extended Additional" (0x1E00..0x1EFF) の文字はupTeX-1.24より defaultを欧文(not_cjk)とする設定を行った。 ◇ pTeX との対照表 ◎ デフォルトのエンコーディング JY1 → JY2 JT1 → JT2 ◎ min10系のフォント(オプション, uptex-1.xxの配布には含まない) min10.tfm → umin10.tfm min9.tfm → umin9.tfm min8.tfm → umin8.tfm min7.tfm → umin7.tfm min6.tfm → umin6.tfm min5.tfm → umin5.tfm goth10.tfm → ugoth10.tfm goth9.tfm → ugoth9.tfm goth8.tfm → ugoth8.tfm goth7.tfm → ugoth7.tfm goth6.tfm → ugoth6.tfm goth5.tfm → ugoth5.tfm min10.vf → umin10.vf min9.vf → umin9.vf min8.vf → umin8.vf min7.vf → umin7.vf min6.vf → umin6.vf min5.vf → umin5.vf goth10.vf → ugoth10.vf goth9.vf → ugoth9.vf goth8.vf → ugoth8.vf goth7.vf → ugoth7.vf goth6.vf → ugoth6.vf goth5.vf → ugoth5.vf ◎ jis.tfm系のフォント(オプション, uptex-1.xxの配布には含まない) jis.tfm → ujis.tfm jisn.tfm → ujisn.tfm jis-v.tfm → ujis-v.tfm jisn-v.tfm → ujisn-v.tfm jisg.tfm → ujisg.tfm jisng.tfm → ujisng.tfm jisg-v.tfm → ujisg-v.tfm jisng-v.tfm → ujisng-v.tfm jis.vf → ujis.vf jisn.vf → ujisn.vf jis-v.vf → ujis-v.vf jisn-v.vf → ujisn-v.vf jisg.vf → ujisg.vf jisng.vf → ujisng.vf jisg-v.vf → ujisg-v.vf jisng-v.vf → ujisng-v.vf ◎ rml.tfm系のフォント(オプション, uptex-1.xxの配布には含まない) rml.tfm → urml.tfm rmlv.tfm → urmlv.tfm gbm.tfm → ugbm.tfm gbmv.tfm → ugbmv.tfm ◎ upjisr-{hv}.tfm系のフォント(デフォルト、新規) ------- → upjisr-h.tfm (UniJIS-UTF16-HまたはUniJISup-UTF16-Hを想定) ------- → upjisg-h.tfm (UniJIS-UTF16-HまたはUniJISup-UTF16-Hを想定) ------- → upjisr-v.tfm (UniJIS-UTF16-VまたはUniJISup-UTF16-Vを想定) ------- → upjisg-v.tfm (UniJIS-UTF16-VまたはUniJISup-UTF16-Vを想定) ------- → upjisr-hq.tfm (UniJIS-UCS2-Hを想定) ------- → upjisg-hq.tfm (UniJIS-UCS2-Hを想定) ------- → upjisr-h.vf (UniJIS-UTF16-HまたはUniJISup-UTF16-Hを想定, set3使用) ------- → upjisg-h.vf (UniJIS-UTF16-HまたはUniJISup-UTF16-Hを想定, set3使用) ------- → upjisr-v.vf (UniJIS-UTF16-VまたはUniJISup-UTF16-Vを想定, set3使用) ------- → upjisg-v.vf (UniJIS-UTF16-VまたはUniJISup-UTF16-Vを想定, set3使用) ------- → upjisr-hq.vf (UniJIS-UCS2-Hを想定) ------- → upjisg-hq.vf (UniJIS-UCS2-Hを想定) ------- → uprml-h.tfm (UniJIS-UTF16-HまたはUniJISup-UTF16-Hを想定) ------- → upgbm-h.tfm (UniJIS-UTF16-HまたはUniJISup-UTF16-Hを想定) ------- → uprml-v.tfm (UniJIS-UTF16-VまたはUniJISup-UTF16-Vを想定) ------- → upgbm-v.tfm (UniJIS-UTF16-VまたはUniJISup-UTF16-Vを想定) ------- → uprml-hq.tfm (UniJIS-UCS2-Hを想定) ------- → upgbm-hq.tfm (UniJIS-UCS2-Hを想定) ◎ 各種ファイル ptex.ini → uptex.ini ptex.tex → uptex.tex (min10ベース → upjisr-hベース) kinsoku.tex → ukinsoku.tex platex.ini → uplatex.ini platex.ltx → uplatex.ltx pldefs.ltx → upldefs.ltx jy1mc.fd → jy2mc.fd (min10ベース → upjisr-hベース) jy1gt.fd → jy2gt.fd (goth10ベース → upjisg-hベース) jt1mc.fd → jt2mc.fd (tmin10ベース → upjisr-vベース) jt1gt.fd → jt2gt.fd (tgoth10ベース → upjisg-vベース) jarticle.cls → ujarticle.cls tarticle.cls → utarticle.cls jreport.cls → ujreport.cls treport.cls → utreport.cls jbook.cls → ujreport.cls tbook.cls → utreport.cls tsize10.clo → utsize10.clo tsize11.clo → utsize11.clo tsize12.clo → utsize12.clo tbk10.clo → utbk10.clo tbk11.clo → utbk11.clo tbk12.clo → utbk12.clo ◎ CJK対応新規フォント upjpnrm-{h,v}.{tfm,vf} (set3使用) upjpngt-{h,v}.{tfm,vf} (set3使用) upschrm-{h,v}.{tfm,vf} (set3使用) upschgt-{h,v}.{tfm,vf} (set3使用) uptchrm-{h,v}.{tfm,vf} (set3使用) uptchgt-{h,v}.{tfm,vf} (set3使用) upkorrm-{h,v}.{tfm,vf} upkorgt-{h,v}.{tfm,vf} upstsl-{h,v}.tfm upstht-{h,v}.tfm upmsl-{h,v}.tfm upmhm-{h,v}.tfm uphysmjm-{h,v}.tfm uphygt-{h,v}.tfm ※ Adobe Acrobat Reader 4 は以下の`generic fonts'を認識するそうだ。 (Ref. http://project.ktug.or.kr/omega-cjk/tug2004-preprint.pdf) Serif Sans Serif Chinese Simplified STSong-Light STHeiti-Regular Chinese Traditional MSung-Light MHei-Medium Japanese Ryumin-Light GothicBBB-Medium Korean HYSMyeongJo-Medium HYGoThic-Medium ◇ kcatcode のデフォルト値 kcatcodeの意味は、14: latin_ucs, 15: not_cjk, 16: kanji, 17: kana, 18: other_kchar, 19: hangul, 20: modifier kcatcodeが14(latin_ucs)または15(not_cjk)の場合は欧文扱いになる。 kcatcodeは原則としてUnicodeのblock毎に与えられる。 (Ref. http://www.unicode.org/Public/UNIDATA/Blocks.txt) ただし、例外の文字集合が7個ある。 さらに、Unicode合成文字を表すためにUnicode範囲外をupTeXの内部コードとして利用する。 文字コード値0x0080以上のブロックでは原則18(other_kchar)が設定されている。 下記の表にはそれ以外の値のものを記載した。左端はブロックの通し番号。 ○Unicode blockに準拠 (0x00) 0x0000.. 0x007F <15> Basic Latin (0x02) 0x0100.. 0x017F <15> Latin Extended-A (0x03) 0x0180.. 0x024F <15> Latin Extended-B (0x25) 0x1100.. 0x11FF <19> Hangul Jamo (0x46) 0x1E00.. 0x1EFF <15> Latin Extended Additional (0x68) 0x2E80.. 0x2EFF <16> CJK Radicals Supplement (0x69) 0x2F00.. 0x2FEF <16> Kangxi Radicals (0x6C) 0x3040.. 0x309F <17> Hiragana (0x6D) 0x30A0.. 0x30FF <17> Katakana (0x6E) 0x3100.. 0x312F <16> Bopomofo (0x6F) 0x3130.. 0x318F <19> Hangul Compatibility Jamo (0x70) 0x3190.. 0x319F <16> Kanbun (0x71) 0x31A0.. 0x31BF <16> Bopomofo Extended (0x72) 0x31C0.. 0x31EF <16> CJK Strokes (0x73) 0x31F0.. 0x31FF <17> Katakana Phonetic Extensions (0x76) 0x3400.. 0x4DBF <16> CJK Unified Ideographs Extension A (0x78) 0x4E00.. 0x9FFF <16> CJK Unified Ideographs (0x88) 0xA960.. 0xA97F <19> Hangul Jamo Extended-A (0x93) 0xAC00.. 0xD7AF <19> Hangul Syllables (0x94) 0xD7B0.. 0xD7FF <19> Hangul Jamo Extended-B (0x99) 0xF900.. 0xFAFF <16> CJK Compatibility Ideographs (0x9C) 0xFE00.. 0xFE0F <20> Variation Selectors (0x115) 0x1AFF0..0x1AFFF <17> Kana Extended-B (0x116) 0x1B000..0x1B0FF <17> Kana Supplement (0x117) 0x1B100..0x1B12F <17> Kana Extended-A (0x118) 0x1B130..0x1B16F <17> Small Kana Extension (0x145) 0x20000..0x2A6FF <16> CJK Unified Ideographs Extension B (0x146) 0x2A700..0x2B73F <16> CJK Unified Ideographs Extension C (0x147) 0x2B740..0x2B81F <16> CJK Unified Ideographs Extension D (0x148) 0x2B820..0x2CEAF <16> CJK Unified Ideographs Extension E (0x149) 0x2CEB0..0x2F7FF <16> CJK Unified Ideographs Extension F (0x14A) 0x2EBF0..0x2EE5F <16> CJK Unified Ideographs Extension I (0x14B) 0x2F800..0x2FFFF <16> CJK Compatibility Ideographs Supplement (0x14C) 0x30000..0x3134F <16> CJK Unified Ideographs Extension G (0x14D) 0x31350..0x323AF <16> CJK Unified Ideographs Extension H (0x14E) 0x323B0..0x3347F <16> CJK Unified Ideographs Extension J (Unicode 17.0予定) (0x15B) 0xE0100..0xE01EF <20> Variation Selectors Supplement (上記の文字の範囲は実装に基づいており、Blocks.txtに記述されている範囲より広い場合がある) ○Unicode blockの例外 (0x1F9) 0x3099, 0x309A <20> Combining Kana (Semi-)Voiced Sound Mark (0x1FA) 0x20E3 <20> Combining Enclosing Keycap (0x1FB) 0x1F1E6..0x1F1FF <20> Regional Indicator Symbol letters (0x1FC) 0x1F3FB..0x1F3FF <20> Emoji Modifier Fitzpatric Type1..6 (0x1FD) 0xAA, 0xBA, 0xC0..0xD6, 0xD8..0xF6, 0xF8..0xFF <15> Latin-1 Letters (0x1FE) 0xFF10..0xFF19, 0xFF21..0xFF3A, 0xFF41..0xFF5A <17> Fullwidth digit and latin alphabet (0x1FF) 0xFF66..0xFF6F, 0xFF71..0xFF9D <17> Halfwidth katakana ○Unicodeの範囲外を合成文字に対応するupTeXの内部コードとして利用する (0x170) 0x220000..0x23FFFF <17> Kana with Voiced Sound Mark (0x171) 0x240000..0x25E6E5 <17> Kana with Semi-Voiced Sound Mark (0x172) 0x25E6E6..0x25FFFF <18> Emoji Flag Sequence (0x173) 0x260000..0x2FFFFF <18> Emoji with Modifier Fitzpatrick (0x175) 0x400000..0x7FFFFF <16> Standardized Variation Sequence (0x176) 0x800000..0x80007F <18> Emoji Keycap Sequence (0x177) 0x800080..0xFFFFFF <16> Ideographic Variation Sequence, VS17..VS48 (0x178) 0x1000000..0x43FFFFF <16> Ideographic Variation Sequence, VS49..VS256 Ideographic Description Characters は upTeX 1.29で <16> から <18> に変更した。 ◇ Unicode合成文字の扱い (upTeX-1.35以降) Unicodeでは一つの文字(書記素)を表すために複数のコードポイントの連なり(シーケンス)で 示すことが規定されている文字がある。例えば異体字セレクタや絵文字シーケンスなどが含まれる。 異体字セレクタによる異体字の指定(同じ文字の別の字形になる)と 合成用文字による文字の合成(別の字になる)とは本来意味が異なるが、 ここではそれらをまとめてUnicode合成文字と呼ぶ。 upTeXの処理の入口において基底文字(base)の直後にmodifierが現れた場合には それを合成文字用拡張文字コード(内部コード)に置き換えてノード化し 内部処理を経てDVIファイルへの書き込みを行う。 dviwareはvf経由またはdviware本体で合成文字用拡張文字コードを扱えるようにする。 upTeXで扱えるUnicode合成文字は特定の組み合わせに限定する。 UTF-8では必ず正規のUnicodeのコードポイントの列に戻して表現する。 対応しているシーケンスと合成文字用拡張文字コード(内部コード)は以下。 <1> 仮名+(半)濁点 base: 平仮名、片仮名、変体仮名 mod: U+3099, U+309A 内部コード: ((mod - 0x3099) << 17) + 0x220000 + base 内部コードの範囲: 0x220000..0x25E6E5 <2> 絵文字(国旗) RGI Emoji Flag Sequence base: U+1F1E6..1F1FF mod: U+1F1E6..1F1FF 内部コード: ((base & 0xFF) << 8) + (mod & 0xFF) + 0x250000 内部コードの範囲: 0x25E6E6..0x25FFFF <3> 絵文字(肌色) base: 特定の絵文字 mod: U+1F3FB..U+1F3FF 内部コード: ((mod - 0x1F3FB) << 17) + 0x260000 + base 内部コードの範囲: 0x260000..0x2FFFFF <4> キーキャップ RGI Emoji Keycap Sequence (base+mod1+mod2のシーケンス) base: U+0000..007F mod1: U+FE0F (SVS) mod2: U+20E3 内部コード: 0x800000 + base base+mod1の内部コードの範囲: 0x7C0000..0x7C007F 3文字シーケンスの内部コードの範囲: 0x800000..0x80007F <5> SVS (Standardized Variation Sequence) base: 漢字他 mod: U+FE00..FE0F 内部コード: ((mod - 0xFE00) << 18) + 0x400000 + base 内部コードの範囲: 0x400000..0x7FFFFF <6> IVS (Ideographic Variation Sequence) base: 漢字 mod: U+E0100..E011F 内部コード: ((mod - 0xE0100) << 18) + 0x800000 + base 内部コードの範囲: 0x800080..0xFFFFFF ◇ upbibtex の is.kanji.str$ upbibtex(内部コード -kanji-internal=uptex)の is.kanji.str$ の返り値は以下に示すとおりとする。 以下に明示されていないブロックは現在falseが返る実装となっているが仕様としては未定義とする。 trueに変更した方が利便性が高い等の判断があった場合、将来の版で変更する可能性もある。 ◎trueのブロック upTeXのkcatcodeのデフォルト値が16(kanji),17(kana),19(hangul)のブロックは返り値をtrueとする。 ◎falseのブロック 以下に示すブロックは返り値をfalseとする。 ○Unicode blockに準拠 (0x00) 0x0000.. 0x007F <15> Basic Latin (0x02) 0x0100.. 0x017F <15> Latin Extended-A (0x03) 0x0180.. 0x024F <15> Latin Extended-B 0x0370.. 0x03FF <18> Greek and Coptic 0x0400.. 0x04FF <18> Cyrillic 0x0500.. 0x052F <18> Cyrillic Supplement 0x1C80.. 0x1C8F <18> Cyrillic Extended-C (0x46) 0x1E00.. 0x1EFF <15> Latin Extended Additional 0x1F00.. 0x1FFF <18> Greek Extended 0x2C60.. 0x2C7F <18> Latin Extended-C 0x2DE0.. 0x2DFF <18> Cyrillic Extended-A 0x3000.. 0x303F <18> CJK Symbols and Punctuation 0x3200.. 0x32FF <18> Enclosed CJK Letters and Months 0x3300.. 0x33FF <18> CJK Compatibility 0xA640.. 0xA69F <18> Cyrillic Extended-B 0xA720.. 0xA7FF <18> Latin Extended-D 0xAB30.. 0xAB6F <18> Latin Extended-E 0xFE30.. 0xFE4F <18> CJK Compatibility Forms (全角英数、半角カナを除く) 0x10780..0x107BF <18> Latin Extended-F ○Unicode blockの例外 (0x1FD) 0xAA, 0xBA, 0xC0..0xD6, 0xD8..0xF6, 0xF8..0xFF <15> Latin-1 Letters ◇ ukinsoku.tex に関する注意事項 ukinsoku.tex で行なった禁則ペナルティに関する設定において、 UnicodeとCJK(JIS X 0213等)の文字を想定して設定されたものの中に 文字コードが 0x80..0xFF のものを含んでいる。 それらの設定は仕様上、8bit欧文の文字にも同時に作用してしまう。 8bit欧文がT1の場合について下記にまとめた。 この動作が不都合な場合は、ユーザー各位の利用状況に応じて適宜 設定を変更するようお願いする。 文字コード Unicode T1 0xA1 U+00A1 (¡) ą {\k a} 0xAA U+00AA (ª) ł {\l} 0xAB U+00AB («) ń {\@tabacckludge'n} 0xB2 U+00B2 (²) š {\v s} 0xB3 U+00B3 (³) ş {\c s} 0xB7 U+00B7 (·) ů {\r u} 0xB9 U+00B9 (¹) ź {\@tabacckludge'z} 0xBA U+00BA (º) ž {\v z} 0xBB U+00BB (») ż {\.z} 0xBF U+00BF (¿) £ {\textsterling} ◇ 動作状況 ◎ uptex-2.xxの配布に含めたもの uptex 動いている。無問題。 ◎ 別の配布に含めたもの otfパッケージ japanese-otf-uptex として公開、CTANに登録した。 (以前は otfbeta-uptex-x.xx.tar.xz として公開していた。) TeX Live svn に r25264 あたりで取り込まれた。 プロポーショナル仮名にも対応済み。 CTAN投稿版は japanese-otf に含まれるようになった。 https://ctan.org/pkg/japanese-otf https://github.com/t-tk/japanese-otf-uptex convbkmk.rb dvipsでのbookmark作成のためのrubyスクリプト。 さらに、out2uni相当動作の-oオプションも追加した。 convbkmk としてCTANに登録した。 https://ctan.org/pkg/convbkmk https://github.com/t-tk/convbkmk CMap UTF8-UTF16 TeX Live svn に r26540 で取り込まれた。 一次配布は http://www.t-lab.opal.ne.jp/tex/uptex.html uptex-fonts の配布に含まれている。 https://github.com/texjporg/uptex-fonts ◎ 日本語TeX開発コミュニティに移管したもの uppltotf,uptftopl,updvitype TeX Live svn r65178 で ppltotf,ptftopl,pdvitype とソース、バイナリを統合した。 upbibtex TeX Live svn r65178 で pbibtex とソース、バイナリを統合した。 jalpha.bst 使用時に一部のエントリーでeuc動作と同等にならないが、許容範囲とする。 upjisr-h.tfmなど JIS X 0208の範囲ではほぼUnicodeに移植出来ていると思う。 JIS X 0213の追加の約物は一応入れた。 その他 JIS X 0208/0213 以外の約物はAJ1-6でめぼしいものはないようだ。 半角カナにも対応済。 upjisr-h.vfなどにBMP外の文字も一部追加した。 以降、開発元は下記に移管。 https://github.com/texjporg/uptex-fonts ukinsoku.tex JIS X 0213 に対応した。 以降、uptex.tex, uptex.iniも含め開発元は下記に移管。 https://github.com/texjporg/uptex-base uplatex 動いている。無問題。 以降、開発元は下記に移管。 https://github.com/texjporg/uplatex makejvf 簡単な対応を施した。 オプション -u, -3, -J, -U, -H, -i を新設した。 以降、開発元は下記に移管。 https://github.com/texjporg/tex-jp-build ptexenc TeX Live svn に r23549〜r25028 あたりで取り込まれた。 JIS→Unicode の変換表は r29213 で見直した。 かなの合成文字は r38704 で取り込まれた。 以降、開発元は下記に移管。 https://github.com/texjporg/tex-jp-build ◎ TeX Live に取り込んでいただいたもの euptex TeX Live の Build/source/web2c で本配布の uptexdir の置き換えでOK euptexdir 以下は新しい uptex との組合わせ可能で euptex が作成出来る。 dvips TeX Live 2010 に取り込まれた。 dvipdfmx TeX Live svn に r24509 あたりで取り込まれた。 set3も含めて動いている。 bookmark 作成は dvipdfmxの--pdfm-str-utf8オプションまたは、 UTF8-UCS2, UTF8-UTF16 の CMap または、 convbkmk.rbの-oオプションを必要とする。 dvi2tty TeX Live svn に r24634 あたりで取り込まれた。 dvi2tty の NTT JTeX/pTeX 対応版を upTeX 対応にした。 オプション -J を変更し、 -U, -E を新設した。 さらに、T1,TS1,OT2,T2A,T2B,T2C,X2エンコーディング対応機能が TeX Live に r39942 あたりで取り込まれた。 https://github.com/t-tk/dvi2tty mendex TeX Live r33962 あたりで、見出しをUnicode対応とした。 さらに r47721 あたりで見出しのデフォルトエンコーディングをUTF-8とした。 https://github.com/texjporg/tex-jp-build upmendex mendex をベースに新規に作成した。 mendex の内部コードをUnicode化し、ICUによるソート、 読みをJIS X 0213のかなに対応、CJK対応、ラテン文字(含非英語)対応、 キリル文字対応、ギリシャ文字対応となっている。 TeX Live svn に r39638 あたりで取り込まれた。 https://github.com/t-tk/upmendex-package upmpost TeX Live r35188 あたりでupmetapostの名前で取り込まれ、 現在upmpostの名前になっている。 ただし、おそらくuptex-0.30の頃と同様、 日本語vfの領域を食い過ぎで多書体ができないと思われる。 Unicodeのファイル名 Unix/LinuxではlocaleがUTF-8ならば使用出来る。 Windowsでは、TeX Live 2014 に取り込まれた。 ◎ 現在の配布に含んでいないもの xdvi uptex-0.30ではset3も含めて動いている。無問題。 uptex-2.xxの配布には含まない。 dviout set2の範囲では改造無しでフォントの設定のみでほぼ動いている。 set3の範囲は文字化けしてしまうが、落ちることはない。 OTFパッケージの \CID{} が Unicode 経由なのは、 pLaTeX と同様。 http://oku.edu.mie-u.ac.jp/~okumura/texfaq/qa/51610.html http://oku.edu.mie-u.ac.jp/~okumura/texfaq/qa/51705.html の問題点の御報告がある。 開発版, CTAN版で修正案を取り入れていただいた。 http://tug.org/svn/dviout?view=revision&revision=178 https://ctan.org/pkg/dviout utfパッケージ uptex-0.30では動いている。 uptex-2.xxの配布には含まない。 ◇ 今後の課題、要検討事項など < 内部実装関連 > [1] Unicodeで複数のコードポイントを必要とする文字(IVS, 文字合成で表される仮名等)を使えるようにする。(upTeX-1.35以降取り組み中) [2] 16bit欧文のサポートを充実させる。(upTeX-2.00以降取り組み中) < dviware, 外部ソフト関連 > [3] upmpost で多書体が使えるようにする。 < その他 > [4] ドキュメントの充実。 [5] 英語ドキュメントを書く。