名前: ttk 日時: 2007-08-23 00:28:23 IPアドレス: 61.210.211.*
土村さん、ZRさん、コメントありがとうございます。 >>49182 要は、機能拡張要求が今後あった場合に、 ptexencが膨れ上がってサポートコストが大きくなりすぎ、 最悪プロジェクト全体が沈んでしまうのではないか？ という危惧をしていらっしゃるのですね。 外部テーブルやフィルターの方式を推奨されている理由も分かりました。 \bigfive というのは全然考えていなかったですが、 もし、台湾の方のメンテナーさんが現れて uptex-big5 のようなものを作られるのだったら 大いに構わないのではないかと思います。 元のpTeXがBSD-likeなフリーソフトなのですし。 私自身は、\bigfive をupTeXに入れて下さいといわれても、 現時点では、「\ucs を推奨しupTeXには入れません、 \jis は後方互換のためのサポートであってckを差別しているのではありません」、 と回答すると思います。 しかし、将来upTeXのckでの需要が高まることでもあれば気が変わるかもしれません。 今はまだ夢ですが。 また、\bigfive のようなプリミティヴではなく、 ファイル入力での文字コードのBig5のサポートについていえば、 UTF-8と混在不能なので拒否します。 ( これにしたって台湾のメンテナーさんが別個になさる分には止めることは出来ません ) 7bitでESCを使うISO-2022系ならUTF-8との混在が技術的には可能でしょうが、 ckでISO-2022系はほとんど使われていないようですし要求自体がこないと思います。 > 私は pTeX と upTeX が並走することを想定しています。 私もそう想定しています。が、想定が少し違っているかもしれません。 現在の状況を簡単に言うと、 (1) ASCIIのオリジナルのpTeX (2) pTeX + 土村さんのptexenc(UTF-8サポート付) (3a) uptex --kanji-internal=euc, uptex --kanji-internal=sjis (3b) uptex --kanji-internal=uptex (内部Unicode版) (2)は(1)のASCIIさんに取り込んでもらえるように配慮して 分かりやすく作られたとのことですが、取り込みはまだ実現していません。 (3a)(3b)は(2)から作ったものですが、Unicode用, babel用にいくつか機能を追加しています。 結果的には、(2)からかなり離れたところに来てしまいました。 (3a)と(3b)は、ptexencで切り替えているだけで中身は一緒です。 (3b)は(1)(2)の上位互換ではありませんが、 (3a)は完全に(3a)>(2)>(1)の順に上位互換になっています。 (3b)は(1)の代替にはなりえませんが(3a)はなります。 ただし(3a)は(2)からの改造量も少なくないので信頼性は不安が残るのも事実です。 しかし、(3b)が普及して信頼性・信用が上がって行けば、 (3a)は(1)(2)を完全に置き換えるものとして採用するdistributionも現れるのではないか という想定をしています。 (3a)は(1)(2)と完全に同じ動作をするのに、あえて二つ以上持つのは無駄でしかないですし。 日本語専用の(1)(2) vs Babelもcjkも動く(3b)にオマケでついてくる(3a)と 海外のLinux distributionでどっちが採択に有利か？ 私は後者だと思います。 また、pTeXとupTeXが併走することを想定すると、 スタイルファイル、マクロ類での推奨の文字コードは pTeX用, (1)(2)(3a) JIS X 0208の範囲 ISO-2022-JP upTeX用, (3b) Unicodeの範囲 UTF-8 pTeX/upTeX兼用 JIS X 0208の範囲 ISO-2022-JP となると思います。 このとき(2)(3a)用や兼用の文字コードをUTF-8にすることは想定しにくいです。 ここにも、JIS → Unicode 変換を捨てられない場面が出てきます。 ＃特定のdistributionが統一する、というケースはまた別の話です。 (2)が(1)を整理してUTF-8をオマケでつけたものだ、という位置づけからすると (2)の標準のスタイルファイルの文字コードとしてISO-2022-JPを推奨することを 変更することは出来ないでしょうし、 ptexenc で ISO-2022-JP と UTF-8 の相互変換機能を削除することは不可能だと思います。 「(1)が(2)を取り込んだ上にさらに入力ファイルを一斉にUTF-8ベースに切り替える」 といった過激な方針をASCIIさんがとるとか、 「(2)でUTF-8サポートを削除する」とかいう動きがあれば話は別ですが…。 > 仕様が重厚長大になってきて、将来メンテできる人がいるのでしょうか。 upTeX本体について言えば、 TeXもpTeXも枯れ切っていてほとんど動いていないような状況ですし、 私がサポートできなくなってもpTeXの動きに追従することはさほど難しくないと思います。 ASCIIさんが突然pTeXの大改造に乗り出したりしたら別ですが…。 ptexencにも関数を追加しましたが、理解不能でメンテナンス性を悪化させるシロモノはないと思います。 gs7.07以降のgs-cjkのように本家が大改造を繰り返しているケースとは違うと思います。 ただし、dviwareのset3サポートはちょっとそういう心配があることは言えると思います。 set2の範囲ではupTeX対応のためのdviwareの改造は不要です。 現在は、テスト目的も兼ねてBMP超をじゃんじゃん試していますが、 サポートの負荷とメリットを考えると、 set3はオプション扱いすべきかも知れません。 >>49183 upTeXの狙いはpTeXの資産の継承もありますが、一つにはスピードもあります。 XeTeXのような実フォントの情報を利用しているやり方に 原則全角等幅フォントのpTeX/upTeXが組版品質で負ける日がいずれ来るかもしれません。 しかし、例えばdvioutがXeTeXをサポートする頃には もう私はTeX系のソフトで文章を書く機会が激減しているんじゃないかと思います。 それよりはupTeXの方がいいソリューションになるでしょう。 >>49188 (3a)(3b)のupTeXにおいて \jis の実装コストは全然かかっていません。 上記(2)のままです。 コード変換もptexencの中で(2)で必須の関数を流用しているだけです。 メンテナンス性で言うと \jis を削除する方がよっぽど、(1)から遠く離れて悪化する方向です。 もしかして、ptexencからUnicode ←→ JIS変換を削除する予定でいらっしゃいましたか? >「\jis なんかを廃止までせずとも、 > 機能は残すが、細かな文字表の違いまでの動作保証はしない」 つまるところ、このあたりが許容出来るか出来ないかの差だと思いました。 JIS → Unicode のばらつきの矯正機能を書いてみたら 巨大なテーブルも不要で、追加テーブルさえ不要で、 ptexencへの追加数行で済みました。 次のupTeXに入れてみようと思います。
この書き込みへの返事：