いま韓国語の本をpLaTeXとotf.styで組版する作業をしています。
韓国のかたが普通にエディタに打ち込める必要があるので，次のようにしています：
\documentclass{jsarticle}
\usepackage[multi]{otf}
\usepackage[utf8]{inputenc}
\DeclareUnicodeCharacter{D55C}{\UTFK{D55C}}
\DeclareUnicodeCharacter{AE00}{\UTFK{AE00}}
\begin{document}
\hsize=9zw
한글
한글.
한글 한글.
한글 한글.
한글 한글.
한글 한글.
한글 한글.
한글 한글.
\end{document}
英語と同様に，改行はスペースにならなければなりませんし，スペースがないところでは改行できません。ピリオドはもちろん行頭には来れません。
ところが，上の例を platex，dvipdfmx で処理すると，行頭にピリオドが来てしまいます。
何か良い方法はないでしょうか。組版結果を添付します。
なお，実際は上の\DeclareUnicodeCharacterをすべての文字について並べたhangul.dfuを読み込んでいます。
ktug の Contribution 板の 2008.2 あたりに，韓国の方から指摘されたものと
同じようです．
http://www.ktug.or.kr/jsboard/read.php?table=contrib&no=4590&page=3
事の詳細を忘れてしまったので，ひとまずリンクだけ張っておきます．
同じようです．
http://www.ktug.or.kr/jsboard/read.php?table=contrib&no=4590&page=3
事の詳細を忘れてしまったので，ひとまずリンクだけ張っておきます．
以前、
AsiaTeX08 参加レポート
で、ハングルの組版について話題になっていましたね。
そのときの話では、
pTeXでは［グループの境界での禁則処理］が効かない、
とのことだったと思います。
upTeXなら、ハングルも普通のCJK文字なので、
この仕様の影響が軽微になるはずです。
upTeX/upLaTeXで試す、というのも対策として一つの選択肢だと思います。
人柱になっていただけるなら、ですが。
AsiaTeX08 参加レポート
で、ハングルの組版について話題になっていましたね。
そのときの話では、
pTeXでは［グループの境界での禁則処理］が効かない、
とのことだったと思います。
upTeXなら、ハングルも普通のCJK文字なので、
この仕様の影響が軽微になるはずです。
upTeX/upLaTeXで試す、というのも対策として一つの選択肢だと思います。
人柱になっていただけるなら、ですが。
どもども。m(__)m
間違えました。全部貼り付けます：
\documentclass{jsarticle}
\usepackage[multi]{otf}
\usepackage[utf8]{inputenc}
\DeclareUnicodeCharacter{D55C}{\UTFK{D55C}}
\DeclareUnicodeCharacter{AE00}{\UTFK{AE00}}
\makeatletter
\DeclareRobustCommand{\UTFK}[1]{\begingroup%
\edef\reserved@a{\gtdefault}\ifx\k@family\reserved@a \kanjiseries{bx}\fi%
\kanjifamily{utfk}\uppercase{\set@character="#1}%
\endgroup%
\nobreak\hbox{}%
}
\makeatother
\begin{document}
\hsize=4zw
\noindent
한글한글.
\end{document}
間違えました。全部貼り付けます：
\documentclass{jsarticle}
\usepackage[multi]{otf}
\usepackage[utf8]{inputenc}
\DeclareUnicodeCharacter{D55C}{\UTFK{D55C}}
\DeclareUnicodeCharacter{AE00}{\UTFK{AE00}}
\makeatletter
\DeclareRobustCommand{\UTFK}[1]{\begingroup%
\edef\reserved@a{\gtdefault}\ifx\k@family\reserved@a \kanjiseries{bx}\fi%
\kanjifamily{utfk}\uppercase{\set@character="#1}%
\endgroup%
\nobreak\hbox{}%
}
\makeatother
\begin{document}
\hsize=4zw
\noindent
한글한글.
\end{document}
うーむ。あれから色々と小細工を練ってみたんですけど、自動挿入のペナルティが簡単に消えてしまう（代入操作を入れるだけで消える
）のでかなりお手上げな状態です。
もし、本当に upTeX を考えるとして、一番気になるのは、そもそも pTeX と upTeX で導入のハードルが大きく違わないかなということです。（向こうに入れた pTeX は ptetex3?）
あと、必要な作業は、文書クラスのフォント定義を韓国語のものに変えることでしょうか。原稿のあり方自体は pTeX + OTF と upTeX で変わらないはずです。
※ あと、pTeX + OTF を使っていて「漢字は大丈夫なの？」と思ったりする。「振り漢字」は日本語の文書の振り仮名と同程度には出現するようなので…。
出先なので「匿 名」になっていますが、ttkです。
“pTeXでの解”を考えました。
○ platexのフォーマットファイルやソースなど一式をEUC-KRで記述して用意する。
○ platexの文字コードはEUCとする。
○ 少量の日本語は、EUC-KRに含まれる漢字と仮名で書く。
○ 本文はEUC-KRのハングル。禁則処理も問題ないはず。
○ otfパッケージの記号類や\UTF{}は使えるはず。日本語の不足分はこれでまかなえる。韓国語もEUC-KRで大抵書けるはずだが不足したら\UTFK{}でまかなう。
○ jfmの作成には、uppltotfが使えるはず。(pTeXのpltotfは、一部の区が指定できない)
理屈の上では可能のように思いますが、
ハードルの高さや掛かる手間の多さはupTeX導入以上かも、です。
“pTeXでの解”を考えました。
○ platexのフォーマットファイルやソースなど一式をEUC-KRで記述して用意する。
○ platexの文字コードはEUCとする。
○ 少量の日本語は、EUC-KRに含まれる漢字と仮名で書く。
○ 本文はEUC-KRのハングル。禁則処理も問題ないはず。
○ otfパッケージの記号類や\UTF{}は使えるはず。日本語の不足分はこれでまかなえる。韓国語もEUC-KRで大抵書けるはずだが不足したら\UTFK{}でまかなう。
○ jfmの作成には、uppltotfが使えるはず。(pTeXのpltotfは、一部の区が指定できない)
理屈の上では可能のように思いますが、
ハードルの高さや掛かる手間の多さはupTeX導入以上かも、です。
- updvi2ttyについて
disdvi.c:83: error: conflicting types for ‘malloc’
が出ると報告いただいています。もしそうなら、 char *malloc(); → void *malloc(); と変更して通らないでしょうか?
- otfパッケージについて
samples/otfsmpl-uplatex.tex
の例のように、
\usepackage[uplatex,noreplace,multi]{otf}
のようにしても駄目ですか?
- dvipdfmxについて
samples/otfsmpl-uplatex.tex
または
samples/cjk_babel.tex (ロシア語、ギリシャ語部分は要当該フォント)
で
upTeXパッチの当たったdvipdfmxで
ptetex3+upTeXの初期設定で通らないでしょうか?
(xdviの方は、環境に応じたフォント設定を手動で行わないと中韓は動きません。)
＞あと、必要な作業は、文書クラスのフォント定義を韓国語のものに変えることでしょうか。
念のため、この辺をもう少し具体的にいうと、jsbook.cls において
\DeclareFontShape{JY2}{mc}{m}{n}{<-> s * [0.924690] upjisr-h}{}
\DeclareFontShape{JY2}{gt}{m}{n}{<-> s * [0.924690] upjisg-h}{}
\DeclareFontShape{JT2}{mc}{m}{n}{<-> s * [0.924690] upjisr-v}{}
\DeclareFontShape{JT2}{gt}{m}{n}{<-> s * [0.924690] upjisg-v}{}
のところで、upjisr→upkorrm, upjisg→upkorgt の変更が必要ということです。
ただ、「日本語の文字」の部分は日本語フォントでないと失敗する恐れがあるので、別途 JY2/jamc ファミリに upjisr-h をあてて、日本語部分でファミリを切り替える必要があります。
私のサイトに upLaTeX の使用法の解説があります。ただし、これは TeX の知識をもたない初級者のためのものなので、自作のパッケージの使用が前提となっています。
pLaTeX + OTF で \UTFK を使った部分の禁則処理ができなくなる問題については，次のような方法も考えました。
\DeclareRobustCommand{\UTFK}[1]{\begingroup%
\edef\reserved@a{\gtdefault}\ifx\k@family\reserved@a \kanjiseries{bx}\fi%
\kanjifamily{utfk}\uppercase{\set@character="#1}%
\endgroup%
\futurelet\@let@token\@UTFnobreakhack}
\def\@UTFnobreakhack{%
\ifx\@let@token.%
\nobreak
\else
\ifx\@let@token,%
\nobreak
\else
\ifx\@let@token'%
\nobreak
\fi
\fi
\fi}
本来はpTeXのほうでもうちょっと何とかならないかと思うのですが。
upLaTeXについても検討しているのですが，結局ハングルと日本語の切れ目に何かを書いてもらわなければならないとすれば先方の手間を増やしてしまうので，考え込んでいます。pTeXが日本語と英語の切れ目に何も入れなくても勝手にフォントを変えてくれたようなことがupTeXでもできればいいのですが。
\DeclareRobustCommand{\UTFK}[1]{\begingroup%
\edef\reserved@a{\gtdefault}\ifx\k@family\reserved@a \kanjiseries{bx}\fi%
\kanjifamily{utfk}\uppercase{\set@character="#1}%
\endgroup%
\futurelet\@let@token\@UTFnobreakhack}
\def\@UTFnobreakhack{%
\ifx\@let@token.%
\nobreak
\else
\ifx\@let@token,%
\nobreak
\else
\ifx\@let@token'%
\nobreak
\fi
\fi
\fi}
本来はpTeXのほうでもうちょっと何とかならないかと思うのですが。
upLaTeXについても検討しているのですが，結局ハングルと日本語の切れ目に何かを書いてもらわなければならないとすれば先方の手間を増やしてしまうので，考え込んでいます。pTeXが日本語と英語の切れ目に何も入れなくても勝手にフォントを変えてくれたようなことがupTeXでもできればいいのですが。
CJK の後ろの方は何とかなるんですが、結局問題なのは「前」の方で…。いや待てよ、後ろのほうは厳密に禁則判定して、前は「常に禁則」（\hbox{}\nobreak を入れる）にするとごまかせる…？
日本語韓国語混在の upTeX ソースで仮名/漢字/ハングルのフォントを切り替えるというのは、pTeX で仮名/漢字で切り替えるというのと同じ問題だと私は認識しています。つまり、VF を用いて解決すべきであると。理由は、そもそも Unicode テキストにおいて「言語の自動判定」が不可能である以上、フォントの切り替えは「言語」ではなく「文字種」によると考えるべきだからです。
少し勘違いをしていました。和文の前では後と異なりグルーピングや代入で penalty が消えることはないようです。だから後ろ側で対策を講じるだけで十分ということになります。
例:(pTeX)
\showboxdepth=10 \showboxbreadth=10
\setbox0=\hbox{({日本})}\showbox0\bye
\showbox の表示（表示されない skip を補足した）
\hbox(7.77588+2.5)x27.02213, yoko direction
.\tenrm (
.\penalty 10000(for kinsoku) -- この後に zero skip
.\tenmin 日 -- この後に kanjiskip
.\tenmin 本 -- この後に zero skip、penalty 消滅
.\tenrm )
なお、フォントの切替も代入の一種なので、和文の直後でフォントを切り替えるとやはりそこでも penalty は消えます。\UTFK の処理で、グルーピングの代わりに文字の前後にフォント切替を置くというのは上手くいかないんですね。
> ハングルと日本語の切れ目に何かを書いてもらわなければならない
今のupTeXの仕様ではCJKのフォントを縦組、横組で一つづつ、欧文のフォントを一つの合計三つを同時に管理していますが、CJKの中では、日本語か韓国語か、という区別はなされていません。
もしpTeX(upTeXも踏襲)で日本語と英語の切れ目にフォントを切り替える機構と同様の手法で、日本語と韓国語の切り替えを行おうとするなら、upTeX自体の改造が必要そうです。
しかし、それ以前に、日本語と韓国語のどちらでも使うような文字が、基本的な漢字以外に記号類などでもいろいろありますが、Unicodeでは文字コード列を見てもそれらの文字が日本語なのか韓国語なのか、という区別のつけようがなく、その振り分けをする判断基準を外から与えないといけません。upTeXの場合、CJKと欧文の切り替えの判断基準を\kcatcode の拡張により外から与えられるようにしているわけですが、\kcatcode のさらなる拡張で、upTeX拡張の延長上でCJK間の切り替えも出来ないことはないです。しかし、煩雑な仕様のようにも思えます。
upTeXの場合は、pTeX+OTFの場合と違って、CJK間のフォントの切り替えをグルーピングで行うのではなく、goto型の切り替えを行うのでも機能するように思えます。例えば、upTeXでhangul.dfuのようなものをgoto型でやる、という案です。それなら、グルーピング後の禁則処理の問題も発生しないような気がします。この手法の場合、hoge.dfuの作成時点で、Unicodeのどの字が日本語なのか韓国語なのかの振り分けをすることになります。
今のupTeXの仕様ではCJKのフォントを縦組、横組で一つづつ、欧文のフォントを一つの合計三つを同時に管理していますが、CJKの中では、日本語か韓国語か、という区別はなされていません。
もしpTeX(upTeXも踏襲)で日本語と英語の切れ目にフォントを切り替える機構と同様の手法で、日本語と韓国語の切り替えを行おうとするなら、upTeX自体の改造が必要そうです。
しかし、それ以前に、日本語と韓国語のどちらでも使うような文字が、基本的な漢字以外に記号類などでもいろいろありますが、Unicodeでは文字コード列を見てもそれらの文字が日本語なのか韓国語なのか、という区別のつけようがなく、その振り分けをする判断基準を外から与えないといけません。upTeXの場合、CJKと欧文の切り替えの判断基準を\kcatcode の拡張により外から与えられるようにしているわけですが、\kcatcode のさらなる拡張で、upTeX拡張の延長上でCJK間の切り替えも出来ないことはないです。しかし、煩雑な仕様のようにも思えます。
upTeXの場合は、pTeX+OTFの場合と違って、CJK間のフォントの切り替えをグルーピングで行うのではなく、goto型の切り替えを行うのでも機能するように思えます。例えば、upTeXでhangul.dfuのようなものをgoto型でやる、という案です。それなら、グルーピング後の禁則処理の問題も発生しないような気がします。この手法の場合、hoge.dfuの作成時点で、Unicodeのどの字が日本語なのか韓国語なのかの振り分けをすることになります。
＞この範囲の次にこの範囲が出てきたらフォント変更コマンドを自動挿入するということをユーザが指摘できる仕組みでも作らないことには無理っぽいですね。
XeTeX はこのアプローチをとっています。
Unicode による LaTeX の多言語処理に関する私の考えを書き捨てておきます。
「各言語の組版の細則(グリフの選択等)は文字コードは面倒をみない」という Unicode の設計に従う以上、高品位な組版が求められる LaTeX のような場では、言語のマークアップは原則的に必要、ただ実害がないなら省略可能であるというのが私の考えです。
さらに、現状では Babel が LaTeX における標準的なマークアップの役割を果たしているとも考えています。例えば、日本語メインの文書の中に韓国語が出てくるなら、そこは \foreignlanguage{korean}{...} となっているのが自然だという発想です。これをどう TeX で実装するかというのがパッケージ作成者の仕事です。
ko.TeXで使うTFMとは、sub fontに分けられた多数のTeX用のTFMなのでしょうか? 直接 pTeX/upTeX の和文/CJK で利用するのは無理そうですね。
文字幅の種類が256種類以内ならば、upTeX用のJFMをuppltotfで一つ作成すれば、upTeXで使うにはよいように思います。日本語の半角片仮名はそれっぽく動いているように見えるので、同様に可能なのではないかと思うのですが…。
pTeX+OTFパッケージでも、\UTFK{}で対応するコード値のJFM多数をプロポーショナルにすれば可能なのかもしれません。プロポーショナルの幅の違いがフォント毎に異なっていたりすると、さらにややこしいのかな。
> 後でテストさせていただきます。
いつもお世話になります。
文字幅の種類が256種類以内ならば、upTeX用のJFMをuppltotfで一つ作成すれば、upTeXで使うにはよいように思います。日本語の半角片仮名はそれっぽく動いているように見えるので、同様に可能なのではないかと思うのですが…。
pTeX+OTFパッケージでも、\UTFK{}で対応するコード値のJFM多数をプロポーショナルにすれば可能なのかもしれません。プロポーショナルの幅の違いがフォント毎に異なっていたりすると、さらにややこしいのかな。
> 後でテストさせていただきます。
いつもお世話になります。
ttkさん，kurokyさん，どうもありがとうございます。
ko.TeXはサブフォントだと思いますので，pTeXにko.TeXのサブフォントを使えるような工夫をしない限り簡単ではなさそうですね。
> 文字幅の種類が256種類以内ならば、upTeX用のJFMをuppltotfで一つ作成すれば、upTeXで使うにはよいように思います。
なるほど。うまく256にクラスタリングできれば，いいかもしれませんね。
このJFMの制限を超えるような非互換な拡張をupTeXに採り入れるというのは将来的にどうでしょうか。
究極のハックとしては，マクロレベルで，dfuファイルの中とかで，1文字ずつ幅を指定するとか……。これだとYoonのベースラインの問題も解決できるでしょうか。
これでAJTにもう一本論文を出しますか？
ko.TeXはサブフォントだと思いますので，pTeXにko.TeXのサブフォントを使えるような工夫をしない限り簡単ではなさそうですね。
> 文字幅の種類が256種類以内ならば、upTeX用のJFMをuppltotfで一つ作成すれば、upTeXで使うにはよいように思います。
なるほど。うまく256にクラスタリングできれば，いいかもしれませんね。
このJFMの制限を超えるような非互換な拡張をupTeXに採り入れるというのは将来的にどうでしょうか。
究極のハックとしては，マクロレベルで，dfuファイルの中とかで，1文字ずつ幅を指定するとか……。これだとYoonのベースラインの問題も解決できるでしょうか。
これでAJTにもう一本論文を出しますか？
もう一点、JFMの機能で重要なものを忘れていました。縦組み、横組みの組み方向指定です。
OFM(level-0, -1)そのものにはJFMの縦組みに相当する仕様は織り込まれていなかったと思います。私の案は横組みにしか有効でないようです。既存のOmegaの縦組みは、あまりにJFM的手法と違いすぎます。縦組みに相当する仕様をxFMに織り込んだものが既存にあって、dviwareのサポートが充分普及している状況というのは、JFM以外には無いと思います。
縦組みをJFM以外で実現する方法について、土村さんのところで議論した (漢字語|縦組)タイプセット のような状況がありました(LuaTeXの縦組みはその後進展あったのでしょうか?)。 何らかの仕様を拡張して、しかも将来的に生き残れるようなものにするなら、正面からこの問題に取り組んだ方がよいようにも思えます。JFM的なやり方は、他と比較しても、決して筋の悪いものではないとは思いますが、国際的に孤立するようならつらくなりますし。
OFM(level-0, -1)そのものにはJFMの縦組みに相当する仕様は織り込まれていなかったと思います。私の案は横組みにしか有効でないようです。既存のOmegaの縦組みは、あまりにJFM的手法と違いすぎます。縦組みに相当する仕様をxFMに織り込んだものが既存にあって、dviwareのサポートが充分普及している状況というのは、JFM以外には無いと思います。
縦組みをJFM以外で実現する方法について、土村さんのところで議論した (漢字語|縦組)タイプセット のような状況がありました(LuaTeXの縦組みはその後進展あったのでしょうか?)。 何らかの仕様を拡張して、しかも将来的に生き残れるようなものにするなら、正面からこの問題に取り組んだ方がよいようにも思えます。JFM的なやり方は、他と比較しても、決して筋の悪いものではないとは思いますが、国際的に孤立するようならつらくなりますし。
奥村さんの
＞このJFMの制限を超えるような非互換な拡張をupTeXに採り入れるというのは将来的にどうでしょうか。
を呼んで私も少し考えていたのですが、辿り着いた方法論は ttk さんと同じでした。まあ、「dviware の改造を最小限に留めたい」（むしろ「独自のファイル形式を upTeX 本体の外に持ち出したくない」）という方針で考えると必然的にその結論になりますね 
少し補足すると、UPFM 形式を用意する代わりに
TeX でのフォント名に対して JFM と OFM の両方が存在する場合は、両方を読み込み、TYPE と GLUEKERN については JFM、残りについては OFM の情報を用いる
（横書き限定、文字コード値は 2 byte まで。L-to-R の横書きだけなら TeX も pTeX も Omega も DVI 仕様は同じ）
でも乗り切れるかなと思います。とりあえず考えてみただけですが。