Menu
▾
▴
mlterm-dev-ja — mlterm mailing list(Japanese)
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(170) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(193) |
Feb
(128) |
Mar
(62) |
Apr
(80) |
May
(75) |
Jun
(69) |
Jul
(19) |
Aug
(13) |
Sep
(59) |
Oct
(11) |
Nov
(24) |
Dec
(12) |
| 2003 |
Jan
(23) |
Feb
(73) |
Mar
(120) |
Apr
(18) |
May
(21) |
Jun
(38) |
Jul
(22) |
Aug
(6) |
Sep
(12) |
Oct
(7) |
Nov
|
Dec
|
| 2004 |
Jan
(31) |
Feb
(13) |
Mar
(14) |
Apr
(5) |
May
(1) |
Jun
(3) |
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(18) |
Dec
(7) |
| 2005 |
Jan
(2) |
Feb
(3) |
Mar
(9) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
(2) |
Dec
(5) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
(7) |
Jun
(8) |
Jul
(3) |
Aug
|
Sep
(3) |
Oct
(33) |
Nov
(47) |
Dec
(9) |
| 2007 |
Jan
(8) |
Feb
(11) |
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(10) |
Jul
(1) |
Aug
(24) |
Sep
(8) |
Oct
(3) |
Nov
(3) |
Dec
(10) |
| 2008 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(5) |
Mar
(15) |
Apr
(20) |
May
(6) |
Jun
(74) |
Jul
(44) |
Aug
(19) |
Sep
(17) |
Oct
(29) |
Nov
(10) |
Dec
(6) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(36) |
Apr
(54) |
May
(80) |
Jun
(70) |
Jul
(34) |
Aug
(33) |
Sep
(20) |
Oct
(7) |
Nov
|
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
(13) |
Jun
(7) |
Jul
(2) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(5) |
Feb
(2) |
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
(3) |
May
(1) |
Jun
|
Jul
(4) |
Aug
(4) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2015 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
| 2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mike F. <mf...@su...> - 2001-12-19 19:41:28
|
Mike Fabian <mf...@su...> writes: > Tomohiro KUBOTA <tk...@ri...> writes: > >> 久保田です。 >> >> すみませんが、ぜんぜん分かりません。たぶん kinput2 の問題だと >> 思います。 一昨日の XFree86 CVS バージョンへアップデートした後、 この問題がなくなりました。 -- Mike Fabian <mf...@su...> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。 |
|
From: Araki K. <j00...@ip...> - 2001-12-19 19:00:30
|
荒木です:-)
以下の修正を commit しました。
* prefer_utf8_selection and xct_process_mode options are removed , and copy_paste_via_ucs
option is added.
* BIG5HKSCS is separated into BIG5 and HKSCS.
* memory leaks when copy&paste combined chars. fixed.
* illegal chars based on ISO2022 are accepted if at all possible in ISO2022-based encodings.
* ISO2022 parser doesn't parse correctly when sequence is splited. fixed.
結局、process received strings via UCS(オプション名は copy_paste_via_ucs
です)が off になっていても、UTF8_STRING セレクションを受け入れるようにしま
した。
そうしないと、UTF8 subset でない encoding 使用時に、どうやっても、UTF8_STRING
セレクション要求を受け入れることができなくなるということに気づきまして、
それはそれで問題かと思いましたので。
かわりに、UTF8 以外のエンコーディングで UTF8_STRING セレクション要求を拒
否する、というオプションをつけるかもしれません。
それから、ISO2022KR を UTF8 subset から外していましたが、よく考えると
subset なので(US_ASCIIとKSX1001だけですよね?)含めました。
また、
receive illegal chars using ISO2022 escape sequence
用のオプションはつけませんでした。デフォルトで有効になっています。
いらん、という人はいないだろうという判断です。
ISO-8859-*,ISO-2022-*,EUC-* 各エンコーディングにて、対応していない文字集
合でも、ISO2022に準拠していれば、どんな文字でもペーストができるようになっ
ていると思いますのでご確認下さい。
この修正にともなって、mkf/ 以下を結構大がかりにrewriteしておりますので、
バグが入ったかも知れません_o_
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-19 04:19:13
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] selection options
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Wed, 19 Dec 2001 09:03:12 +0900
> ぼくは mlterm の内部構造はあまり知らないのですが、素朴な疑問として、
> Unicode 変換テーブルはいろんな所で使われるのに、ここでだけ変換を
> さぼることで、リソース上どれだけ得をするのだろう、というのがあります。
UTF8 エンコーディング上で、ja_JP.eucJP ローケールから日本語入力するとか、
eucJP エンコーディングで Anti Alias するとか、eucJP エンコーディング端末
から UTF8 で copy & paste するとか、そういった限られた状況下でしか、UCS
変換テーブルには一切触っていません。
内部コードは、特定の文字集合やエンコーディングに依存していませんので、ご
くありがちな X 端末の使用用途であれば、テーブルを使った変換処理は一切行
わなくてもよいようになっています。
> PS やっとこさ、mlterm が Debian Woody (testing) に入れられました。
> Sid (unstable) から Woody に入るのに、10 日あまりの観察期間を
> 必要とするようです。これで、Debian の次期バージョン (3.0) に
> mlterm が入ることが確実となりました。
それはよかったです:)
では
--
kiken
j00...@ip...
|
|
From: Tomohiro K. <tk...@ri...> - 2001-12-18 23:54:12
|
久保田です。 At 18 Dec 2001 23:06:58 +0900, Araki Ken wrote: > すみません、「答える/答えない」ということです。 > > メリットというか狙いは、UCS変換テーブルにアクセスしないですませられるオプ > ションは、あったほうがいいだろう、ということです。 ぼくは mlterm の内部構造はあまり知らないのですが、素朴な疑問として、 Unicode 変換テーブルはいろんな所で使われるのに、ここでだけ変換を さぼることで、リソース上どれだけ得をするのだろう、というのがあります。 しかし、特に異議はありません。これでいいと思います。 PS やっとこさ、mlterm が Debian Woody (testing) に入れられました。 Sid (unstable) から Woody に入るのに、10 日あまりの観察期間を 必要とするようです。これで、Debian の次期バージョン (3.0) に mlterm が入ることが確実となりました。 --- 久保田智広 Tomohiro KUBOTA <ku...@de...> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ |
|
From: Hironori S. <hs...@mt...> - 2001-12-18 15:17:57
|
$B:dK\$G$9!#(B > $B5WJ]ED$G$9!#(B > JIS X 0213 $B$NJ8;z$,(B Unicode $B$KF~$C$F$$$k$+$I$&$+!"$H$$$&$N$O!"(B > $BJQ49%F!<%V%k$,B8:_$7$J$$$3$H$K$O0UL#$,$"$j$^$;$s!#$H$$$&$o$1$G!"(B > http://www.cse.cuhk.edu.hk/~irg/ > $B$K!"JQ49%F!<%V%k$i$7$-$b$N$,$"$k$h$&$G$9!#$^$@FbMF$O8+$F$$$^$;$s!#(B N807_TablesX0123-UCS.zip $B$G$9$M(B($BL>A0$OJQ$G$9$,(B^^;)$B!#(B $B4{$K!"(B6$B7n;~E@$GMn$7$F$^$7$?!#(B($B%\%1%\%1$G$9$M(B...) $B$G!"FbMF$G$9$,Hs4A;z$K4X$7$F$O0lJ8;z$r=|$-LdBj$J$$$H;W$$$^$9!#(B $BLdBj$N0lJ8;z$O!"(B JIS X 0213-1 0x2B58 $B%@%$%"%/%j%F%#%+%k%^!<%/(B($B9g@.2DG=(B), $BO"7k$7$F$$$k(B COMBINING DIACRITICAL MARKS, LINKING MARK $B$G!"(B U+203F UNDERTIE $B$KBP1~IU$1$5$l$F$$$^$9$,!"(BU+203F $B$O7k9gJ8;z$G$O$J$$$N$G$9!#(B $B$7$+$7!"(BUnicodeData-3.2.0d6.txt $B$K$O!"$=$l$i$7$-$b$N$O8+Ev$?$j$^$;$s!#(B $B$I$&$$$&(B($B@/<#E*(B)$B7hCe$,$D$$$F$$$k$N$G$7$g$&$M!#(B $BJ8;z$H$7$F$OA4ItF~$C$F$$$k$N$G$9$,!"4v$D$+9g@.=hM}$NI,MW$J$b$N$,(B $B$"$j$^$9!#FC$K(B 0x2B65 RISING SYMBOL <=> U+02E9 + U+02E5 0x2B66 FALLING SYMBOL <=> U+02E5 + U+02E9 $B$J$s$+!"$H$C$F$b7y$i$7$$$1$l$I!#(B ----------------------------------- $B:dK\(B $B9@B'(B <hs...@mt...> http://www2u.biglobe.ne.jp/~hsaka/ |
|
From: Araki K. <j00...@ip...> - 2001-12-18 14:11:59
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] selection options
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Tue, 18 Dec 2001 21:16:29 +0900
> > 端末エンコーディング 受信タイプ 変換処理
> > -------------------------------------------------------------
> > UTF8 COMPOUND_TEXT 変換して受け取る
> > UTF8 UTF8_STRING そのまま受け取る
> > UCS-subset,2022 COMPOUND_TEXT オプション1,2
> > UCS-subset,2022 UTF8_STRING オプション1,2
> > UCS-subset,non2022 COMPOUND_TEXT オプション1
> > UCS-subset,non2022 UTF8_STRING オプション1
> > others COMPOUND_TEXT オプション2
> > others UTF8_STRING オプション2
> いいと思います。2 がオフのときは、「端末エンコーディングでサポート
> される文字集合に属する文字はそれに変換し、そうでない文字は捨てる」
> ですよね。
そうです。
> > 端末エンコーディング 優先する受信タイプ 優先する送信タイプ
> > -------------------------------------------------------------
> > UTF8 UTF8_STRING UTF8_STRING
> > UCS-subset,2022 オプション1 オプション1
> > UCS-subset,non2022 オプション1 オプション1
> > others COMPOUND_TEXT COMPOUND_TEXT
> に変更するということですが、送信タイプについて、「優先」って
> 決めることができましたっけ? (すみません、セレクションのことが
> あまりよく分かってないのですが、セレクションのタイプとして
> [サポートされているなかで] 何を使うか、というのは、セレクション
> 要求側つまり受信側、ペースト側が決めることですよね)。UTF8_STRING
> 要求に「答える/答えない」ならできますが、あえて「答えない」
> メリットというのは何かありますか?
すみません、「答える/答えない」ということです。
メリットというか狙いは、UCS変換テーブルにアクセスしないですませられるオプ
ションは、あったほうがいいだろう、ということです。
X端末のような軽くあるべきソフトが、UTF8_STRING を優先するアプリケーション
と copy&paste しただけで、swap in/out を起こしうるというのはあまり好ましく
ないでしょうから。
> 英語表現をもうちょっと練ったほうがいいかも。
はい、其の辺指摘していただくと大変ありがたいです。
> UCS subset encodings
> ---> for Unicode-subset encodings
> encodings based on ISO2022
> ---> for ISO2022-based encodings
> ---> for ISO2022-compliant encodings
for Unicode-subset encodings
for ISO2022-compliant encodings
これでいこうと思います。
> prefer utf8 to xct
> ---> prefer UTF8_STRING to COMPOUND_TEXT for paste
> ---> process the received strings via UCS
> forcibly convert inconvertible char
> ---> receive illegal chars using ISO2022 escape sequence
これについても、
process the received strings via UCS
receive illegal chars using ISO2022 escape sequence
こうしようと思います。
> 文字数制限はかなり厳しいので、短かくしなければならないのですが、
> 一方で、かなり難しい概念を表現しようとしているのも確かです。
> 詳しい説明は manpage に任せるとしても、最低限必要な説明でさえ、
> ある程度の長さになるのは仕方がないのではないかと思います。
これはそのとおりだと思います。
では
--
kiken
j00...@ip...
|
|
From: Tomohiro K. <tk...@ri...> - 2001-12-18 12:07:31
|
久保田です。 At 18 Dec 2001 14:11:08 +0900, Araki Ken wrote: > というわけで、もう少し拡張し、(a)のケースおよび(b)のケースについて、 > > 1. UCS を経由した変換により、同一視できる文字は極力端末 > エンコーディングに準拠する形で受け取れるようにする。 > UTF8_STRING によるセレクションを優先するのと同値(オプション(d),(e)を包接) > (prefer utf8 in receiving) > > 2. 端末エンコーディングでサポートされる文字集合に属する文字は > それに変換し、そうでない文字は ISO2022 エスケープシーケンスを > 用いた表現で端末に送る。 > (forcibly convert inconvertible char) > > # 2の機能は、ちょっと面倒ですけれど、なんとか実装してみます。 > 端末エンコーディング 受信タイプ 変換処理 > ------------------------------------------------------------- > UTF8 COMPOUND_TEXT 変換して受け取る > UTF8 UTF8_STRING そのまま受け取る > UCS-subset,2022 COMPOUND_TEXT オプション1,2 > UCS-subset,2022 UTF8_STRING オプション1,2 > UCS-subset,non2022 COMPOUND_TEXT オプション1 > UCS-subset,non2022 UTF8_STRING オプション1 > others COMPOUND_TEXT オプション2 > others UTF8_STRING オプション2 いいと思います。2 がオフのときは、「端末エンコーディングでサポート される文字集合に属する文字はそれに変換し、そうでない文字は捨てる」 ですよね。 > ついでに、UCS subset encodings の場合に、相手方に送信する際の動作として、 > > 3. UTF8_STRING 要求に応える > (accept utf8 in sending) > > というオプションも設けたいです。 > 端末エンコーディング 優先する受信タイプ 優先する送信タイプ > ------------------------------------------------------------- > UTF8 UTF8_STRING UTF8_STRING > UCS-subset,2022 オプション1 オプション3 > UCS-subset,non2022 オプション1 オプション3 > others COMPOUND_TEXT COMPOUND_TEXT これは、 > 端末エンコーディング 優先する受信タイプ 優先する送信タイプ > ------------------------------------------------------------- > UTF8 UTF8_STRING UTF8_STRING > UCS-subset,2022 オプション1 オプション1 > UCS-subset,non2022 オプション1 オプション1 > others COMPOUND_TEXT COMPOUND_TEXT に変更するということですが、送信タイプについて、「優先」って 決めることができましたっけ? (すみません、セレクションのことが あまりよく分かってないのですが、セレクションのタイプとして [サポートされているなかで] 何を使うか、というのは、セレクション 要求側つまり受信側、ペースト側が決めることですよね)。UTF8_STRING 要求に「答える/答えない」ならできますが、あえて「答えない」 メリットというのは何かありますか? > +--------+----------+----------+-----+ > |encoding|copy&paste|appearance|other| > ++ - - - - - - - - - - - - +------+ > | +- UCS subset encodings -----------------+ | > | |[ ] prefer utf8 to xct | | > | +----------------------------------------+ | > | +- encodings based on ISO2022 -----------+ | > | |[ ] forcibly convert inconvertible char | | > | +----------------------------------------+ | > +--------------------------------------------+ 英語表現をもうちょっと練ったほうがいいかも。ぼくもあまり良い案は ないですが、たとえば、 UCS subset encodings ---> for Unicode-subset encodings encodings based on ISO2022 ---> for ISO2022-based encodings ---> for ISO2022-compliant encodings 上記のふたつは、話題にしているエンコーディングというのが mlterm の エンコーディングのことだということが明確になればいいのですが。 (ぼくの案でもその点はいまいちです)。また、UCS のサブセットである ということと、ISO2022 に準拠しているということが、直交している概念 であり、排他的な概念ではない、ということがうまく伝わるかどうか、 ちょっと心配です。後者については -compliant の案の方がいいと 思います。また、UCS を Unicode とするほうが通りがいいと思います。 UCS subset encodings ---> when mlterm encoding is a subset of Unicode encodings based on ISO2022 ---> when mlterm encoding is compliant with ISO2022 とするのも、ひとつの手ですね。 prefer utf8 to xct ---> prefer UTF8_STRING to COMPOUND_TEXT for paste ---> process the received strings via UCS forcibly convert inconvertible char ---> receive illegal chars using ISO2022 escape sequence これらについては、受信側に立つときの動作を規定している、という ことが明確になればいいと思います。また、専門用語については、 UTF8_STRING だとか COMPOUND_TEXT というような正式名称を用いた ほうがいいと思います。どちらにせよ、ほとんどの人は知らない言葉 ですが、知りたい人は調べることができるように。 prefer utf8 to xct については、「COMPOUND_TEXT よりも UTF8_STRING を好む」ということよりも、「UCS を経た変換を用いることにより 文字の同一視を行う」ということのほうが重要な点だと思います。 ですので、ふたつの案のうち、process the received strings via UCS のほうがおすすめです。ただこの案だと、「同一視」という ことが入っていません。どれだけ長くてもいいのなら、 「identify equivalent characters from different character sets by converting/processing the received selection via UCS」という 感じなのでしょうが、「同一視」ということを表現するためだけに、 「identify」「equivalent」「different character set」という 長い言葉遣いが必要になり、これはちょっと諦めないといけないかな、 という感じです。(identify だけでも同一視という意味はないことは ないですが、それだけだと別の意味にとられる恐れがありそう)。 forcibly convert inconvertible char については、「当該エンコー ディングには含まれない文字を ISO2022 のエスケープシーケンスを 用いて無理やり受信する」という意味が伝えられればいいと思うの ですが、ぼくの案だと「当該エンコーディングに含まれない」という のが「illegal」となり、ちょっと意味があいまいになっています。 が、これを正しく伝えるとなるとやはり長くなってしまいます。いくら 長くなってもいいのなら、「receive characters which don't belong to the mlterm encoding forcibly by using ISO2022 escape sequence」 という感じでしょうか。「ISO2022 のエスケープシーケンスを用いて」 という部分は絶対に削れないと思ったので、ぼくの案ではそれを残し、 「当該エンコーディング」とか「無理やり」とかを削ってあります。 文字数制限はかなり厳しいので、短かくしなければならないのですが、 一方で、かなり難しい概念を表現しようとしているのも確かです。 詳しい説明は manpage に任せるとしても、最低限必要な説明でさえ、 ある程度の長さになるのは仕方がないのではないかと思います。 --- 久保田智広 Tomohiro KUBOTA <ku...@de...> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ |
|
From: Tomohiro K. <tk...@ri...> - 2001-12-18 10:58:18
|
久保田です。 At Tue, 18 Dec 2001 18:35:56 +0900 (JST), sakamoto hironori wrote: > 先日、公開された Unicode 3.2 BETA > http://www.unicode.org/versions/beta.html > ですが、 > http://www.unicode.org/Public/BETA/Unicode3.2/UnicodeData-3.2.0d6.txt > を眺めたところ、JIS X 0213 の文字(仮名の拡張や記号類)が > めでたく入っています。全部入っているかどうかはまだ見ていません。 > # 既にチェックしている人/グループを御存知でしたら教えてください。 JIS X 0213 の文字が Unicode に入っているかどうか、というのは、 変換テーブルが存在しないことには意味がありません。というわけで、 http://www.cse.cuhk.edu.hk/~irg/ に、変換テーブルらしきものがあるようです。まだ内容は見ていません。 また、ここに載っているものがどれだけの強制力があるのか、という ことも、知りません。 --- 久保田智広 Tomohiro KUBOTA <ku...@de...> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ |
|
From: Hironori S. <hs...@mt...> - 2001-12-18 09:38:21
|
$B:dK\$G$9!#(B $B@hF|!"8x3+$5$l$?(B Unicode 3.2 BETA http://www.unicode.org/versions/beta.html $B$G$9$,!"(B http://www.unicode.org/Public/BETA/Unicode3.2/UnicodeData-3.2.0d6.txt $B$rD/$a$?$H$3$m!"(BJIS X 0213 $B$NJ8;z(B($B2>L>$N3HD%$d5-9fN`(B)$B$,(B $B$a$G$?$/F~$C$F$$$^$9!#A4ItF~$C$F$$$k$+$I$&$+$O$^$@8+$F$$$^$;$s!#(B # $B4{$K%A%'%C%/$7$F$$$k?M(B/$B%0%k!<%W$r8fB8CN$G$7$?$i65$($F$/$@$5$$!#(B http://www.unicode.org/Public/BETA/Unicode3.2/EastAsianWidth-3.2.0d4.txt $B$K$bE,MQ$5$l$F$$$kMM$G$9!#(B # $B$G$b!"(BJIS X 0213 $B$K(B MICRON $B$r=|$-A4It$"$k$O$:$N!"(BU+00A1-00FF $B$N(B # $BB?$/$,(B N $B$K$J$C$F$$$k$N$OG<F@$$$+$J$$!#(B # $B$H$$$&$+!"F1$8%9%/%j%W%H$KB0$9$kJ8;z$N4V$G0c$&$C$F$N$O$J$s$@$+$J$!!#(B ----------------------------------- $B:dK\(B $B9@B'(B <hs...@mt...> http://www2u.biglobe.ne.jp/~hsaka/ |
|
From: Araki K. <j00...@ip...> - 2001-12-18 05:26:47
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] selection options
From: Araki Ken <j00...@ip...>
Message-ID: <200...@pd...>
Date: 18 Dec 2001 14:11:08 +0900
> ついでに、UCS subset encodings の場合に、相手方に送信する際の動作として、
>
> 3. UTF8_STRING 要求に応える
> (accept utf8 in sending)
>
> というオプションも設けたいです。
すみません、これ不要ですね。
オプション1が指定されているかどうかで判断するので十分ですね。
ということは、
端末エンコーディング 優先する受信タイプ 優先する送信タイプ
-------------------------------------------------------------
UTF8 UTF8_STRING UTF8_STRING
UCS-subset,2022 オプション1 オプション1
UCS-subset,non2022 オプション1 オプション1
others COMPOUND_TEXT COMPOUND_TEXT
こうなって、設定画面も、
+--------+----------+----------+-----+
|encoding|copy&paste|appearance|other|
++ - - - - - - - - - - - - +------+
| +- UCS subset encodings -----------------+ |
| |[ ] prefer utf8 to xct | |
| +----------------------------------------+ |
| +- encodings based on ISO2022 -----------+ |
| |[ ] forcibly convert inconvertible char | |
| +----------------------------------------+ |
+--------------------------------------------+
こんな感じですね。
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-18 05:16:00
|
荒木です:-)
Subject: [Mlterm-dev-ja] selection options
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Mon, 17 Dec 2001 09:03:32 +0900
> 端末エンコーディング セレクション どうする?
> -------------------------------------------------------------
> UTF8 COMPOUND_TEXT 変換して受け取る
> UTF8 UTF8_STRING そのまま受け取る
> UCS-subset,2022 COMPOUND_TEXT 人によって好みが違う->オプション(a)
> UCS-subset,2022 UTF8_STRING 変換して受け取る
> UCS-subset,non2022 COMPOUND_TEXT UCS 経由変換 (オプション(b))
> UCS-subset,non2022 UTF8_STRING 変換して受け取る
> others COMPOUND_TEXT そのまま (オプション(c))
> others UTF8_STRING 変換して受け取る
> オプション(a)
> 1. UCS を経由した変換により、同一視できる文字は極力端末
> エンコーディングに準拠する形で受け取れるようにする。
> 2. 端末エンコーディングでサポートされる文字集合に属する文字は
> それに変換し、そうでない文字は ISO2022 エスケープシーケンスを
> 用いた表現で端末に送る。
> 3. 漢字 (JISX0208, JISX0212, JISX0213, KSX1001, GB2312, Big5 に
> 属する文字? もっと正確に判断する?) は 2、それ以外は 1 の
> 方法を用いる。
うげげ、3 は細かすぎますので、きついです^_^;
> オプション(b)
> 1. UCS を経由した変換により、同一視できる文字は極力端末
> エンコーディングに準拠する形で受け取れるようにする。
> 2. 違う文字集合に属する文字は捨てる。
> オプション(c)
> 1. 端末エンコーディングでサポートされる文字集合だけを受け取り、
> 端末エンコーディングでサポートされない文字は捨てる。
> 2. 端末エンコーディングでサポートされない文字集合に属する
> 文字であってもそのまま受け取る。
>
> これくらいがあると思いますが、「捨てる」というオプションは
> なくてもいいと思います。とすると、オプション (b-2) と (c-1) は
> 消え、(b) と (c) はそれぞれ選択肢がひとつしかなくなってしまうので
> オプションでさえなくなり、生き残るのはオプション (a) だけとなります。
わたしは、特に(b)について、UCSを経由せず捨てるというオプションはあったほ
うがいいと思います。
UCS 変換テーブルにアクセスするのは、特にメモリの制約が厳しい環境ではなる
べく避けた方がよいので。
# OS 次第では、起動時から、UCS 変換テーブルまでメモリにロードされる環境
# もあるでしょうけれど。
> で、UTF8_STRING と COMPOUND_TEXT のどちらを要求するかですが、
>
> 端末エンコーディング どうする?
> -------------------------------------------------------------
> UTF8 UTF8_STRING
> UCS-subset,2022 人によって好みが異なる -> オプション(d)
> UCS-subset,non2022 UTF8_STRING (どうせ必ず UCS 経由変換するのだから)
> others COMPOUND_TEXT
捨てるというオプションがあったほうがいいと判断すると、
UCS-subset,non2022 UTF8_STRING (どうせ必ず UCS 経由変換するのだから)
のケースでは、オプション切替えができたほうがいいと思います。(オプション(e))
ただ、
> オプション(d) ですが、
> - オプション(a)が「UCS経由変換」のときは、UTF8_STRING に決まってる
> - オプション(a)が「ISO2022」あるいは「漢字のみISO2022」のときは、
> COMPOUND_TEXT に決まってる
> ということで、独立なオプションではないので消える。
いわれてみますと、これはそのとおりですので、(d),(e)とも、(a),(b)オプショ
ンのUCS経由変換に包接してしまうのが賢そうです。
> 結論として、オプション(a) のみが生き残る。
というわけで、もう少し拡張し、(a)のケースおよび(b)のケースについて、
1. UCS を経由した変換により、同一視できる文字は極力端末
エンコーディングに準拠する形で受け取れるようにする。
UTF8_STRING によるセレクションを優先するのと同値(オプション(d),(e)を包接)
(prefer utf8 in receiving)
2. 端末エンコーディングでサポートされる文字集合に属する文字は
それに変換し、そうでない文字は ISO2022 エスケープシーケンスを
用いた表現で端末に送る。
(forcibly convert inconvertible char)
# 2の機能は、ちょっと面倒ですけれど、なんとか実装してみます。
この二つのオプションを指定できるようにしたいです。
ついでに、UCS subset encodings の場合に、相手方に送信する際の動作として、
3. UTF8_STRING 要求に応える
(accept utf8 in sending)
というオプションも設けたいです。
一方、自動認識するかどうか、というオプションは外してよいと思います。
上記以外の変更はできないようにしても問題ないと思いますので。
まとめますと、
端末エンコーディング 受信タイプ 変換処理
-------------------------------------------------------------
UTF8 COMPOUND_TEXT 変換して受け取る
UTF8 UTF8_STRING そのまま受け取る
UCS-subset,2022 COMPOUND_TEXT オプション1,2
UCS-subset,2022 UTF8_STRING オプション1,2
UCS-subset,non2022 COMPOUND_TEXT オプション1
UCS-subset,non2022 UTF8_STRING オプション1
others COMPOUND_TEXT オプション2
others UTF8_STRING オプション2
端末エンコーディング 優先する受信タイプ 優先する送信タイプ
-------------------------------------------------------------
UTF8 UTF8_STRING UTF8_STRING
UCS-subset,2022 オプション1 オプション3
UCS-subset,non2022 オプション1 オプション3
others COMPOUND_TEXT COMPOUND_TEXT
設定画面は、
+--------+----------+----------+-----+
|encoding|copy&paste|appearance|other|
++ - - - - - - - - - - - - +------+
| +- UCS subset encodings -----------------+ |
| |[ ] prefer utf8 in receiving | |
| |[ ] accept utf8 in sending | |
| +----------------------------------------+ |
| +- encodings based on ISO2022 -----------+ |
| |[ ] forcibly convert inconvertible char | |
| +----------------------------------------+ |
+--------------------------------------------+
こんな感じでどうでしょう?
では
--
kiken
j00...@ip...
|
|
From: Tomohiro K. <tk...@ri...> - 2001-12-16 23:54:39
|
久保田です。
At 16 Dec 2001 23:52:52 +0900,
Araki Ken wrote:
> 考えてみると、現状のやりかたもあまりこなれているとはいえませんね。
>
> 実装したい個々の機能としては、
>
> 1. セレクションで受け取ったデータを、一旦 UCS に変換した後、端末エンコー
> ディングに変換して端末に吐き出す。
> 2. セレクションで受け取ったデータを、エスケープシーケンスでいちいち文字
> 集合を指示するISO2022シーケンスに変換して端末に吐き出す。
> 3. セレクション要求を出す/受け取る場合に、UTF8 でのセレクションを優先す
> る。
> 4. 端末エンコーディングが、Unicode のサブセットかどうかを調べる。
> 5. 端末エンコーディングが、ISO2022 に準拠しているかどうかを調べる。
>
> この5つです。
まず、これらのオプションをどう使って何をやりたいのかを考えましょう。
1. Unicode のサブセットであるような端末エンコーディングのとき、
現在の端末エンコーディングに含まれない文字集合に属する文字であって
も、UCS で同一視される文字は現在の端末エンコーディングに準拠する
形でセレクションが受け取れるようにしたい。
2. 逆に、UCS で同一視される文字であっても、ISO2022 で別な文字集合に
属する文字は、ISO2022 エスケープシーケンスを使って (現在の端末
エンコーディングから見れば間違いだが) その文字集合の情報を保持した
ままセレクションを受け取りたい。
3. できるだけ多種多様なセレクションを正しく受け取れるようにしたい。
やりたいこと、つまりユーザのニーズは、このくらいだと思います。
端末エンコーディング セレクション どうする?
-------------------------------------------------------------
UTF8 COMPOUND_TEXT 変換して受け取る
UTF8 UTF8_STRING そのまま受け取る
UCS-subset,2022 COMPOUND_TEXT 人によって好みが違う->オプショ
ン(a)
UCS-subset,2022 UTF8_STRING 変換して受け取る
UCS-subset,non2022 COMPOUND_TEXT UCS 経由変換 (オプション(b))
UCS-subset,non2022 UTF8_STRING 変換して受け取る
others COMPOUND_TEXT そのまま (オプション(c))
others UTF8_STRING 変換して受け取る
ここで、
UTF8 UTF8。(GB18030 も?)
UCS-subset,2022 UCS のサブセットでかつ ISO2022 準拠。
EUC-JP, ISO-2022-KR, ISO-8859-1, TIS-620 など。
UCS-subset,non2022 UCS のサブセットでかつ ISO2022 に準拠しない。
Big5, Shift_JIS, GBK, KOI8-R など。
others UCS のサブセットでない。(現状ではすべて
ISO2022 準拠で stateful)。ISO-2022-JP-2 など。
オプション(a)
1. UCS を経由した変換により、同一視できる文字は極力端末
エンコーディングに準拠する形で受け取れるようにする。
2. 端末エンコーディングでサポートされる文字集合に属する文字は
それに変換し、そうでない文字は ISO2022 エスケープシーケンスを
用いた表現で端末に送る。
3. 漢字 (JISX0208, JISX0212, JISX0213, KSX1001, GB2312, Big5 に
属する文字? もっと正確に判断する?) は 2、それ以外は 1 の
方法を用いる。
オプション(b)
1. UCS を経由した変換により、同一視できる文字は極力端末
エンコーディングに準拠する形で受け取れるようにする。
2. 違う文字集合に属する文字は捨てる。
オプション(c)
1. 端末エンコーディングでサポートされる文字集合だけを受け取り、
端末エンコーディングでサポートされない文字は捨てる。
2. 端末エンコーディングでサポートされない文字集合に属する
文字であってもそのまま受け取る。
これくらいがあると思いますが、「捨てる」というオプションは
なくてもいいと思います。とすると、オプション (b-2) と (c-1) は
消え、(b) と (c) はそれぞれ選択肢がひとつしかなくなってしまうので
オプションでさえなくなり、生き残るのはオプション (a) だけとなります。
で、UTF8_STRING と COMPOUND_TEXT のどちらを要求するかですが、
端末エンコーディング どうする?
-------------------------------------------------------------
UTF8 UTF8_STRING
UCS-subset,2022 人によって好みが異なる -> オプション(d)
UCS-subset,non2022 UTF8_STRING (どうせ必ず UCS 経由変換するのだ
から)
others COMPOUND_TEXT
オプション(d) ですが、
- オプション(a)が「UCS経由変換」のときは、UTF8_STRING に決まってる
- オプション(a)が「ISO2022」あるいは「漢字のみISO2022」のときは、
COMPOUND_TEXT に決まってる
ということで、独立なオプションではないので消える。
結論として、オプション(a) のみが生き残る。
こんな感じで、いかがでしょうか。
---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
|
|
From: Araki K. <j00...@ip...> - 2001-12-16 14:57:33
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] commig log
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Sun, 16 Dec 2001 20:37:28 +0900
考えてみると、現状のやりかたもあまりこなれているとはいえませんね。
実装したい個々の機能としては、
1. セレクションで受け取ったデータを、一旦 UCS に変換した後、端末エンコー
ディングに変換して端末に吐き出す。
2. セレクションで受け取ったデータを、エスケープシーケンスでいちいち文字
集合を指示するISO2022シーケンスに変換して端末に吐き出す。
3. セレクション要求を出す/受け取る場合に、UTF8 でのセレクションを優先す
る。
4. 端末エンコーディングが、Unicode のサブセットかどうかを調べる。
5. 端末エンコーディングが、ISO2022 に準拠しているかどうかを調べる。
この5つです。
これらを、いくつかのオプション指定の形で、うまくまとめたいんですが、ど
うするのがよいか、アイデアはありませんでしょうか?
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-16 14:16:32
|
荒木です:-)
結合文字を使っていると、copy&paste の際にメモリリークします。
パッチです。
# 例のcopy&pasteでのcore dumpの問題とは関係ないとは思いますが...
では
--
kiken
j00...@ip...
Index: ml_term_screen.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_term_screen.c,v
retrieving revision 1.222
retrieving revision 1.223
diff -u -r1.222 -r1.223
--- ml_term_screen.c 2001/12/16 09:13:55 1.222
+++ ml_term_screen.c 2001/12/16 10:54:04 1.223
#include "ml_term_screen.h"
@@ -2510,6 +2510,8 @@
}
ml_str_copy( *chars , buf , size) ;
+
+ ml_str_final( buf , size) ;
return 1 ;
}
|
|
From: Araki K. <j00...@ip...> - 2001-12-16 11:46:10
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] commig log
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Sun, 16 Dec 2001 20:37:28 +0900
> すみません、理解力がなくて、何度も質問してばっかりですが。
いえ、とんでもないです_o_
> すみません、まだよくわからないんですが、ctext を受け取るというのは、
> mlterm へのペースト時ですよね。ふつう、そういう場合、どんな時でも
> 必ず端末のエンコーディングに変換しないといけないのではないのですか?
> (つまり、そうしないと正常に動作しない)。
例えば、eucjp は ISO2022 準拠なエンコーディングですから、そのパーサは、
GR に JISX0208 が暗黙に指示された、ISO2022 パーサにすぎません。
ですので、端末側のエンコーディングが eucjp である場合、結局は、受け取
った文字列を、ISO2022 として解釈しますので、ctext のように汎用性の高い
ISO2022 シーケンスであれば(一部問題はでますが)、正常に解釈可能です。
> -c=raw というのは、どういうときに使うのでしょうか? つまり、端末の
> エンコーディングとは違うもの (CTEXT) が、端末に対して送られる、
> ということですよね。これは正常に動作しないのではないですか?
使用目的は、例えば、相手が KSC5601 文字列を CTEXT で送ってきた場合に、
eucjp な端末でも表示できるようにする、というようなものです。
CTEXT は、GR に ISO8859 が暗黙に指示されていますので、GL のみを使った
7bit ISO2022 に変換したほうがいいんですが、まぁ、ctext のまま流しても
ほぼ同じことだから問題なかろうという判断です。
# 旧来の conv_to_generic_iso2022 オプションを整理しただけで、実用性はそ
# れほど求めていませんので。
> また、ctext 以外のペースト (たとえば utf8 とか) を受け取ったときには、
> どうなるのでしょうか。
これは、ctext を受け取った時の挙動を設定するオプションですから、utf8
を受け取った場合は関係ありません。
> つまり、ペーストを受けた mlterm がペースト元に対して UTF8 な
> selection を要求したにもかかわらず、CTEXT が返ってきた場合、
> ということですね。
そうです。
では
--
kiken
j00...@ip...
|
|
From: Tomohiro K. <tk...@ri...> - 2001-12-16 11:28:38
|
久保田です。 すみません、理解力がなくて、何度も質問してばっかりですが。 At 16 Dec 2001 18:45:00 +0900, Araki Ken wrote: > まず、-c(xct_process_mode) オプションの意味を変えました。 > > -c=ucs: 受け取った ctext を ucs に変換します。(旧来の pre_conv_xct_to_ucs 相当) > -c=raw: 受け取った ctext をそのまま pty に流します。(旧来の conv_to_generic_iso2022 相当) > ただし、端末エンコーディングが、ISO2022 準拠な場合にしか有効になりません。 > -c=normal: 受け取った ctext を 端末エンコーディングに変換します。(従来の通常動作) すみません、まだよくわからないんですが、ctext を受け取るというのは、 mlterm へのペースト時ですよね。ふつう、そういう場合、どんな時でも 必ず端末のエンコーディングに変換しないといけないのではないのですか? (つまり、そうしないと正常に動作しない)。 -c=ucs というのが、pre_conv_xct_to_ucs ということは、ctext を 受け取ったとき、いったん UCS に変換してから端末エンコーディング へと 2 段階に変換する、ということですね? (つまり、UCS に変換して そのまま、ということはないですよね?) これの使い道としては、別の 文字セットに属するけれども Unicode では同一視されている文字を、 同一視することができる、ということですよね。(たとえば、ISO-8859-1 と ISO-8859-2 は多くの共通の文字がありますし、Han Unification も その対象になりますね。) -c=raw というのは、どういうときに使うのでしょうか? つまり、端末の エンコーディングとは違うもの (CTEXT) が、端末に対して送られる、 ということですよね。これは正常に動作しないのではないですか? また、 ctext 以外のペースト (たとえば utf8 とか) を受け取ったときには、 どうなるのでしょうか。 (ISO2022 準拠というのは、たとえば Big5 や GBK や KOI8-R は ISO2022 準拠ではないけど、EUC-JP や TIS-620 は ISO2022 準拠だ、 ということですよね?) > また、prefer_utf8_selection=true しただけでは、受け取った CTEXT を ucs > に変換しないようになっています。 つまり、ペーストを受けた mlterm がペースト元に対して UTF8 な selection を要求したにもかかわらず、CTEXT が返ってきた場合、 ということですね。 --- 久保田智広 Tomohiro KUBOTA <ku...@de...> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ |
|
From: Araki K. <j00...@ip...> - 2001-12-16 09:49:46
|
荒木です:-)
commit log です。
* prefer_utf8_selection includes auto_detect_utf8_selection.
that is , true/false/auto can be used as value.
* conv_to_generic_iso2022 and pre_conv_xct_to_ucs options are obsoleted.
* xct_process_mode(-c/--xct) option is added.
this accepts ucs , raw or normal value.
* new "copy&paste" tab is added to mlconfig
* --ucshater => --ucs2other
--ucslover => --all2ucs
随分昔に作ったオプションが分かりにくくなりましたので少々整理しました。
まず、-c(xct_process_mode) オプションの意味を変えました。
-c=ucs: 受け取った ctext を ucs に変換します。(旧来の pre_conv_xct_to_ucs 相当)
-c=raw: 受け取った ctext をそのまま pty に流します。(旧来の conv_to_generic_iso2022 相当)
ただし、端末エンコーディングが、ISO2022 準拠な場合にしか有効になりません。
-c=normal: 受け取った ctext を 端末エンコーディングに変換します。(従来の通常動作)
これにともなって、-C オプションは廃止しています。
これらは、設定画面の copy&paste タブから動的に変更可能です。
また、prefer_utf8_selection=true しただけでは、受け取った CTEXT を ucs
に変換しないようになっています。
ucs に変換してから端末エンコーディングに変換したい場合は、明示的に、
xct_process_mode=ucs して下さい。
# selection で utf8 を優先するということと、受け取った CTEXT を ucs に変換
# する、ということは違う話ですので。
次に、
--ucslover => --all2ucs
--ucshater => --ucs2other
と、ロングオプションの名前を変えました。
これで、selection 周りの話がそこそこ整理されたと思いますが、何か問題があ
れば、ご指摘下さい。
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-16 05:06:21
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] selection options
From: Araki Ken <j00...@ip...>
Message-ID: <200...@pd...>
Date: 16 Dec 2001 13:43:08 +0900
> すみません、-c もセレクションとは関係ないです。
> 端末エンコーディングとして、ISO2022 に準拠する(しないものは、するように変換
> して)すべての文字集合を受け入れる、というオプションですので、事実上、端末エ
> ンコーディング指定と同じことです。
> ですので、-c オプションは廃止して、GENERIC_ISO2022 という端末エンコーディン
> グを追加することにしました。
これも嘘です。
-c は、セレクションおよびキーボード入力を、端末側エンコーディングに変換す
る場合に、ISO2022 のエスケースシーケンスを使って、情報の欠落なしに端末に
吐き出すためのオプションです。
これは、例えば、euc-jp 変換モジュールが、たとえ、ISO2022 に準拠した文字集
合であっても、変換の際に、euc-jp に合致しない文字集合を切り捨ててしまうた
め、それを避ける目的のものです。
あまり意味のあるオプションではないので、動的変更できるようにはなっていま
せん。
# たびたびすみません、いろんなことがごっちゃになってしまいまして...
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-16 04:47:46
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] selection options
From: Araki Ken <j00...@ip...>
Message-ID: <200...@pd...>
Date: 16 Dec 2001 12:55:45 +0900
> > それから、-c/-n/-u の動作がいまいちよくわかりません。
> > すべて、独立な意味を持つオプションなのでしょうか?
>
> -c は、確かに、セレクション関係のオプションですが、-n/-u は、セレクショ
> ンとは関係ないです。
すみません、-c もセレクションとは関係ないです。
端末エンコーディングとして、ISO2022 に準拠する(しないものは、するように変換
して)すべての文字集合を受け入れる、というオプションですので、事実上、端末エ
ンコーディング指定と同じことです。
ですので、-c オプションは廃止して、GENERIC_ISO2022 という端末エンコーディン
グを追加することにしました。
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-16 04:00:22
|
荒木です:-)
Subject: [Mlterm-dev-ja] selection options
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Sun, 16 Dec 2001 09:08:50 +0900
> セレクション関係のオプションが複雑になりつつあります。
>
> -C/--xct2ucs
> -U/--utf8sel
> -o/--autoutf8
> -c/--conv2022
> -n/--ucshater
> -u/--ucslover
>
> このなかで、-U と -o は統合できると思います。
> -U が、TRUE/FALSE/AUTO という指定をすればいいですから。
あ、そうですね。気づきませんでした。
> それから、-c/-n/-u の動作がいまいちよくわかりません。
> すべて、独立な意味を持つオプションなのでしょうか?
-c は、確かに、セレクション関係のオプションですが、-n/-u は、セレクショ
ンとは関係ないです。
# わたしも存在を忘れかけていたくらい昔に作ったオプションなので、現状から
# 考えると不適切な名前ですが。
まず、-c ですが、これは、受け取った CTEXT セレクションを、EUC-JP な端末
に流す時などに、EUC-JP に変換できない文字列を無視するのではなく、ISO2022
のシーケンスを利用して、情報欠落なしに端末に流すためのオプションです。
-n/-u は、端末側で、受け取ってからの動作を指定するものです。
端末側で、文字コードパーサをかけて取り出した文字を、UCS に変換する or UCS
以外の文字集合に変換する、を指定するものです。
> mlconfig ですが、-U/(-o)/-C だけなら、こんな感じでどうでしょうか。
>
> +--------+----------+----------+-----+
> |encoding|copy&paste|appearance|other|
> ++ - - - - - - - - - - - - +------+
> | |
> | +- Prefer UCS to XCT on receiving paste -+ | -U (-o) に相当
> | | <> Always | |
> | | <> When encoding is subset of Unicode | |
> | | <> Never | |
> | +----------------------------------------+ |
> | |
> | [ ] convert XCT to UCS on receiving paste | -C に相当
> | |
> +--------------------------------------------+
そうですね、こんな感じにしてみます。
では
--
kiken
j00...@ip...
|
|
From: Tomohiro K. <tk...@ri...> - 2001-12-16 00:00:02
|
久保田です。 セレクション関係のオプションが複雑になりつつあります。 -C/--xct2ucs -U/--utf8sel -o/--autoutf8 -c/--conv2022 -n/--ucshater -u/--ucslover このなかで、-U と -o は統合できると思います。 -U が、TRUE/FALSE/AUTO という指定をすればいいですから。 それから、-c/-n/-u の動作がいまいちよくわかりません。 すべて、独立な意味を持つオプションなのでしょうか? mlconfig ですが、-U/(-o)/-C だけなら、こんな感じでどうでしょうか。 +--------+----------+----------+-----+ |encoding|copy&paste|appearance|other| ++ - - - - - - - - - - - - +------+ | | | +- Prefer UCS to XCT on receiving paste -+ | -U (-o) に相当 | | <> Always | | | | <> When encoding is subset of Unicode | | | | <> Never | | | +----------------------------------------+ | | | | [ ] convert XCT to UCS on receiving paste | -C に相当 | | +--------------------------------------------+ それから、エンコーディングを変えた際に一時的に漢字などの ペーストができなくなる問題ですが、 - 時間経過もからんでいるかもしれません。 - 単に表示だけの問題ではなさそうです。というのは、 cat somefile とやると、きちんと漢字等が表示されるのに、 続いて漢字ペーストをやろうとすると、表示されないときが あるからです。 もしかしたら、荒木さんの「類似の問題」と同じ問題なのかも しれません。 --- 久保田智広 Tomohiro KUBOTA <ku...@de...> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ |
|
From: Araki K. <j00...@ip...> - 2001-12-15 14:26:24
|
荒木です:-)
commit logです。
* prefer_utf8_selection (-U/--utf8sel) , auto_detect_utf8_selection (-o/--autoutf8)
options are added.
* when window resized , font changed or encoding changed , screen may not be redrawn
or cursor position may be strange. fixed.
Subject: Re: [Mlterm-dev-ja] commit log , xpg4 and Big5
From: Araki Ken <j00...@ip...>
Message-ID: <200...@pd...>
Date: 15 Dec 2001 17:36:44 +0900
> すみません、selection を UTF8 で受け取る実装、ちゃんとできていませんでした。
> 後程、他のバグ修正と併せて commit します。
実装しました。
以下のオプションで、selection のやりとりを制御できます。
o prefer_utf8_selection (-U/--utf8sel)
端末エンコーディングに関係なく、selection をもっている相手に、UTF8 で
送るように要請します。
また、UTF8 な selection を要請された場合にも、端末エンコーディングが
UTF8 でなくても、mlterm 側で UTF8 への変換処理を行うようにします。
o pre_conv_xct_to_ucs (-C/--xct2ucs)
端末エンコーディングに関係なく、相手が CTEXT で送信してきた場合に、それを
一旦 UCS に変換してから、端末に流します。
o auto_detect_utf8_selection (-o/--autoutf8)
端末側が、UTF8 のサブセットなエンコーディングの場合にだけ、
prefer_utf8_selection_request と pre_conv_xct_to_ucs が自動的に on に
されます。
それから、
> - ペーストのテストをしていたら、ごくたまに、segfault することがありま
> す。感覚的には 20 回から 100 回に 1 回くらいの割合で。
これですが、以前はそれなりに発生してくれたのですが、どうにも再現できなく
なってしまいました。
ただ、これに関係しうる修正をした記憶はありませんので、多分直っていないと
思います。
> mlconfig でエンコーディングを変更した直後に、XIM での入力が
> できなくなることがあります。入力はできている (入力した内容が
> シェルに渡っている) のに、表示されていないのです。何文字か
> 入力していると直ったりします。ペーストについても同様で、
> 表示されていないけどシェルには渡っている、という症状が出ます。
> (ASCII 文字は入力もペーストも問題ないようです)。
> 調べてみると、cvs 2001-12-10 からこの不具合があるようです。
> 2001-12-08 までは不具合はありません。
これも、まだ、再現できていません。
ウィンドウリサイズ、フォントサイズ、エンコーディングを変更した場合に、フ
ォント表示がヘタってしまうバグがあったのは確かですので、ひょっとすると、
もう直ったのかも知れません。
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-15 09:11:17
|
荒木@大呆けです:-)
Subject: [Mlterm-dev-ja] commit log , xpg4 and Big5
From: Araki Ken <j00...@ip...>
Message-ID: <200...@pd...>
Date: 15 Dec 2001 17:02:21 +0900
> commit log です。
すみません、selection を UTF8 で受け取る実装、ちゃんとできていませんでした。
後程、他のバグ修正と併せて commit します。
# 少々、誤解していました。
# どう実装するかなぁ...
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-15 08:06:46
|
荒木です:-)
commit log です。
* ESC H (set tab) ESC [ 0 g (clear tab) ESC [ 3 g (clear all tabs) are supported.
* Big5HKSCS encoding/charset is supported.
* US ASCII font is not changed when encoding is changed to ISO8859 variant or UTF8. fixed.
* huge memory leaks when window is resized. fixed.
* input text is received in order of XmbLookupString => XLookupString => Xutf8LookupString.
* UTF8 selection is received as it is.
Big5 <=> UCS 変換テーブルとして、
ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5HKSCS.gz
を使い、同時に、BIG5HKSCS 文字集合&エンコーディングの対応コード(仮)を入れ
ました。
$ mlterm -E big5hkscs
PUA はどうしようか(=見なかったことにしたい)と思ったのですが、一部が PUA
に mapping されている C6A1-C8FE の ETEN 記号文字はともかく、HKSCS につい
ては、PUA の該当領域を使用したフォントが、実際に作られているようですので、
対応しないわけにはいかないか、と思い、素直に PUA を使うことにしました。
また、一応、BIG5HKSCS と、BIG5 は、同一コードポイント部分も、別文字集合
として扱っています。
HKSCS 部分だけというフォントもあるようですので、どう扱うのが適当なのか、
謎なんですけれど、とりあえずまだ (仮) ということで。
# フォントの XLFD 表記もよく分かっていない状況です。
それから、tab setting/resetting シーケンスにも対応しましたので、これで、
vttest の主要項目はすべてパスするようになったと思います。
Subject: Re: [Mlterm-dev-ja] commit log , xpg4 and Xutf8LookupString
From: hs...@mt... (Hironori Sakamoto)
Message-ID: <200...@mt...>
Date: Fri, 14 Dec 2001 23:55:42 +0900 (JST)
> やっぱりダメなのですが、簡単なテストプログラムでは lib*.so.* を
> 作る時には、-lxpg4 は必要でありませんでした。
> ただ、古い gtk の ports では -lxpg4 を追加したりしていますので、
> 何かあるのかもしれません。
ダメですか。
多分、相変わらず、わたしがどこかでヘタっているのだと思うんですが、当面原因は
わかりそうにもありませんので、kiklib/autoconf/configure.in にも、xpg4 チェッ
クを入れるようにしました _o_
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-15 07:00:38
|
荒木です:-)
Subject: [Mlterm-dev-ja] Big5, selection, Xutf8LookupString, mlconfig
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Sat, 15 Dec 2001 12:34:54 +0900
> - まず、Big5 なペーストの受け入れですが、--big5buggy で切り替えるの
> ではなく、いつでも何でも受け入れる、というのがいいと思います。
> mlterm 以外にも、COMPOUND_TEXT を独自に生成しているソフトウェアが
> あります (たとえば emacs)。そういうソフトウェアが生成する
> COMPOUND_TEXT に対応するには、そうするのがいいと思います。
そう致しました。
> - ペーストのテストをしていたら、ごくたまに、segfault することがありま
> す。感覚的には 20 回から 100 回に 1 回くらいの割合で。
手元でも、core dump まではしませんが、それくらいの頻度で、'\0'文字が挿入
されてしまうケースを確認しております。
後程、調査致します。
> - ペーストのとき、COMPOUND_TEXT を Unicode にいったん変換する (そして
> さらに現在のエンコーディングに変換する) というオプションがあります
> が、
> それがオフのときでも、Unicode でやってきたセレクションを現在の
> エンコーディングに変換する、というのは、やったほうがいいと思います。
その通りですね。気づいていませんでした。
そのように修正致しました。
> あるいは、エンコーディングごとに Unicode のサブセットになっているか
> どうか、という情報を持たせ、もしサブセットになっているなら Unicode
> 変換を使う、そうでなければ使わない、という切り分けでもいいと思い
> ます。
...
> まとめると、
> mlterm encoding が Unicode のサブセットのとき
> selection(XCTorUCS) -> Unicode -> (mlterm encoding)
> mlterm encoding が Unicode のサブセットでないとき
> selection(XCTorUCS) -> (mlterm encoding)
> というぐあいにするモードがあればと思います。
そうですね。
まだ実装しておりませんが、auto_pre_conv_xct_to_ucs オプションを追加して、
これが true にされている場合は、端末エンコーディングが UCS のサブセット
かどうかで、XCT => UCS 変換を行うかどうかを自動判定してくれる、逆に、も
し、auto_pre_conv_xct_to_ucs が false の場合には、 mlconfig で変更しない
限り、状態は変わらない、という感じでどうでしょうか?
Subject: [Mlterm-dev-ja] encoding change and input
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Sat, 15 Dec 2001 13:53:06 +0900
> mlconfig でエンコーディングを変更した直後に、XIM での入力が
> できなくなることがあります。入力はできている (入力した内容が
> シェルに渡っている) のに、表示されていないのです。何文字か
> 入力していると直ったりします。ペーストについても同様で、
> 表示されていないけどシェルには渡っている、という症状が出ます。
> (ASCII 文字は入力もペーストも問題ないようです)。
>
> 調べてみると、cvs 2001-12-10 からこの不具合があるようです。
> 2001-12-08 までは不具合はありません。
これは、まだ再現できていません。
# 近い問題として、USASCII相当のフォントが、エンコーディング変更後、変更
# されるべきケースで、一定時間変更されない問題があることを確認しておりま
# す。
それから、結構、手元での修正点が溜っておりますので、先に commit 作業
を行います。
ご指摘いただいた copy and paste の問題と、auto_pre_conv_xct_to_ucs 、
XIM 入力の問題は、それから一休みしたあとということで。
では
--
kiken
j00...@ip...
|
792 messages has been excluded from this view by a project administrator.
