This page is for discussion of Kanji (Han script) and/or vertical typesetting.
このページは，漢字と/または縦組を必要とする言語に関する話題を扱うページです．
最終的に，国際標準を作ろうとしている方々にコミットすることを目標にします．
(議論に使用する言語に制限は設けませんが，
ときどき英語のサマリーなどを作ってくださる方がいらっしゃると嬉しいです．)
本当にできて欲しいこと (定義やアルゴリズムの世界) と，
存在する実装 (プログラミングの世界) の両方を，
きちんと区別して議論できるといいと思います．
存在する実装は，直接的に再生産の手助けになりますが，
本当にできて欲しいことがわからないと，
制限された/間違った実装を引きずることになりかねません．
本当にできて欲しいこと †
CJK における縦組み †
- 簡体字中国語、韓国語使用圏において現在出版されている書籍、新聞などの本文はほとんど横組み (TLT) になっている。書籍の背表紙では、中国語では縦組み (RTT) がほとんどで、韓国語では横組みの-90度回転 (RTR) が若干あるものの多数は縦組み (RTT) である。日本と比較して縦組みの需要ははるかに少ないものの、完全にゼロというわけにはいかない、といったところと思われる。これに対して繁体字中国語圏（台湾等）では縦書きがよく使われる。
- CJK の縦組みの PostScript/PDF や TrueType/OpenType などでの扱いは CJK の間で同様であり、課題や解決法も似ている。協調して国際的な開発の場に乗せるのが望ましい。
- 現状 Omega 系統の縦組みの PDF 出力は、マトモでないようだ。WMode=1 のフォントを使った正常な出力が得られるようにしたい。
モンゴル文字によるモンゴル語 †
- モンゴル語には、キリル文字による書法とモンゴル文字による書法がある。モンゴル国ではキリル文字が使用されている。モンゴル文字の使用を復活する動きはあまり成功していない。中国内のモンゴル系民族は、モンゴル文字を使用している。
- Unicodeでは、U+1800-U+18AF に定義されているが、母音と子音の音素単位の定義となっている。アラビア文字と同様、語頭、語中、語尾の位置によって字形が変化し、加えて母音と子音の組み合わせによっても字形が変化する。文字をコード列順に一次元的に配置すれば大体済んでしまう欧米語や CJK とは異なり、Unicode のモンゴル文字フォントはこれらの字形を変種(variant)としてもつ必要があり、またそのレンダリングには複雑なアルゴリズムを要する。古い TrueType フォントでは、個々の字形に異なる符号位置を与えている（当然 Unicode ではない）。
- 字送りは下方向、行送りは右方向である。Omega/Aleph のマニュアルでは、"LTL" が想定されている。歴史的にはそれで正しいのかもしれないが、現代モンゴル語話者の感覚では "LTT" なのではないかと思う。また、現存するモンゴル文字の TTF/OTF は Unicode 符号化か否かに関わらず "LTR" であるものがほとんどである。モンゴル文字は独自の句読点をもつが、欧文の"！"や"？"も借用され、これらの文字は "LTT" で配置される。
- モンゴル文字が主体の文章で欧米語や CJK を混ぜ書きする場合は、モンゴル文字:"LT?"、欧米語:"LTR"、CJK:"LTT" で組むのがおそらく自然であろう。
- 字送りが下方向の縦書きという点では CJK の縦書きに似ているが、CJK とは異なって字送り方向が一方向のみである。この理由から、文字の変位ベクトルを 2 方向分用意した CJK フォントの方法とは解決方法が異なることになるかもしれない。
世界のスクリプトの組版上の特徴と課題 †
- 雑ではありますが、まとめてみました。世界の中で CJK がどのように見えるか、多少は想像できそうです。CJK 独特の処理を国際的な開発の場に主張していくことは決して独善ではない、と思います。
| スクリプト | 主な書字方向 | 語句の分離/連続 | 行分割 | レンダリング | 重要な課題 |
| ラテン文字 | TLT | スペース区切り | 語の区切りか、ハイフネーション | 単純 | ハイフネーション |
| ヘブライ文字 | TRT | スペース区切り | | 少々複雑 | bidi, レンダリング |
| アラビア文字 | TRT | スペース区切り | | 非常に複雑 | bidi, レンダリング |
| デヴァナーガリー | TLT | スペース区切り | | 非常に複雑 | レンダリング |
| タイ文字 | TLT | 連続 | 語の区切り | 非常に複雑 | レンダリング。語の分割箇所の判定。 |
| 漢字・かな (日本語) | RTT, TLT | 連続 | 語中の任意箇所 | 単純 | 文字種の多さ。組み方向。 |
| 漢字 (中国語) | RTT, TLT | 連続 | 語中の任意箇所 | 単純 | 文字種の多さ。組み方向。 |
| ハングル (韓国語) | RTT, TLT | スペース区切り | 語中の任意箇所 | 単純 | 文字種の多さ、組み方向。 |
| モンゴル文字 | LT? | スペース区切り | 語の区切り | 複雑 | レンダリング。組み方向。 |
- 組版上で課題となる項目
コメント †
- LTT のモンゴル文字のフォントは OTF では実現可能なようにみえるのですが、現状には何か理由があるのでしょうか。 -- ZR
- 「レンダリングの複雑さ」について、アブジャド(abjad)の場合は母音符号を含むかで大きく違うと思います。私の直感では
ラテン = ヘブライ(符号無) < アラビア(符号無) < ヘブライ(符号有) < モンゴル < アラビア(符号有)
ですかね。（ただ、このページの主題とは無関係ですね。）-- ZR
- コメントありがとうございます。レンダリングの難しい言語に対して LuaTeX はどのように対処しようとしているのでしょうか? XeTeX の方向性(スマートフォントの活用) はよく分かるのですが。それや BiDi に比べれば、組み方向が縦というのは簡単な問題のように思えます。座標の読み替えだけで実現できるのですから。ましてや、行送り方向が、RTT か LTT かなど随分やさしいのでは。それよりも CJK にとっては、行分割や禁則処理の方が他の諸言語と比較して独特の処理となるので、スマートな実装をどうするかという点で課題になり得るようにも思いました。 -- ttk
- 本質的に TLT、TRT、LTT 等のどれか 1 つが他より難しいということはないでしょう（元々 TLT 専用のソフトを他に対応させる…という場合は別）。CJK のように縦と横の両方ある場合は、方向による異体字が生じるので、それは事態を少し複雑にするでしょうが、位置異体と比べると容易いものですね。ところで、LTT と RTT の言語が「段落単位」で混在した場合、行の順序はどうなるのですかね。BiDi のようになる? -- ZR
- LuaTeX の「スマートなレンダリング」は OTF を念頭に置いていると思われます。OTF は、フォントは「データ」だけ持って「アルゴリズム」はレンダリングエンジンに任せるという方式です。XeTeX は既存のライブラリ(ICU)を用いていますが、LuaTeX では、フォントのデータを Lua 上に読み込んで自前で（多分 Lua で?）出力の調整をしようとしているように見える、というのがこの発表資料を見た後の印象です。 -- ZR
- ありがとうございます。日本語でも、仮名の連綿体や異体字セレクタなど、従来の枠組みでは難しそうなレンダリングもこれから欲しくなりそうです。LTT と RTT が段落単位で BiDi のようになるのは、面白そうですが、確かにややこしそうです。 -- ttk
- CJK の縦組み (RTT) 主体の文章中に R-to-L を縦に組む場合には、RTL に組むのでしょうか? そうすると、R-to-L にとっては、行送りが文字の下から上の方向(普通と逆)になります。モンゴル文字 (LT?) 主体の文章中に L-to-R を LTR に組む場合も同様です。まあ、どんな組み方向がどんな組み合わせで現れても不自由しない自然で単純明快な仕様が望まれる、ということはいえそうです。 - ttk
- 疑問に思ったのですが、LuaTeX でのスマートレンダリングの「実験の成果」は公開されている物―ConTeXt (MkIV) ということになるのでしょう―の中に既に反映されているのでしょうか。LuaTeX の現状を知るだけの目的で ConTeXt に手を伸ばすというのは二の足を踏んでしまいますが…。 -- ZR
存在する実装 †
PostScript/PDF †
- CJK の文字送り方向の縦横は、指定フォントの WMode (書式モード) の値が 0(横組み)か 1(縦組み)のどちらになっているかで決定される。WMode のデフォルト値は 0 である。
WMode の指定によって、各グリフの原点と描画後の新しいテキスト位置が切り替わる。行送り方向の指定は特に無く、"moveto" (PostScript) や "m" (PDF) などでカレントポイントを個別に指定する必要がある。
pTeX †
- 組み方向を指定するプリミティヴ \yoko, \tate が存在する。
- DVI命令に、組み方向指定命令(255番)を独自に拡張している。DVIware は、この拡張命令を解釈できることが要求される。
| オペランド | 組み方向 | 字送り方向 | 行送り方向 | Omega風に言うと |
| 0 | 横組み | 水平右向き | 垂直下向き | TLT |
| 1 | 縦組み | 垂直下向き | 水平左向き | RTT(和文), RTR(欧文) |
- 和文フォントメトリックス JFM に、縦組み用ID 9, 横組み用ID 11 がある。縦組み用、横組み用との間で、深さ、高さ、幅、カレントポイントの移動方向などが90度異なっている。PostScript/PDF での WMode に相当する。欧文は、横組み用の TFM が縦組みでもそのまま利用され、RTR 相当に組まれる。
- Omega と対応させてみると、Omegaで言う主方向と第2方向の情報を DVI の組み方向指定命令で、第3方向の情報を JFM の ID で持っている、という風にも取れる。
- 字送り方向が right に、行送り方向が down に一致するような座標系を取っている。
- このような pTeX の方法以外にも、RTT(和文) と RTR(欧文) の混植を組むのに「字送り方向が down に、行送り方向が left に一致する座標系」もありえそう。
Omega/Aleph †
- 書字方向は、3つの属性(主方向、第2方向、第3方向) がTop, Bottom, Left, Rightのどの値を取るかで表現され、32通りが可能である。
| 主方向 | 行送りの開始地点のある方向 |
| 第2方向 | 行内字送りの開始地点のある方向 |
| 第3方向 | フォント上の文字の「上」が版面上で指す方向 |
- ここでの話題に関係ありそうなものを抜粋すると
| TLT | 左→右、左横書きCJK、欧文 |
| TRT | 右→左、右横書きCJK、ヘブライ文字、アラビア文字 |
| RTT | 上→下、縦書きCJK |
| LTL | 上→下、モンゴル文字 |
- 書字方向を指定するプリミティヴ\textdir が存在する。
- 出力 DVI には special が挿入される。場合によっては DVIware は、この special を解釈できることが要求される(??)。
e-TeX/pdfTeX †
- TeX--XeT と呼ばれる拡張を含む。TLT と TRT の混植が可能。
- \TeXXeTstate が正のとき TeX--XeT 機能が有効で、\beginR, \endR プリミティヴで囲まれた部分が TRT 相当に組まれる。
- DVI, TFM は、TLT 相当の仕様のままで拡張はない。出力 DVI に文字が現れる順序は、TRT の場合、論理的な順序と逆になる。紙の出力や画面上の静的な出力では問題にならないが、PDF 出力をヴューア上で文字列選択するような場合には問題になるのではないだろうか。
LuaTeX †
- 書字方向については、TeX--XeT 拡張は不採用。Omega/Aleph 方式が採用されている。
- CJK の縦組みはあまりテストされていないらしい。
XeTeX †
- XeTeX 自身は縦書きをサポートせず、横に組んだものを graphicx パッケージ（つまり xdvipdfmx）の回転機能を用いて縦方向に出力させている。例としては zhspacing のマニュアルを参照。R-to-L のサポートには TeX--XeT 拡張を用いる。
- CJK フォントの場合、フォント定義(\font)で feature に "vertical" を指定すると、「縦組みモード」が選択され、横転した文字の横書き（"TLL" 相当）で組まれる。これを時計回りに 90°回すと "RTT" になる。
- パラメタ \XeTeXupwardsmode が正の時は行送りが上方向になる。この状態で "LTR" のモンゴル文字フォントを用いて横に組み（"BLT" になる）、時計回りに 90°回すと "LTR" になり正しい方向になる。
MonTeX †
コメント †
- PDF の日本語、中国語の縦組みに関しては、「PDFリファレンス第2版―Adobe Portable Document Format Version 1.3」(ISBN-10: 4894713381, ISBN-13: 978-4894713383) の240, 251, 277 ページ付近に解説があります。Adobe が正式な仕様書をおそらく公開していると思いますが。PDFでモンゴル語の扱いはどうなっているのでしょうか? また、TrueType や OpenType での CJK の縦組みの仕様がどうなっているのか、モンゴル語ではどうか、知っておく必要があると思います。 -- ttk
- 各章の部分にコメント欄を作ってみました。 -- ZR
- 現在の Omega のように DVI で putchar/down によって文字を縦に並べる方法では、そこから正常なテキスト情報をもつ PDF を作るのは困難だと思います。では（「DVI」を保持するとして）どの方法がいいかは考慮の余地があります：例えば、上下左右を変換する（pTeX DVI の様に）か、setchar の変位方向を可変にするのか、等。あと、Omega で書字方向が変化したときに、内部で上下左右の変換が起こるのか（box の「深さ」とはどの方向を指す?）が気になります。少し実験したところでは、内部表現(\showbox)では、縦書きは（複数の行ではなく）文字の並びでした。あと、Omega のように任意のフォントを任意の方向で使うことを考えると、フォント情報(OFM)の中に縦方向のベースラインの情報がないことに気づきます（常にグリフの中心を通ると仮定しているようです）。 -- ZR
- 私の理解した範囲で、思い切って断定的に書いていますが、間違っていたらどんどん直してください。 -- ttk
関連情報 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
