path: root/language/japanese/uptex-base/01uptex_doc_utf8.txt

upTeX, upLaTeX  --- 内部unicode版 pTeX, pLaTeX の実装
2020.02.22 Ver1.26
TANAKA, Takuji   ttk(at)t-lab(dot)opal(dot)ne(dot)jp

◇ upTeX開発のねらい
  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の申
し分のない高みを出発点として、無理のない自然な拡張を着実に行っていけ
ば、成果を出しつつ目標に近づけるであろうと目論んでいる。


◇ 主な開発方針
<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> pTeX の和文トークンを CJKトークンとして扱い、
    中国語/韓国語対応を強化する。
<5> pTeX の和文トークンの 16bit を単純に Unicode (UCS2等) 化すると
    欧文トークン (catcode 4bit + charcode 8bit) と衝突してしまう。
    これを回避する手法は何通りか考えられるが、
    CJKトークンの上限の拡張を行い、
    CJKトークンを (kcatcode 5bit+charcode 24bit) で扱う。
    pTeX からの改造量はやや大きいが、欧文 TeX との対称性は良くなる。
<6> U+2xxxx (Supplimentary Ideograph Plane, SIP) の漢字など
    BMP以上かつ全角幅の文字はサポートする。
    BMP以上かつ全角幅以外の文字は、jfmの拡張によりサポートする方針だが、
    dviware の対応状況に差が出る可能性を考慮しオプション扱いとする。
<7> 日本ローカル色を薄めるだけの目的での機能変更、整理、削除は行わない。
    \xkanjiskip, \euc などはそのままの名称、機能で維持する。
    理由は、少々の手当で日本ローカル色が払拭できるはずもなく、
    pTeX との互換性を下げるだけに過ぎない結果になるであろうから。
この方針により、pTeX が抱えていた弱点はいくつか解消できるものの、
pTeX の特殊性 (全角等幅フォント前提の jfm 等) は保たれているし、
pdfeTeX など欧文 TeX の近年の動向から遠く離れたままであるし、
欧文部分 は 8bit のままであるし、
OpenType の新技術などを駆使できているわけでもない。
世界の最新の TeX 環境や
他の Unicode 拡張 (Omega/Aleph, 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)のエンコーディングはUCS-2。
    エンコーディング名は JY2, JT2 とする。
    U+FFFFを越える文字は、U+2xxxx(SIP)の漢字を想定し、
    jfmのフォーマットが従来のpTeXのものを用い
    chartype が defaultの 0 の全角文字として組版する。
    jfmのフォーマットは文字コード24bitを扱えるように拡張するが、
    dviwareの拡張jfmへの対応が進むまで当面オプションとする。
<4> dvi, vfにはUnicodeスカラー値を2〜3バイトで記録する(註2)。
    U+FFFF以下の文字はset2で、U+FFFFを越える文字はset3で扱う。
    和文として扱える文字コードの最大値はUnicodeの最大値U+10FFFF。
<5> 和文、欧文の切替えは、コードレンジのチェックに加えkcatcodeを見て行う。
    kcatcode=16,17,18なら漢字,かな,和文その他記号(pTeXと同様)で、
    kcatcode=15なら欧文、非CJKの文字(新規)。
    kcatcode=19ならhangul(新規)。hangul直後の改行は欧文同様、
    空白と看做すが、それ以外の点では、漢字と全く同じ動作になっている。
<6> 欧文と判定されればUTF-8の8bit可変長文字列として内部処理する。
    オリジナルの欧文TeXと完全に互換の処理ができる。
    すなわち、欧文LaTeXの\inputenc{utf8}やBabelが障害なく利用できる。
<7> 和文と判定されればpTeXと同様の処理ができる。
    すなわち、組版はもちろん、
    漢字,かなをコントロールワードに使う機能等が障害なく利用できる。
<8> kcatcodeの切替えはUnicodeのBlock毎に可能。
    ( http://www.unicode.org/Public/UNIDATA/Blocks.txt )
    ( ちなみに、オリジナルpTeXでは2バイト文字のうち上位バイト毎。 )
<9> 和文の内部コードは、kcatcode 5bit+charcode 24bit で処理する。
   内部コードが欧文(catcode 4bit+charcode 8bit)と重なることはない。
<10> 従来のpTeXでは、kcatcodeの参照を文字コードからkcatcodeの表を引き
   間接的に行う方法を行っている。この方法を
   ファイルなどからの読み込み時と内部処理時の両方で行っている。
   upTeXでは、ファイルなどからの読み込み時は同様であるが、
   内部処理時には、<9>でCJKトークン毎に振ったkcatcodeを読み込むように
   変更した。たとえ同じ文字コードでもkcatcodeの途中変更を行えば、
   CJKトークン毎に異なるkcatcodeを割り当てることが出来るようになる。
<11> 新しく \ucs プリミティヴを新設。
    \char\ucs"301C, \kchar\ucs"301C はU+301C(波ダッシュ)になる。
<12> uptex, uplatex などでは -kanji=uptex と指定して
   動くように実装した。
   その他の漢字コード指定の場合は、
   基本的に従来のpTeXと同様の結果になるはず。
<13> 各文字が実際のフォントで利用可能な文字かどうかの判定は
   uptex 本体では行わない。この判定は dviware で行うことになる。
   「任意の部分実装を容認している Unicode において
   文字集合の範囲の固定的な判定は不可能だ」という理由もあるが、
   この仕様は pTeX でも同様となっている。
<14> 新しく \kchar, \kchardef プリミティヴをを追加。
   \char`<文字>, \chardef では文字コードが255以下の場合には欧文動作、
   256以上の場合には和文動作となる。
   \kchar`<文字>, \kchardef では文字コード範囲によらず和文動作となる。
<15> 従来デフォルトのフォントはset2の範囲で済むようにし、
   set3を含むフォント(vf)はオプションとしていたが、
   dviwareのset3対応の普及が進んでおり
   2018年2月よりset3を含むフォント(vf)を標準とした。
<16> 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+8bit] { 最大29bit 欧文と和文で別構成※1 }
↓
<3> マクロ展開
↓
(4) 組版処理 [和文5+24bit, 欧文4+8bit]
(4a) tfm, jfm, (ofm)へのアクセス [和文16bit, 欧文4+8bit] ※2
<4a> ptexenc
(4b) dviへの入出力 [和文5+24bit, 欧文4+8bit] ※3
<4b> ptexenc
↓
(5) 出力バッファー [8bit可変長(UTF8)]
↓
<5> ptexenc
↓
(6) 出力 (log, 端末など) [8bit可変長(UTF8)]

※1: 欧文はcatcode 4bit + 文字コード8bit
(Omegaではcatcode 4bit + 文字コード16bitだが、Omegaへの拡張を視野にいれたい。)
和文はkcatcode 5bit + 文字コード24bit。
オリジナルpTeXでは、和文は文字コード16bit,
kcatcodeは、文字コードを引数として表を参照して求めていたが、
upTeXでは、欧文と同等に(k)catcodeと文字コードの組となるように変更した。
和文/欧文トークンは 29bit を重ならないように使用していることになる。
U+10FFFFのUnicode最大値までを和文として処理できることを想定している。
U+1xxxxの文字は考慮していない。Omegaの拡張的アプローチが必要か。
※2: U+FFFF超の文字は当面U+2xxxxの漢字のみを想定し、
U+2xxxxのchar typeをdefaultの0番と解釈することにすれば、
jfmは当面拡張する必要がない。
(2), (3), (4)のあたりで欧文8bit(TeX)との共存も可能。
欧文のcatcodeで使用しているレンジをさらに上位バイトに移動し、
和文24bit, 欧文16bit(Omega) と共存可能にし、
ptexencにOTPインタープリターを突っ込み、
ofmとjfmの混在した組版を可能にすれば
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]

[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] 和文のみ可能。欧文は不可。
(**) "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の意味は、15: not_cjk, 16: kanji, 17: kana, 18: other_kchar, 19: hangul
kcatcodeが15(not_cjk)の場合は欧文扱いになる。
kcatcodeは原則としてUnicodeのblock毎に与えられる。
(Ref. http://www.unicode.org/Public/UNIDATA/Blocks.txt)
ただし、例外の文字集合が3個ある。
文字コード値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
 (0x24)  0x1100.. 0x11FF  <19>  Hangul Jamo
 (0x45)  0x1E00.. 0x1EFF  <15>  Latin Extended Additional
 (0x67)  0x2E80.. 0x2EFF  <16>  CJK Radicals Supplement
 (0x68)  0x2F00.. 0x2FEF  <16>  Kangxi Radicals
 (0x69)  0x2FF0.. 0x2FFF  <16>  Ideographic Description Characters
 (0x6B)  0x3040.. 0x309F  <17>  Hiragana
 (0x6C)  0x30A0.. 0x30FF  <17>  Katakana
 (0x6D)  0x3100.. 0x312F  <16>  Bopomofo
 (0x6E)  0x3130.. 0x318F  <19>  Hangul Compatibility Jamo
 (0x6F)  0x3190.. 0x319F  <16>  Kanbun
 (0x70)  0x31A0.. 0x31BF  <16>  Bopomofo Extended
 (0x71)  0x31C0.. 0x31EF  <16>  CJK Strokes
 (0x72)  0x31F0.. 0x31FF  <17>  Katakana Phonetic Extensions
 (0x75)  0x3400.. 0x4DBF  <16>  CJK Unified Ideographs Extension A
 (0x77)  0x4E00.. 0x9FFF  <16>  CJK Unified Ideographs
 (0x87)  0xA960.. 0xA97F  <19>  Hangul Jamo Extended-A
 (0x92)  0xAC00.. 0xD7AF  <19>  Hangul Syllables
 (0x93)  0xD7B0.. 0xD7FF  <19>  Hangul Jamo Extended-B
 (0x98)  0xF900.. 0xFAFF  <16>  CJK Compatibility Ideographs
 (0x103) 0x1B000..0x1B0FF <17>  Kana Supplement
 (0x104) 0x1B100..0x1B12F <17>  Kana Extended-A
 (0x105) 0x1B130..0x1B16F <17>  Small Kana Extension
 (0x129) 0x20000..0x2A6FF <16>  CJK Unified Ideographs Extension B
 (0x12A) 0x2A700..0x2B73F <16>  CJK Unified Ideographs Extension C
 (0x12B) 0x2B740..0x2B81F <16>  CJK Unified Ideographs Extension D
 (0x12C) 0x2B820..0x2CEAF <16>  CJK Unified Ideographs Extension E
 (0x12D) 0x2CEB0..0x2F7FF <16>  CJK Unified Ideographs Extension F
 (0x12E) 0x2F800..0x2FFFF <16>  CJK Compatibility Ideographs Supplement
 (0x12F) 0x30000..0x3134F <16>  CJK Unified Ideographs Extension G
(上記の文字の範囲は実装に基づいており、Blocks.txtに記述されている範囲より広い場合がある)
○Unicode blockの例外
 (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


◇ 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-1.xxの配布に含めたもの
uptex     動いている。無問題。
uppltotf  動いている。無問題。
uptftopl  動いている。無問題。
updvitype 動いている。無問題。
upbibtex  ほぼ動いている。しかし、jalpha.bst 使用時に
  一部のエントリーでeuc動作と同等にならない問題がある。
ukinsoku.tex  JIS X 0213 に対応した。
◎ 別の配布に含めたもの
otfパッケージ  japanese-otf-uptex として公開、CTANに登録した。
  (以前は otfbeta-uptex-x.xx.tar.xz として公開していた。)
  TeX Live svn に r25264 あたりで取り込まれた。
  プロポーショナル仮名にも対応済み。
  https://ctan.org/pkg/japanese-otf-uptex
  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開発コミュニティに移管したもの
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
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も含めて動いている。
  ただし、set3で、「内部コードがUTF-32, CMapがUniXXX-UTF16」であること
  を仮定したハードコーディングになっているおり、柔軟性は乏しい。
  bookmark 作成は 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-1.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
  の問題点の御報告がある。
  開発版で修正案を取り入れていただいた。
  (Ref. http://tug.org/svn/dviout?view=revision&revision=178 )
utfパッケージ  uptex-0.30では動いている。
  uptex-1.xxの配布には含まない。


◇ 今後の課題、要検討事項など
< 内部実装関連 >
[1] pdfTeX 拡張機能の追加は?
[2] Unicodeで複数のコードポイントを必要とする文字(IVS,
  文字合成で表される仮名等)を使えるようにする。
< dviware, 外部ソフト関連 >
[3] upmpost で多書体が使えるようにする。
[4] upbibtex で、jalpha.bst 使用時に
  一部のエントリーでeuc動作と同等にならない問題点の解決。
< その他 >
[5] ドキュメントの充実。
[6] 英語ドキュメントを書く。