QA: ptexlive-2009 の Babel 対応

皆様ご無沙汰しております。

ptexliveのBabel対応ですが，昨年は本業のほうでばたばたしており対応が遅れてしまい申し訳ありません。
ptexlive-2009についてはできるだけ早く対応できるようにしたいと思っています。

今回は北川さんに作成いただいた6babel.shスクリプトをもとにテストしてみました。
北川さん，ありがとうございます。
手順としては，

（1）ptexliveコンパイル時に北川さんご提供のeptex-100201.tar.bz2所収の6babel.shを実行し，その後make install
（2）$TEXMF/ptex/platex/configのなかにあるhyphen.cfgをリネームか削除
（3）フォーマットファイルの（再）作成（例えば fmtutil(-sys) --byfmt platex）

e-pTeXは以下からダウンロード出来ます。
http://sourceforge.jp/projects/eptex/wiki/FrontPage
$TEXMFはデフォルトでは/usr/local/texlive/p2009/texmf/...のような感じだと思います。

とりあえず，新しいhyph-utf8システムを使って旧来の7ビットコードのソースをコンパイルすることは可能のようです。ただしhyph-utf8そのものがまだかなり未完成（現時点で正式対応しているハイフネーションファイルは2割程度）なので，細かい不具合はあるかも知れません。

ひとまず永田先生のヨハネ伝サンプルファイルを使ってテストしてみました。
http://oku.edu.mie-u.ac.jp/~okumura/texwiki/?%E6%96%B0%20pTeX%20%E3%81%A8Babel#mafcbf19

確認したい文字列を\showhyphens{ }で囲むとlogファイルにハイフネーションの動作状況を書き出してくれます。
手元の実験結果を添付します（フランス語は文字化けしている部分がありますが）。
お気づきの点がありましたらご指摘よろしくお願いします。

-----------------------------------------------------------

This is pTeXk, Version 3.1415926-p3.1.11 (utf8.euc) (TeX Live 2009)
restricted \write18 enabled.
(./johannes-j.tex
pLaTeX2e <2006/11/10>+0 (based on LaTeX2e <2009/09/24> patch level 0)
(/usr/local/texlive/p2009/texmf/ptex/platex/jsclasses/jsarticle.cls
Document Class: jsarticle 2010/03/14 okumura
) (/usr/local/texlive/p2009/texmf-dist/tex/latex/cm-super/type1ec.sty
(/usr/local/texlive/p2009/texmf-dist/tex/latex/base/t1cmr.fd))
(/usr/local/texlive/p2009/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/p2009/texmf-dist/tex/latex/cyrillic/ot2enc.def)
(/usr/local/texlive/p2009/texmf-dist/tex/latex/base/t1enc.def))
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/babel.sty
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/greek.ldf
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/babel.def)
Loading the definitions for the Greek font encoding
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/lgrenc.def))
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/russianb.ldf)
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/english.ldf)
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/frenchb.ldf
*************************************
* Local config file frenchb.cfg used
*
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/frenchb.cfg))
(/usr/local/texlive/p2009/texmf-dist/tex/generic/babel/germanb.ldf))
(/usr/local/texlive/p2009/texmf-dist/tex/latex/carlisle/scalefnt.sty)
(/usr/local/texlive/p2009/texmf-dist/tex/latex/graphics/keyval.sty)
(./johannes-j.aux
(/usr/local/texlive/p2009/texmf-dist/tex/latex/cbfonts/lgrcmr.fd)
(/usr/local/texlive/p2009/texmf-dist/tex/latex/cyrillic/ot2cmr.fd))

Package frenchb.ldf Warning: The definition of \@makecaption has been changed,
(frenchb.ldf) frenchb will NOT customise it;
(frenchb.ldf) reported on input line 8.

(/usr/local/texlive/p2009/texmf-dist/tex/latex/base/t1cmss.fd)
Underfull \hbox (badness 10000) in paragraph at lines 26--26
[] \T1/cmr/m/n/10 In the be-gin-ning was the Word, and the Word was with God,
and the Word was God. He was in the be-gin-ning with God. All things came into
be-ing through him, and with-out him not one thing came into be-ing. What has c
ome into be-ing in him was life, and the life was the light of all peo-ple. The
light shines in the dark-ness, and the dark-ness did not over-come it.

Underfull \hbox (badness 10000) in paragraph at lines 44--44
[] \T1/cmr/m/n/10 Au com-men-ce-ment 蜚ait le Verbe, et le Verbe 蜚ait tourn
vers Dieu, et le Verbe 蜚ait Dieu. Il 蜚ait au com-men-ce-ment tournvers Dieu
. Tout fut par lui, et rien de ce qui fut, ne fut sans lui. En lui 蜚ait la vie
et la vie 蜚ait la lu-mi蓿e des hommes, et la lu-mi蓿e brille dans les t薛n萵r
es, et les t薛n萵res ne l'ont point com-prise. Il y eut un homme, en-voyde Di
eu : son nom 蜚ait Jean.

Underfull \hbox (badness 10000) in paragraph at lines 61--61
[] \T1/cmr/m/n/10 Im An-fang war das Wort, und das Wort war bei Gott, und das
Wort war Gott. Die-ses war im An-fang bei Gott. Al-les wur-de durch das-sel-be,
und oh-ne das-sel-be wur-de auch nicht ei-nes, das ge-wor-den ist. In ihm war
Le-ben, und das Le-ben war das Licht der Men-schen. Und das Licht scheint in de
r Fin-ster-nis, und die Fin-ster-nis hat es nicht er-fa^^fft.
(/usr/local/texlive/p2009/texmf-dist/tex/latex/cbfonts/lgrcmss.fd)
Underfull \hbox (badness 10000) in paragraph at lines 80--80
[] \LGR/cmr/m/n/10 >En >ar-q~h| ~>hn <o l'o-gos, ka`i <o l'o-gos ~>hn pr`os t`
on je-'on, ka`i je-`os ~>hn <o l'o-gos. o-~<u-tos ~>hn >en >ar-q~h| pr`os t`on
je-'on. p'an-ta di'' a>u-to~u >e-g'e-ne-to, ka`i qw-r`is a>u-to~u >e-g'e-ne-to
o>u-d`e <'en. <`o g'e-go-nen >en a>u-t~w| zw-`h ~>hn, ka`i <h zw-`h ~>hn t`o f~
ws t~wn >an-jr'w-pwn; ka`i t`o f~ws >en t~h| sko-t'i-a| fa'i-nei, ka`i <h sko-t
'i-a a>u-t`o o>u ka-t'e-la-ben.
(/usr/local/texlive/p2009/texmf-dist/tex/latex/cyrillic/ot2cmss.fd)
Underfull \hbox (badness 10000) in paragraph at lines 95--95
[] \OT2/cmr/m/n/10 V na-qa-le by-lo Slo-vo, i Slo-vo by-lo u Bo-ga, i Slo-vo b
y-lo Bog. Ono by-lo v na-qa-le u Bo-ga. Vse qrez Nego n&aqalo bytp1, i bez Nego
ni-qto ne n&aqalo bytp1, qto n&aqalo bytp1. V Nem by-la zhiznp1, i zhiznp1 by-
la svet qe-lo-ve-kov. I svet vo tp1me sve-tit, i tp1ma ne obp2yala ego.
[1] [2] (./johannes-j.aux) )
(see the transcript file for additional information)
Output written on johannes-j.dvi (2 pages, 3024 bytes).
Transcript written on johannes-j.log.

Re: ptexlive-2009 の Babel 対応

2010年 05月 29日(土曜日) 19:58 - 栗山雅俊の投稿

すみません一箇所間違いがありました。

> eptex-100201.tar.bz2

はeptex-100420.tar.bz2です。

Re: ptexlive-2009 の Babel 対応

2010年 05月 29日(土曜日) 23:47 - 栗山雅俊の投稿

自己レスばかりで恐縮です。

先の
> （2）$TEXMF/ptex/platex/configのなかにあるhyphen.cfgをリネームか削除

ですが，北川さんのスクリプトにすでに処理があるようです。
もしかすると私の環境で（たまたま？）処理が落ちてしまっただけなのかも知れません。もしそうであれば（2）（3）の作業は不要になります。

こちらも動作確認いただける方がおられましたら嬉しいです。

あとBabelの小さなバグが二つありますが，こちらはまた別コメントで報告いたします。

Re: ptexlive-2009 の Babel 対応

2010年 05月 30日(日曜日) 15:02 - 安田功の投稿

栗山さん，こんにちは。

私は Mac OS X Snow Leopard で ptexlive-2009 + 北川さん e-pTeX を
インストールしましたが，autoconf, automake, m4 のバージョンを

最新にし，sed を GNU sed に入れ替えないといけませんでした。
これで，きちんと e-pTeX 含めコンパイルでき，
かつ UTF-8 ハイフネーションパターンを使ってフォーマットファイルも
platex, eplatex いずれでも普通に生成できました。
分綴処理もきちんと動作しました。
hyphen.cfg リネームなどは不要でした。

安田

Re: ptexlive-2009 の Babel 対応

2010年 05月 31日(月曜日) 21:14 - 栗山雅俊の投稿

安田さん，こんばんは。
検証いただきましてありがとうございます。

> hyphen.cfg リネームなどは不要でした。

実はこちらは私のミスだったかも知れません。
一旦ptexliveの標準版をインストールした後に，上書きする形で処理してしまったため最初のhyphen.cfgが残っていただけだった可能性もありそうです。

そこでe-pTeX単独でコンパイルを何度か試みていますが，まだ成功できていません（コンパイル途中にパソコンにリセットがかかった状態になるなど）。
ptetex単独だと問題ないのですが...

Vine 5.1も決して最新とは言えないかも知れません。

autoconf-2.63-1vl5
Build Date: 2008年09月21日 21時17分22秒
automake-1.10.1-2vl5
Build Date: 2008年10月09日 17時14分35秒
m4-1.4.13-2vl5
Build Date: 2009年04月05日 17時00分14秒
sed-4.1.5-3vl5
Build Date: 2008年09月29日 17時48分07秒

Re: ptexlive-2009 の Babel 対応

2010年 06月 2日(水曜日) 07:21 - 北川弘典の投稿

北川です．

> コンパイル途中にパソコンにリセットがかかった状態に
> なるなど
このような症状は初めて見ました．
詳しく教えてください．
途中までのログをとることはまったく考えていないので，
0eptex.sh 2>&1 |tee cmp.log
ぐらいしかログをとる方法は思いつきません^^;

Re: ptexlive-2009 の Babel 対応

2010年 06月 2日(水曜日) 17:07 - 栗山雅俊の投稿

北川さん，コメントありがとうございます。

すみません，報告のしかたが悪くて余計なご心配をお掛けしました。
今回はコンパイルしている間しばらく放っておいたらなぜかPCがログインの画面に戻っていてあれっ?という感じで，何が原因かも全く特定できていません。

時間を見て再チャレンジして，再度報告いたします。

> 0eptex.sh 2>&1 |tee cmp.log

ご教授ありがとうございます。これも試してみます。

Babel（3.8l）バグ対応

2010年 05月 30日(日曜日) 01:07 - 栗山雅俊の投稿

皆様こんばんは。

こちらではBabel（3.8l）のバグ対応についてコメントします。

現在わかっているのは二つで，こちらをクリアすればptexliveでのBabelインストールをスクリプトで行うことが出来るようになると思います。

（1）frencb.ldfとcatalan.ldf（\up命令の重複）

frencb.ldf（v.2.3d 2009/03/16）とcatalan.ldf（v.2.2p 2005/03/29）では\upという同じ名前の命令が定義されており，両言語を併用すると以下のようなエラーで処理が止まります。

! LaTeX Error: Command \up already defined.
Or name \end... illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...

l.289 \newcommand*{\up}{\relax}

?

日付から言ってもcatalan.ldfが先で，本来はfrencb.ldfを直すべきだとは思いますが，1行の修正のみで済むカタラン語のほうを直すのが賢明かも知れません。catalan.ldfの243行目

> \DeclareRobustCommand*{\up}[1]{\textsuperscript{#1}}
を
> \DeclareRobustCommand*{\cup}[1]{\textsuperscript{#1}}

などとします。

（2）spanish.ldfとgalician.ldf（\quoting命令の重複）

spanish.ldf（v5.0h 2009/01/02）とgalician.ldf（v.4.3c 2008/07/06）ではやはり同様に\quotingという同名の命令が競合しています（エラーメッセージは省略）。
こちらは双方とも最近のバージョンで付加されたようですが，やはり修正箇所が少なくて済むガリシア語のほうを直します。galician.ldfの220-223行目

> \ifx\quoting\c@undefined\def\next{\let\next\relax\newenvironment}
> \else\def\next{\PackageInfo{galician}{Redefining quoting}\let\next\relax\renewenvironment}
> \fi
> \next{quoting}

のうち「quoting」とある3箇所を「gquoting」などに書き換えます。

> \ifx\gquoting\c@undefined\def\next{\let\next\relax\newenvironment}
> \else\def\next{\PackageInfo{galician}{Redefining gquoting}\let\next\relax\renewenvironment}
> \fi
> \next{gquoting}

これらの修正で，稲垣さん作成のbabeltestJIS.tex（ptexlive2009所収）がエラーなく処理出来るようになります。

なお，以前のteTeX3（ptetex3）時代にあったusorbian.ldfのバグは，バージョンアップでフィックスされました。またicelandic.ldfとfrencb.ldfの\decimalsep命令の競合は，frencb.ldfの新バージョンででこの命令がなくなり競合が解消されました。

フランス語とスペイン語の定義ファイルはかなり精力的にバージョンアップされているので，また競合や競合の解消など，動きがあるかも知れません。

もしお時間のある方は検証いただけると嬉しいです。
それではよろしくお願いします。

Re: Babel（3.8l）バグ対応

2010年 05月 30日(日曜日) 04:03 - Inagaki Toru の投稿

栗山さん，おはようございます。

catalan.ldf, galician.ldf を直すことで，競合は無事，解消されています。

pTeX sjis 版ですと icelandic.ldf の 144行 ó，145行 Ó がエラーになりますが，

utf8.euc がメインになれば，支障は無いでしょう。

Re: Babel（3.8l）バグ対応

2010年 05月 31日(月曜日) 21:03 - 栗山雅俊の投稿

稲垣さん，いつもお世話になります。
検証いただきましてありがとうございます。
おかげさまでptetexのBabel対応に見通しがついてきました。

> pTeX sjis 版ですと icelandic.ldf の 144行 ó，145行 Ó がエラーになりますが，

W32TeX所収のもので確認いたしました。実は，今回のptetexではエラーにならないのがちょっと不思議だったのですが，これは土村さんの方でパッチを当てていただいていたのかも知れません。

ハイフネーションファイルについては，W32TeXでは角藤先生にpTeX専用のハイフネーションファイルをわざわざご用意いただいておりますが，いずれhyph-utf8へ移行する時期が来るのだろう思います。
幸い今回はメンテナーのモイツァさんから直々にコメントをいただいたので，TeX Live上でうまく共存できる方法を模索できればと思います。

Re: Babel（3.8l）バグ対応

2010年 06月 2日(水曜日) 23:40 - 栗山雅俊の投稿

すみません，一つ報告し忘れていました。
最新版のfrenchb.ldfではscalefontというパッケージを使うようで，これがないと文句をいわれるようです。

(c:/usr/local/share/texmf/tex/generic/babel/frenchb.cfg))
(c:/usr/local/share/texmf/tex/generic/babel/germanb.ldf))

! LaTeX Error: File `scalefnt.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name

frenchb.ldf（v2.3d）の255行でscalefnt.styを呼び出しています。

l. 255 \AtEndOfPackage{\RequirePackage{scalefnt}}

scalefnt.styはデヴィッド・カーライルという人が作られた同名のパッケージ（Carlisle）に含まれているもので，CTANに収められています。
ftp://ftp.ring.gr.jp/pub/text/CTAN/macros/latex/contrib/carlisle/

Babelから呼ぶならこちらも`required'になるはずですが，まだそうなっていません。frenchbは現在かなり頻繁に更新されているので，仕様が安定するのを待つ必要があるのかも知れません。

Re: Babel（3.8l）バグ対応

2010年 05月 30日(日曜日) 19:28 - Z. R. の投稿

栗山さん、こんばんは。

北川さんの 6babel.sh で少し気になる所があります。

LOADHYPH_SED="s/\\\\ifx\\\\secondarg\\\\empty/\\\\ifx\\\\false/"

この置換先の \ifx\false は意図としては \iffalse なのだと思います。ただ、ここで判定に失敗すると後でエラーになるはずなので、TeX Live の当該版においては影響はないのでしょう。

あとは「\cup 命令は標準 LaTeX にある」とか「quoting の名前を変えたなら、galician.ldf 中で quoting を呼んでいる他の箇所も変えるべきでは？」とか思いました。些細なことばかりでスミマセン。

Re: Babel（3.8l）バグ対応

2010年 05月 30日(日曜日) 20:09 - 北川弘典の投稿

北川です．

みなさま，eptex-100420 内の 6babel.sh を試してくださってありがとうございます．

> この置換先の \ifx\false は意図としては \iffalse なのだと思います。
はい，その通りです．
\false = \message でないからたまたまうまくいっていただけのような気がします^^;
# どこを勘違いしたのだろうか

また，（e-pTeX の問題ですが）eptexdefs.lib のコピーし忘れが見つかったので，それも直しておきます．

# LOADHYPH_SED を直しておきました，eptex-100420-patch1.diff (5/30 20:21)

Re: Babel（3.8l）バグ対応

2010年 05月 31日(月曜日) 21:36 - 栗山雅俊の投稿

北川さん，こんばんは。
おかげさまでptexliveのBabel対応の方法が大方見えてきました。
ありがとうございます。

安田さんへのコメントにも記しましたが，e-pTeXのコンパイルがなかなか通らず苦戦しております。
例えば途中エラーで落ちた場合に直前までのlogなどを残しておく方法がありますでしょうか。ご教授頂ければ幸いです。

ハイフネーションのアスキーコード化は稲垣さん，安田さんにご検証いただいたとおり正常に動作しているようです。

Re: Babel（3.8l）バグ対応

2010年 05月 31日(月曜日) 21:29 - 栗山雅俊の投稿

Z.R.さん，こんばんは。
検証＆ご指摘いただきましてありがとうございます。

> 「\cup 命令は標準 LaTeX にある」

全くその通りですね。日頃は数式を使わない人文系だとは言え，これはひどすぎました...
\catlup か何かに書き換えるべきですね。

> 「quoting の名前を変えたなら、galician.ldf 中で quoting を呼んでいる他の箇所も変えるべきでは？」

これもご指摘の通りです。何を間違えたのか，先にあげた箇所だけだと思いこんでおりました。手間としてはspanish.ldfを直すのと大して違いはないことになりますが，一括置換で19箇所ありました。

私が確認出来たのは，
220,221,223,464,599,600,654,667,669,673,675(x2),676,678(x2),684,685,686,823行の計19箇所です。
対応方法は一度まとめなおすつもりです。

あと，モイツァさんへの詳細なご説明，ありがとうございます。TeX Live統合への道筋が少しでも見えてくればと思っています。

Re: ptexlive-2009 の Babel 対応

2010年 05月 31日(月曜日) 01:36 - Mojca Miklavec の投稿

I'm one of authors of hyph-utf8 and I'm willing to fix hyph-utf8 (and all patterns) to properly work with pTeX in TeX Live 2010. If anyone wants to cooperate in that, please let me know.

See also this thread on our mailing list:
http://tug.org/pipermail/tex-hyphen/2010-May/000606.html

But I don't speak Japanese, so please post any replies in English.

Re: ptexlive-2009 の Babel 対応

2010年 05月 31日(月曜日) 07:21 - 永田善久の投稿

皆さん，こんにちは。

hyph-utf8 パッケージを保守されているスロヴェニアの Mojca Miklavec さんからのご依頼があったので，ここでアナウンスさせてください。

現在 pTeX が TeX Live 2010 できちんと動くようにすべく，Mojca Miklavec さん，Arthur Reutenauer さん，Karl Berry さん，角藤先生といった方々が精力的に作業してくださっています。

角藤先生は，すでに，loadhyph-*.tex, dehyph*.tex などのファイル内の箇所を

\ifx\kanjiskip\undefined
   \ifx\secondarg\empty
      (UTF-8)
   \else
      (Other)
   \fi
\else
   (Other)
\fi

と書き換えるコードのアイディアを提供されているのですが，その後，話を私に振ってくださいました。

残念ながら，UTF-8 や pTeX をきちんと理解していない私では役不足ですので，どうか皆様，Mojca さんらのお仕事にご協力くだされば，と思います。

宜しくお願いいたします。

Re: ptexlive-2009 の Babel 対応

2010年 05月 31日(月曜日) 22:18 - 栗山雅俊の投稿

永田先生，ご無沙汰しております。
いつも有益なご指摘ありがとうございます。

実は昨日の夜中にhyph-utf8メンテナーのモイツァさんからコメントをいただいたのを発見してびっくりしていたのですが，なるほど事情が飲み込めました。
pTeX が TeX Live に収録されるなど少し前までは夢のような話でしたが，なんとか妙案ができればと思います。

長い目で見れば，日本語に限らず2バイト言語（CJKVその他）すべてをhyph-utf8で切り替えて使えるようになれば大変便利ですね。どんな形になるのかまだ見当がつきませんが，楽しみでもあります。

Re: ptexlive-2009 の Babel 対応

2010年 06月 1日(火曜日) 11:51 - 永田善久の投稿

栗山様，

安田さん，稲垣さん共々，『新版美文書「多言語章」』のご執筆にご尽力なさっていらっしゃること，陰ながら応援させていただいております。（何のお役にも立てず済みません。）

Z.R.さんのご投稿のお蔭で，Mojca さんは早速 pTeX を絡めた「試作版」を作成してくださったようです。

http://tug.org/svn/texhyphen/branches/ptex/hyph-utf8/tex/generic/hyph-utf8/patterns/ptex/?pathrev=427

http://tug.org/svn/texhyphen/branches/ptex/hyph-utf8/tex/generic/hyph-utf8/loadhyph/?pathrev=427

もっとも，Mojca さんが挙げてくださった Mailing list: [tex-hyphen] ptex-specific patterns でのやり取りを拝見していると，「pTeX 用の工夫を現時点で hyph-utf8 にマージすること」には，特に Karl Berry さんが慎重な姿勢でいらっしゃるようです。

ハイフネーション・パタンをめぐっては，ドイツ語のような言語にもちょっとした「揺れ」があります。german-x-2008-06-18, ngerman-x-2008-06-18 等というものが同梱されているのを，最近の TeX をインストールしてみて初めて知りました。

こちらは，

\RequirePackage[german=german-x-2008-06-18]{hyphsubst}

のように hyphsubst パッケージと一緒に用いるようです。

Re: ptexlive-2009 の Babel 対応

2010年 06月 1日(火曜日) 21:29 - 栗山雅俊の投稿

永田先生，

コメントいただきありがとうございます。
大変助かっております。

> （何のお役にも立てず済みません。）

とんでもありません。今回もMojcaさんやhyph-utf8開発チームとやりとりする道筋をつけていただき，おかげ様でいろいろなことが進展できる予感がします。ありがとうございます。

tex-hyphenのメーリングリスト拝見しました（以下参照）。
http://tug.org/pipermail/tex-hyphen/2010-May/thread.html#606

ざっと一読して見て（私自身まだ理解できていない部分もあるかも知れませんが），以下のような話になっていると思われます。もし誤りがありましたらご指摘下さい。

MojcaさんはTeX Forum（ここ）のスレッドの最後でA safe approachとA hacky approachの二つを提案されています。
https://okumuralab.org/tex/mod/forum/discuss.php?d=460&parent=2423

A safe approachのほうはpTeX専用のハイフネーションファイルを用意してやるということで，これは北川さんに作成いただいたパッチを適用したハイフネーションファイルをTeX Live所収のpTeXに同梱してやるだけで済むと思います。

Mojcaさんはtex-hyphenのメーリングリストで，上のA safe approachよりもう少し踏み込んだ，A hacky approachに近い方法（hyph-utf8にマージする）を提案されているようで，それに対してKarl Berryさんは「とりあえず pTeX単独で動くようにするのが先だろう，話はそれから」とコメントされているようです。これが私の理解です。
http://tug.org/pipermail/tex-hyphen/2010-May/000609.html

私も「現時点では」Karlさんの指摘は妥当だと思われ，とりあえず今回はA safe approachで逃げてよいのではないかと思っています。
特に，hyph-utf8開発チームはpTeXの処理方法（特にUnicode，欧文8ビットコードと日本語処理の関係など）を理解するのに手間取っているようで，これは我々ですら理解するのが大変なので，日本語を母語としない方々にはなおさらわかりづらいと思います。こちらの方はもう少し長く時間をとってすり合わせをして行く必要があるかと思われます。

日本のTeX user側から「現時点で」どのような提案をすればよいのか，いま頭を悩ませていますが，もし何かお知恵がありましたらご教授下さい。＞皆様

Re: ptexlive-2009 の Babel 対応

2010年 06月 2日(水曜日) 22:59 - Z. R. の投稿

TeX Live 2010 に pTeX が入るという予定は確定でしたか…。知らなかった……。（参考）

hyph-utf8 に関しては、とにかく今このトピックで議論されている内容、特に北川さんのスクリプトを提供することがまず必要だと考えます。

ところで Mojca さんの質問の中の

is it possible to "safely assume" some particular mode (for example utf8) during pattern loading?
（入力漢字コードについて、パターン読込の時には何か特定のもの（例えば utf8）にしてしまうという処理方法は採れないか？）

これなんですが、勿論「パターン読込時だけ」漢字コード（-kanji）を変えることは無理なので、「フォーマット（.fmt）作成（-ini 起動）だけ」ということを検討してみると、「正しい」フォーマットが生成される条件は

フォーマット作成時に読み込むファイル（plcore.ltx 等）の漢字コードが入力漢字コード指定に対し互換（= 同一 or jis or UTF-8+BOM）である
内部漢字コード指定（-kanji-internal）が実際に使用するものと同一である

なので、これを満たす範囲で固定することが可能なはずです。 ……ということを考えているうちに、ふと次のようなことが思いつきました。

現在の（ptexenc 版）pTeX には jis、sjis、euc、utf8 の 4 つの入力漢字コード指定がある。
指定されたコードは当然読める、加えて ISO-2022-JP（jis）と UTF-8+BOM は（妥当な条件の下で確実に判別できるので）常に読める。
従って、「jis のみ」という設定は「勿体無い」ので、実際には指定が jis の時も sjis と euc の一方（内部コードと同じもの？）が使用可能になっている。
しかし、ここで「本当に jis のみしか読まない」という指定 jisonly があったとする。ISO-2022-JP は完全な 7 ビットコードなので、jisonly ならば 8 ビットバイト（UTF-8 でもレガシーでも）を含むパターンを読み込める。plcore.ltx 等は jis にしておけばよい。実際の p(La)TeX の入力コードは好きに選べる。
あるいは、jisonly で UTF-8+BOM も読めるようにしてもよい。この場合も「同じ妥当な仮定下で」安全に 8 ビットが読める。（8 ビット欧文 TeX と共用する UTF-8 ファイルには BOM はない。）
さらにこの jisonly モードは、8 ビットバイトを含むパッケージで問題が起こったときの一時的な回避策にも使えるはず。

この考えについて何かコメントがありましたらお聞かせください。

Re: ptexlive-2009 の Babel 対応

2010年 06月 3日(木曜日) 00:48 - t tk の投稿

面白いアイディアです。
pTeX + ptexenc の実装では、
現在 --kanji=utf8 では「JIS X 0208の文字集合に含まれるUTF-8の8bitのシーケンス」以外の8bit文字は ^^ab のような形式にする (井上浩一さんの発案) になっています。
これと似たことをやればptexencの改造だけで実現出来そうです。

つまり、ファイルから行読み込みする際に、エスケープシーケンスで指示された7bitのJIS X 0208文字はEUCまたはSJISとして入力バッファに突っ込み、8bit文字は ^^ab のような形式ににして入力バッファに突っ込めばいいわけです。
jisonly で UTF-8+BOM も読めるようにする場合も同様です。

Re: ptexlive-2009 の Babel 対応

2010年 06月 3日(木曜日) 03:55 - 栗山雅俊の投稿

Z. R.さん，ttkさん，ご提案ありがとうございます。大変助かります。

そうしますと，今回の論点としては，とりあえずフォーマットファイル（.fmt）をうまく作成できれば，ひとまず「pTeXで完結する分」については何とか行けるということになりますでしょうか。

> 現在 --kanji=utf8 では「JIS X 0208の文字集合に含まれるUTF-8の8bitのシーケンス」以外の8bit文字は ^^ab のような形式にする (井上浩一さんの発案) になっています。

pTeX-p3.1.4からのこの対応で日本語＋多言語処理能力が飛躍的に高まりました。前回の『美文書』多言語章の記述はまさにこの成果に拠っていました（井上先生には感謝，感謝です）。

フォーマットファイルの作成ですが，土村さんの記述では（ptetex3時代から）platex.fmtは一種類で，これはeuc，sjisに限らず（utf-8も想定している？）共通のものが使えることになっているようです。
http://tutimura.ath.cx/ptetex/?UTF-8%C2%D0%B1%FE%285%29
そうすると，少なくともjis（iso-2022-jp）, euc，sjisの三者では現時点ですでにフォーマットファイルの共有は出来ているということなのでしょうか。

ハイフネーションの側から見ると，euc，sjis＋ラテン，ギリシャ，キリル文字の7ビットコード（具体的にはアクセントなどをlatin transliterationで記す）についてはこれで正常に処理出来ることになります。
（iso8ビットのソースについては入力段階で引っかかるので処理は出来ませんが）

問題はutf-8で，こちらは分綴処理が異なる（アクセントや合字の扱い〜文字コード上で〜が異なっている）はずなので，本来ならばutf-8専用のフォーマットファイルが必要です。hyph-utf8開発チームのテーマがまさにこれで，XeTeXやLuaTeXのようなutf-8デフォルトのパッケージと従来のLaTeXシステムを共存できるように（一括でフォーマットファイルが作成できるように）文字コードを自動判別するというというものです。同じことはpTeXとpTeX-Unicodeの間にも当てはまると思います。

現在のptexencでは，ラテン文字についてはutf-8で入力可能なので，この範囲でutf-8用フォーマットファイルの恩恵を受けることが出来ることになるでしょうか。結局フォーマットファイルは従来のJIS＋7ビット用とutf-8用の二つが必要になると思われます（iso8ビットについては処理が出来ないので考慮から外れます）。この処理が出来ればOKということになりますでしょうか。

とりあえず私が理解できた範囲ですが，もし誤りなどありましたらご指摘いただければ幸いです。

Re: ptexlive-2009 の Babel 対応

2010年 06月 4日(金曜日) 00:17 - Z. R. の投稿

(u)pLaTeX での文字コードの扱いは、LaTeX での体系と pTeX 自身の体系の両方が絡む関係で、非常に複雑になっています。次に挙げるような複数の概念をきちんと分けて考えないと混乱してしまいます。

LaTeX 入力エンコーディング：文書ファイルの文字コード。inputenc のパッケージオプションで指定、値は ascii（これのみ 7 ビット; 他は 8 ビット）, latin1, koi8-r, urf8 等。無指定の場合、8 ビット欧文 LaTeX なら ascii と等価。XeLaTeX／LuaLaTeX ならば「UTF-8 直接入力」になる。
LaTeX フォントエンコーディング：欧文フォントの文字コード。fontenc のパッケージオプションで指定、値は OT1, OT2, LGR（7 ビット）, T1, T2A, LY1（8 ビット）等。Unicode LaTeX の場合は、「Unicode 直接」（XeLaTeX は EU1／LuaLaTeX は EU2）が可能。既定値は OT1。
(u)pLaTeX 和文フォントエンコーディング：和文フォントの文字コード、ハイフネーションとは無関係。普通は固定されていて、pLaTeX では JY1（横書）／JT1（縦書）、upLaTeX では JY2／JT2（同）。
(u)pTeX 入力漢字コード：文書ファイルの文字コード。コマンドラインオプション -kanji で指定。値は jis（ISO-2022-JP）、sjis（Shift_JIS）、euc（EUC-JP）、utf8（UTF-8）。既定値はビルド時に指定する。
(u)pTeX 内部漢字コード：和文の内部処理で用いる符号空間。コマンドラインオプション -kanji-internal で指定。値は sjis（Shift_JIS）および euc（EUC-JP）（符号値を16 ビット整数として扱う）。upTeX ではさらに uptex（Unicode 符号値の 24 ビット整数扱い）も可能（普通はこれを指定）。既定値はビルド時に指定する。ハイフネーションとは直接には無関係。

注意事項：

フォーマットファイルは 5. に依存する。4. には依存しない。
当然、文書ファイルごとにその文字コードは決まっているので、1. と 4. で矛盾する設定は無意味である。pTeX の場合 4. が utf8 以外の場合、事実上 1. は ascii しか選べない。4. が utf8 なら 1. は ascii の他に utf8（utf8x）も可能。
ちなみに、upTeX では文書中で「日本語入力を無効化」する設定に切り替えられる。（一時的に 4. を「なし」にできると考えればよい。）従って、「4.=utf8、1.=ascii」な日本語の文書の途中で「4.=なし、1.=latin1」なフランス語文書を \input する、という芸当が可能。
パターンファイル（正確には、その中のパターンの記述）は 2. に相当するコードで入力しなければならない。だから、もし「直接入力」で記述するなら、通常と異なり、2. の文字コードでファイルを作ることになる。ただし、hyph-utf8 では「UTF-8 で記述されたパターンをマクロで変換する」という処理を行っていて、この場合、「パターンファイル」の文字コードは UTF-8 であるということになる。補足しておくと、パターン読込は、そもそも LaTeX のユーザレベル処理でないので inputenc とは無関係である。
「DVI での和文符号空間」は 5. と連動。sjis と euc の場合は jis（ISO 2022 の GL 表現）、uptex の場合は Unicode（符号値）。
「欧文内部処理の符号空間」は 8 ビット欧文 TeX なら 8 ビット、Unicode TeX なら Unicode（当たり前）。「DVI での欧文符号空間」はこれと同一。

これを踏まえて検討してみます。

そうしますと，今回の論点としては，とりあえずフォーマットファイル（.fmt）をうまく作成できれば，ひとまず「pTeXで完結する分」については何とか行けるということになりますでしょうか。

そうです。そのフォーマットを使うのは「pTeX ユーザ」であって、非英語欧文文字を安全に扱うためのノウハウを持っていると想定できますので（「我々には美文書4版付録Jがある」）。

そうすると，少なくともjis（iso-2022-jp）, euc，sjisの三者では現時点ですでにフォーマットファイルの共有は出来ているということなのでしょうか。

フォーマットファイルは入力漢字コード（4.; utf8 も含む）に依らずに共通のものが使えます。和文は内部漢字コード（5.)に変換されて処理されているからです。逆に言うと、5. が違うものの間では共有できません（無論 1 つのシステムで複数の 5. に対応させる必要性は全くない）。アスキー社のオリジナルの pTeX の場合、4. が euc／sjis なら 5. も同じと決め打ちしていたので（先の理由により）共有は不可能でした。

ハイフネーションの側から見ると，euc，sjis＋ラテン，ギリシャ，キリル文字の7ビットコード（具体的にはアクセントなどをlatin transliterationで記す）についてはこれで正常に処理出来ることになります。
（iso8ビットのソースについては入力段階で引っかかるので処理は出来ませんが）

これはその通りです。（つまり 1. が ascii ならば OK です。）

問題はutf-8で，こちらは分綴処理が異なる（アクセントや合字の扱い～文字コード上で～が異なっている）はずなので，本来ならばutf-8専用のフォーマットファイルが必要です。hyph-utf8開発チームのテーマがまさにこれで，XeTeXやLuaTeXのようなutf-8デフォルトのパッケージと従来のLaTeXシステムを共存できるように（一括でフォーマットファイルが作成できるように）文字コードを自動判別するというというものです。

フォーマットファイル中のパターン情報が依存するのは 1. ではなく 2.（フォントエンコーディング；これには“utf-8”という指定はない）です。8 ビット欧文 LaTeX で UTF-8 入力を用いた（1. に utf8 を指定）としても、2. は不変なので別のパターンを用意する必要はありません。結果的に、1 つのエンジンがパターン情報の異なる複数のフォーマットを持つ必要は生じていないのです。

補足：ところで 1 つの言語について複数のフォントエンコーディング（2.）を使い分けたいということはありえます。例えば、ロシア語では、ASCII 翻字入力ならば 2. は必然的に OT2 ですが、UTF-8 入力（1. が utf8）の場合は 2. は T2A にしたい所です。だからパターンが 1 つしか選べないというのは実は不便だったりします。両方を登録すること自体は可能なのですが、残念ながら、現在の Babel にはパターンを「切り替えて使う」機能がありません。

同じことはpTeXとpTeX-Unicodeの間にも当てはまると思います。現在のptexencでは，ラテン文字についてはutf-8で入力可能なので，この範囲でutf-8用フォーマットファイルの恩恵を受けることが出来ることになるでしょうか。結局フォーマットファイルは従来のJIS＋7ビット用とutf-8用の二つが必要になると思われます（iso8ビットについては処理が出来ないので考慮から外れます）。この処理が出来ればOKということになりますでしょうか。

以上のことを考え合わせると、これは正しくないことが解ると思います。(u)pTeX は欧文については 8 ビットなので、4. を utf8 にしても、さらに 1. を utf8 にしても、また upTeX だとして 5. を uptex（Unicode）にしても、2. は結局変わらないので、パターンを変える必要はないわけです。

Re: ptexlive-2009 の Babel 対応

2010年 05月 31日(月曜日) 10:35 - Z. R. の投稿

Hello Mojca.

I think it is difficult for pTeX to share a single set of hyphenation files with Unicode-aware engines (XeTeX and LuaTeX). The loadhyph-* files could be shared, by elaborating engine detection in some way as Akira Kakuto suggests. The other files, however, must be filtered so that all occurrence of bytes with value 0x80 or greater must be translated to the escaped forms ^^??, and doing so makes the files unusable in Unicode-aware engines that read directly UTF-8 encoded characters.

Here I explain how pTeX processes input from source files (not so) briefly.

The pTeX engine treats ‘Japanese’ and ‘European’ characters in a distinctive way; e.g. pTeX has multiple ‘current’ fonts, each for European, horizontal Japanese and vertical Japanese.
In view of anything but source input, the processing of European characters is done in the same way as 8-bit TeX; e.g. in pTeX you can use 8-bit font encodings like T1, and once 8-bit hyphenation patterns are safely loaded (in some way) then they will perfectly work.
On the processing of Japanese characters, pTeX can handle characters in JIS X 0208 (refer to
http://unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT
for the repertoire of JIS X 0208.) Note that in pTeX a Japanese character is always treated as one character (and thus one token).
Input from source files is always seen in 7-bit ASCII plus JIS X 0208 rendered in either of ISO-2022-JP(jis), Shift_JIS(sjis), EUC-JP(euc) or UTF-8(utf8). The input encoding is specified as a command-line option, so cannot be specified (or changed) in TeX documents.
When pTeX sees a byte with its high bit on, it tries to decode the sequence starting with that byte in the specified encoding; if it succeeeds pTeX thinks there is a Japanese character, and if it fails pTeX thinks there is a 8-bit European character in fallback, as the result of lexical analysis.
- In utf8 mode, only byte sequences that will give a character in JIS X 0208 are deemed to be valid; for everything else decoding will fail.
And finally, pTeX always regards an escaped form ^^?? as a single 8-bit European character.

For example, when pTeX scans a byte sequence <CE A4 21>:

In utf8 mode, pTeX reads it as a Japanese character ‘Τ’<CE A4> and an European character ‘!’<21>, since JIS X 0208 contains basic Greek characters. Putting Japanese characters in hyphenation patterns would cause an error because it does not make sense.
In euc mode, pTeX reads it as a Japanese character ‘里’<CE A4> and an European character ‘!’<21>.
in sjis mode, pTeX reads it as three European characters ^^ce, ^^a4 and ‘!’<21>, since neither CE nor A4 is a lead-byte of sjis double-byte characters.

And when pTeX scans a byte sequence <C3 A4>:

In utf8 mode, pTeX reads it as two European characters ^^c3 and ^^a4, since <C3 A4> means in UTF-8 ‘ä’, which is not a JIS X 0208 character.

Re: ptexlive-2009 の Babel 対応

2010年 05月 31日(月曜日) 15:51 - Mojca Miklavec の投稿

Thanks a lot for the very informative answer. Now this made me think of two possible approaches:

A safe approach that takes more space: auto-generate a new version of patterns in appropriate format, so that pTeX would read them directly.
A hacky approach that takes less space and makes more fun: we did the conversion between unicode and 8-bit encodings; I see no reason why we should not be able to make a "JIS X 0208" to 8bit conversion before loading the patterns. That is: if <CE A4> appears is hyphenation patterns, we would make that character active and map it to appropriate 8-bit character.

(I can try out both and then decide/ask for opinion.)

Now that I understand the process of reading input for hyphenation patterns, a different question: how is a user of pTeX supposed to type Bulgarian or Greek or French documents? In what encoding?

Two other questions to help me play with the second idea (just for fun):

Is it possible to determine the mode (utf8/euc/sjis) when loading the patterns? That is: is it possible to "safely assume" some particular mode (for example utf8) during pattern loading?
Does there exist any reference listing all the JIS X 0208 characters? (The link to Unicode doesn't seem to contain Greek characters - it has no 'X' in name.)

Thanks, Mojca

Re: ptexlive-2009 の Babel 対応

2010年 06月 1日(火曜日) 23:16 - Z. R. の投稿

Now that I understand the process of reading input for hyphenation patterns, a different question: how is a user of pTeX supposed to type Bulgarian or Greek or French documents? In what encoding?

There are two ways to go.

1. Resorting to 7-bit ASCII:
It is good old methodology, such as Fran\c{c}ais, Ellhnik'a (for LGR), Bp2lgarski (for OT2), etc. In this case you must choose a font encoding that allows practical input in ASCII: e.g. for Cyrillic, OT2 allows Latin-transliterated input, but T2A cannot be input with ASCII except typing lengthy LICR commands like \CYRB\cyrsftsn\cyrl\cyrg.... everywhere. Some case requires you have some expertise and some languages do not have such appropriate font encoding at all.

2. UTF-8 input encoding:
As you see, the nature of input handling of pTeX renders the inputenc package almost useless, but there is one important exception: UTF-8. As is derived from the input handling rule, pLaTeX in utf8 mode can do \usepackage[utf8]{inputenc} to get sensible perspective of UTF-8: all characters in JIS X 0208 (those used in ordinary Japanese text) are read as ‘Japanese’ characters (in the sense of pTeX) as expected, and (the bytes representing) all other characters are read as active 8-bit characters, which trigger the processing of inputenc and are interpreted as the intended characters (perhaps in LICR form) in consequence.
For example: The byte sequence 47 C3 B6 64 65 6C E6 95 B0 is read by pLaTeX (utf8) as follows:
G^^c3^^b6del数
And then ^^c3^^b6 outputs ö when processed by inputenc. (This phrase means “Gödel numbering.”)

(Of cource, if your documents contain no Japanese language then the best way to go is not to use pTeX.)

The link to Unicode doesn't seem to contain Greek characters - it has no 'X' in name.

Please just read twice. The first header line of that file clearly says it is “JIS X 0208”, and note that although the revision in year 1990 is not the recent one the repertoire has not been changed since then.

That is: is it possible to "safely assume" some particular mode (for example utf8) during pattern loading?

I guess it is possible, but I could be mistaken for that….