mlterm-dev-ja — mlterm mailing list(Japanese)

[Mlterm-dev-ja] commit log [20020124-2] (was: Re: proposal of aafont extension)

[Araki K. <j00...@ip...>]

	荒木です:-)

        commit log です。

* NEC Gaiji couldn't be converted to UCS. fixed.
* Japanese gaiji characters are converted to UCS.
* if -w [fontsize] is too small or too large , mlterm may dump core. fixed.
* foreground color couldn't be change run time. fixed.

        lynx を SJIS で使っていて、外字(Win)が流れてくる可能性があることに気付
        きまして、どうしようかな、と思ったのですが、結局全部 Unicode に置換する
        ようにしました。
        現在のところ、UCS 変換に対応しているのは、NEC 特殊文字だけです。

        CVS current のテストは、引き続きよろしくお願い致します _o_

        # 普段使わないようなオプションの組み合わせでテストしていただけると
        # 助かります。

	Subject: Re: [Mlterm-dev-ja] proposal of aafont extension
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Wed, 23 Jan 2002 03:14:54 +0900

>> 最初は最も横幅の小さい文字（か、基本的な文字（空白など））を
>> 一行の文字数分（例えば、80個分）の、横幅の小さいウィンドウで
>> mltermを開始し、一行に80文字が収まりきらなくなった時は、
>> 横スクロールバーではなく、mltermのウィンドウ自体を横に
>> 少し大きくする事で、解決するというのはどうでしょうか。
>         ただ、右端まで文字が埋まると、ウィンドウが勝手にリサイズするというのは、
>         個人的には、なんだか気持ちわるいので、それなら初めから、'W' によるコラム
>         幅チェックを行なわず、その結果、はみだして見えなくなる文字があっても気
>         にしない、というのでもいいかな、という気もします。

        font/vfont のフォーマットも、aafont/vaafont 同様、以下のように拡張してみました。

        [XLFD](:[Percentage])

        これで、そのフォントのグリフを表示するに、フォントサイズの何パーセント分の幅を
        とるかを指定します。

        猫家さんの提案のように、画面からはみだした場合にリサイズすることはありませんが、
        フォントごとに、細かく幅指定できるので、比較的柔軟に対応できるのではないか、と
        思います。

        # 固定ピッチフォントを使う場合も、文字間隔を少し広げたいときなどに使えます。

        例えば、vfont に、

ISO8859_1 = 12,-mona-*-medium-r-*-12-*-iso8859-1:100;
ISO8859_1_BOLD = 12,-mona-*-bold-r-*-12-*-iso8859-1;
JISX0201_KATA = 12,-mona-*-medium-r-*-12-*-jisx0201.1976-0;
JISX0201_KATA_BOLD = 12,-mona-*-bold-r-*-12-*-jisx0201.1976-0;
JISX0201_ROMAN = 12,-mona-*-medium-r-*-12-*-jisx0201.1976-0;
JISX0201_ROMAN_BOLD = 12,-mona-*-bold-r-*-12-*-jisx0201.1976-0;
JISX0208_1983 = 12,-mona-*-medium-r-*-12-*-jisx0208.1990-0;
JISX0208_1983_BOLD = 12,-mona-*-bold-r-*-12-*-jisx0208.1990-0;

        こんな風に指定(ISO8859_1 の最後の ":100" を忘れず)した場合のスクリーンショット
        を以下に置いておきます。

        http://www.geocities.co.jp/SiliconValley-Cupertino/6461/mona.png

	では
--
kiken
j00...@ip...

[Mlterm-dev-ja] commit log [2002/01/24]

[Araki K. <j00...@ip...>]

	荒木です:-)

* cursor may disappear when selected region color is restored. fixed.
* w3mmlconfig(2002/01/15 version) is added(tool/w3mmlconfig)
* contrib/scrollbar/sample is moved to scrollbar/sample

        mlterm -v は、2.2.0 と吐くようになっております。

        HP-UX 10.20 でもコンパイル&動作確認致しました。

        mlterm.spec も、あとは、最終的な日付を入れればよいだけです。現時点で、確認
        していただけると幸いです _o_ > nisizawa さん
        
        また、坂本さんの w3mmlconfig の 2002/01/15 日版を、tool/w3mmlconfig 以下に、
        そのまま import させていただきました _o_

        # 著作権は行使されないとのことですので、contrib/ 以下には置いておりません。

        doc/en/README.w3mmlconfig

        に簡単なドキュメントを置いております。

        w3mmlconfig は、w3m がインストールされているかどうかに関係なく、
        ./configure ; make では make されません。
        必要に応じて、tool/w3mmlconfig にて、make ; make install してください。

        それから、ディレクトリ単位で修正が入るついでに、前からやりたかったんです
        が、 contrib/scrollbar/sample を scrollbar/sample 以下に移動しまし、LICENSEの
        (except for files in contrib/scrollbar/sample directory)
        を消しました。

        # でないと、わたしが新しく scrollbar を実装する場合、その度に LICENSE の
        # except 以下を追加しなくてはいけなくなりますし、また、この辺については、
        # 当初の目論見とは、ちょっと状況が変わってしまったこともありますので。

        あと、南さんの mlconf_curses.pl ですが、どうしましょうか?
        一応手元のソースツリーには、contrib/tool/mlconf_curses/mlconf_curses.pl
        として置いているのですが。

        # C で書きなおされる、という話もしておられましたが....

        とりあえず、現状でもそれなりに動いていますので、DEBUG 出力だけなくして、
        ほぼそのまま、contrib/tool/mlconf_curses 以下に置いてしまってもよいよう
        に思いますが、どうでしょうか?

        # ついでに、ドキュメント(含む著作権表示)と、Makefile を付けてもらえれば
        # ....:)

        ところで、Encoding の入力で、0-9 も使用しますので、添付のパッチのような
        感じにしていただけるとありがたいです。

        # すみません、手元では、随分前に修正していたんですが、報告忘れておりま
        # した _o_

	では
--
kiken
j00...@ip...

--- mlconf_curses.020117-0.pl	Thu Jan 17 14:30:00 2002
+++ mlconf_curses.pl	Sat Jan 19 22:28:27 2002
@@ -918,11 +918,6 @@
 	    return $text;
 	}
 	$input = display_getch(0, $window_dlg);
-	if ( $input =~ /^[A-Za-z]/) {
-	    substr( $text, $pos , 0) = $input ;
-	    $pos++;
-	    next;
-	}
 	if ( $input eq "\n") {
 	    $window_dlg->delwin;
 	    return ( $input, $text);
@@ -941,7 +936,11 @@
 	    $pos = 0;
 	} elsif ( $input eq KEY_END) {
 	    $pos = length( $text) ;
-	}
+	} elsif ( $input =~ /^[A-Za-z0-9]/) {
+	    substr( $text, $pos , 0) = $input ;
+	    $pos++;
+	    next;
+        }
     }
 }
 

[Mlterm-dev-ja] commit log [2002/01/23] and plan of 2.2.0 release (was: Re: proposal of aafont extension)

[Araki K. <j00...@ip...>]

	荒木です:-)

        commit log です。
        
* ISCII rendering is tuned up.
* etc/font and etc/vfont format is changed. (default font can be specified.)

	Subject: Re: [Mlterm-dev-ja] proposal of aafont extension
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Wed, 23 Jan 2002 03:14:54 +0900

>         が、あまりにアドホックではありますし、とはいえ、~/.mlterm/font に記述され
>         ているフォントになるべく似たフォントを選ぶといっても、複数指定されていたり、
>         fonts.alias の省略記法で指定されていた場合に、面倒なことになりますので、
>         ~/.mlterm/font ~/.mlterm/vfont でも、デフォルトフォントを指定できるように
>         したほうがいいかな、と思っています。
>
>         ISO8859_1 = -*-medium-r-*--%d-*-iso8859-1;10,a10;
>
>         こんな感じで。
>
>         この場合ですと、フォントサイズが 10 のときは、a10 フォントが、それ以外のとき
>         は、-*-medium-r-*--%d-*-iso8859-1 (%dにはフォントサイズが入る)が使われます。
>
>         # aafont , vaafont の場合と同じようなフォーマットです。
>
>         一応、旧来のフォーマットと互換性を保った形で実装することは可能ですので、その
>         点での心配はないです。
>
>         どうでしょうか?

        実装しました。
        README.ja の説明を添付します。
        旧来のフォーマットも受けつけますので、デフォルトフォントを指定する必要のない方
        は、現状のまま修正の必要はありません。

        例えば、
        
JISX0208_1983 = -kochi----normal--%d-0-0-0-c-0-jisx0208.1983;

        このように記述しておくことで、font_size_range の範囲内のすべてのフォントサ
        イズに対して、東風フォントを使用することができます。

        # 但し、デフォルトフォント指定は、少々メモリを食いますので(これは、aafont
        # でも同様)、制約の厳しい環境では、できるだけ避けたほうがよいかもしれませ
        # ん。

        それから、Jyotirmoy Saikia さん、あいかわらずお忙がしいようですので、
        ISCII 対応はとりあえずおいておくとして、2.2.0 のリリース準備に入ろうと
        思います。

        現在の CVS 版につきまして、問題点などの洗い出しなどしていただけるとありが
        たいです _o_

	では
--
kiken
j00...@ip...

--- README.ja        
        フォーマットは、以下のようになります。
        [default font name];[font size],[font name];[font size],[font name];...

        [default font name]で、デフォルトのフォントを指定し、サイズごとにデフォル
        トと異なるフォントを指定できます。
        
        [default font name]に %d を含めておくと、そこにフォントサイズが入ります。

        font name は、font/vfont(通常のXフォント)と、aafont/vaafont(Xft用フォント)
        で異なります。
        o font/vfont
          XLFD、もしくは、fonts.aliasで定義している省略記法。
          
        o aafont/vaafont
          [font family]-[font encoding](:[percentage])

          percentage は、フォントサイズに対して何パーセントの幅のフォントを表示する
          かを指定します。
          例えば、フォントサイズが12の場合に、percentage として 100 を指定すると、
          半角文字なら幅 6 , 全角文字なら幅 12 になります。
          percentage 指定がない場合、'W' の文字幅が収まるだけの幅が取られます。

          percentage は、微妙に大きさの異なるフォントを組み合わせる場合の微調整や、
          'W' が大きすぎるプロポーショナルフォントを使用する場合などに使います。
          とくに、Dynalab フォントのように、'W' が全角幅で収められているフォントを
          使用する場合は、必ず適切な指定を行なってください。

          e.g.)
          JISX0208_1983 = Hoge-iso10646-1:100;        

Re: [Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCPURKfTh+ST08KEJQMX4bKEI=?= =?ISO-2022-JP?B?GyRCJEs4fiQxJD8lYSViGyhC?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] 縦方向表示対応に向けたメモ
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Tue, 22 Jan 2002 23:25:37 +0900

>> # むしろ、本来の日本語の縦書きは倒さないで書くと思います。
>> # 倒す場合は、そこで言語が切り替わっていると思うべきなのかな。
>         あくまで、横表示しか対応していないアプリケーションをつかって、縦表示(もどき)
>         ができればよい、という話ですので、コンソールアプリケーションからみたとき(=横
>         表示)での全角、半角という semantics を変えるわけにはいきません。
>         したがって、半角文字は、どうしても横倒しにしてやる必要があります。
>         # でないと、一行が画面内におさまらなくなってしまいます。

        すみません、おもいっきり勘違いしていました _o_

        全角文字をあつかう場合は、半角を横に倒さないといけないと思いこんでましたが、
        別にそんなことはなくって、ただ、ウィンドウを縦方向に長めにとればよいだけで
        すね。
        # かなり縦長になってしまいますが。

        倒さないですむなら、それにこしたことはありませんから、半角文字も倒さずに表
        示する方向で考えなおします。

        # 縦方向の一行の横幅を、全角幅分とるか、半角幅分にするかのオプションと、右
        # から左に流れるか、左から右に流れるかのオプションが必要か....

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] proposal of aafont extension

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] proposal of aafont extension
	From: nekoie <ne...@ti...>
	Message-ID: <20020122164534.GA22777%ne...@ti...>
	Date: Wed, 23 Jan 2002 01:45:34 +0900

> ウィンドウの右側が空いてしまう問題の解決方法を考えてみたのですが、
> 最初は最も横幅の小さい文字（か、基本的な文字（空白など））を
> 一行の文字数分（例えば、80個分）の、横幅の小さいウィンドウで
> mltermを開始し、一行に80文字が収まりきらなくなった時は、
> 横スクロールバーではなく、mltermのウィンドウ自体を横に
> 少し大きくする事で、解決するというのはどうでしょうか。
> デメリットとして、
> ・長い間使っていると、結局以前と変わらなくなる
> ・横スクロール実装時と同じ問題をかかえている
> ・ウィンドウ自体をリサイズするので、少し画面描画の負荷が増えるかも
> ・ディスプレイの右端の方でmltermを開いた時に、いちいちウィンドウを
> 　移動させる手間がかかってイライラするかもしれない
> という点があるので、自分で提案しておいて何ですが、
> わざわざそこまでして実装する価値があるのか、
> かなり疑問でもあります‥‥ (^^;

        いいアイデアだと思います。
        確かに、経験的に、右端まですべて文字が埋まるケースのほうがまれですから、
        いざそうなるときまで、右の空白が生じるのを遅延させるだけで、期待に近い
        動作になりそうですね。

        ただ、右端まで文字が埋まると、ウィンドウが勝手にリサイズするというのは、
        個人的には、なんだか気持ちわるいので、それなら初めから、'W' によるコラム
        幅チェックを行なわず、その結果、はみだして見えなくなる文字があっても気
        にしない、というのでもいいかな、という気もします。

        実際、そんなことをおっしゃられている方もいらっしゃいますし。

---- http://www.tenet.res.in/Donlab/Indlinux/(iitm-term の開発元)から
During startup, the virtual terminal has a width
to accommodate 80 English characters, which may
not be sufficient to accommodate that many
Indian characters.
But the window can be easily resized using mouse.

        最後の一文読んだときには、まぁそうなんだけどね、と思いましたが。

        ただ、どの解も一長一短といった感じなので、とりあえず、当面は現状のままで
        いこうかと思います _o_

>>         -A の場合、XIM には ~/.mlterm/font のフォントを、-A -V の場合、~/.mlterm/vfont
>>         のフォントを使われるようにしました。
> 早速試してみました。上手く動作しています。
> ただ、mltermを起動してから動的にフォントサイズを変更した際に、
> ~/.mlterm/font に無いサイズへと変更した時は、
> やはりmltermにおまかせになってしまいますね。
> せっかくなので、mltermが自分でフォントを選ぶ時には、できれば、
> ~/.mlterm/font に記述されているフォントになるべく似たフォント
> （特に、wghtとslantを）を選ぶようにするか、せめてデフォルトで
> *-medium-r-* なフォントを選んで欲しいです。
> （現在の状態だと、高い確率で、boldでイタリックなフォントが
> 選択されてしまう気がするので‥‥）

        *-medium-r-* なフォントを選ぶようにしました。
        パッチを添付します。

        が、あまりにアドホックではありますし、とはいえ、~/.mlterm/font に記述され
        ているフォントになるべく似たフォントを選ぶといっても、複数指定されていたり、
        fonts.alias の省略記法で指定されていた場合に、面倒なことになりますので、
        ~/.mlterm/font ~/.mlterm/vfont でも、デフォルトフォントを指定できるように
        したほうがいいかな、と思っています。

        ISO8859_1 = -*-medium-r-*--%d-*-iso8859-1;10,a10;

        こんな感じで。

        この場合ですと、フォントサイズが 10 のときは、a10 フォントが、それ以外のとき
        は、-*-medium-r-*--%d-*-iso8859-1 (%dにはフォントサイズが入る)が使われます。

        # aafont , vaafont の場合と同じようなフォーマットです。

        一応、旧来のフォーマットと互換性を保った形で実装することは可能ですので、その
        点での心配はないです。

        どうでしょうか?
                
	では
--
kiken
j00...@ip...

Index: src/ml_font_manager.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_font_manager.c,v
retrieving revision 1.111
diff -u -r1.111 ml_font_manager.c
--- src/ml_font_manager.c	2002/01/21 14:21:15	1.111
+++ src/ml_font_manager.c	2002/01/22 17:56:53
@@ -845,7 +845,7 @@
 		return  NULL ;
 	}
 
-	sprintf( default_font_name , "-*-*-*-*-*--%d-*-*-*-*-*" , font_man->font_size) ;
+	sprintf( default_font_name , "-*-*-medium-r-*--%d-*-*-*-*-*" , font_man->font_size) ;
 
 	list_str_len = strlen( default_font_name) ;
 

Re: [Mlterm-dev-ja] proposal of aafont extension

[nekoie <ne...@ti...>]

猫家です。


> >> どう実装しても、一行の文字数が固定な限り右側が空いてしまうと思うので、
> >> 可能でしたら、先に挙げた、一行の最大文字数を不定にするやり方を
> >> 実現して欲しいです。
> 
>         朝木さんも指摘しておられますが、一行の文字数を不定にするということは、
>         VT100 端末の仕様上不可能ですので、そのようにするわけにはいかないのです _o_
(snip)
>         その辺の問題を解決しつつ、横スクロール(または、可変長コラム幅の場合に、ウ
>         ィンドウの右があいてしまう問題を解決する別の手法)を実装する方法があれば、
>         提案していただければ、もちろん、実装いたします。
> 
>         # わたしも、なんかやだなぁ、とは思ってますので ^_^;

そうなのですね。納得しました。
説明して下さり、どうもありがとうございます。

ウィンドウの右側が空いてしまう問題の解決方法を考えてみたのですが、
最初は最も横幅の小さい文字（か、基本的な文字（空白など））を
一行の文字数分（例えば、80個分）の、横幅の小さいウィンドウで
mltermを開始し、一行に80文字が収まりきらなくなった時は、
横スクロールバーではなく、mltermのウィンドウ自体を横に
少し大きくする事で、解決するというのはどうでしょうか。
デメリットとして、
・長い間使っていると、結局以前と変わらなくなる
・横スクロール実装時と同じ問題をかかえている
・ウィンドウ自体をリサイズするので、少し画面描画の負荷が増えるかも
・ディスプレイの右端の方でmltermを開いた時に、いちいちウィンドウを
　移動させる手間がかかってイライラするかもしれない
という点があるので、自分で提案しておいて何ですが、
わざわざそこまでして実装する価値があるのか、
かなり疑問でもあります‥‥ (^^;
とりあえず、このぐらいしか私には思い付きませんでした。


> > そういえば、猫家さんで思い出したんですが、
> > 猫家さんのmlterm導入手法のページで記述されている、
> > XIMのフォントの問題ですが、現状でもあのままでしょうか。
> > # ソースをざっと見ただけでは良く分からなかった…。
> >
> > ~/.mlterm/fontsの設定を使うなどの手はできませんか?
> > FontPathをいじるのは他への影響が大きすぎますし。
> 
>         あー、可能です。
> 
>         # なんで今まで思いつかなかったんでしょ^_^;
> 
>         -A の場合、XIM には ~/.mlterm/font のフォントを、-A -V の場合、~/.mlterm/vfont
>         のフォントを使われるようにしました。
> 
>         添付のパッチをお試し下さい。

早速試してみました。上手く動作しています。
ただ、mltermを起動してから動的にフォントサイズを変更した際に、
~/.mlterm/font に無いサイズへと変更した時は、
やはりmltermにおまかせになってしまいますね。
せっかくなので、mltermが自分でフォントを選ぶ時には、できれば、
~/.mlterm/font に記述されているフォントになるべく似たフォント
（特に、wghtとslantを）を選ぶようにするか、せめてデフォルトで
*-medium-r-* なフォントを選んで欲しいです。
（現在の状態だと、高い確率で、boldでイタリックなフォントが
選択されてしまう気がするので‥‥）


後で自分のところの文書を修正しておきますね。

-------------------------------
From: nekoie <ne...@ti...>

commit log (was: Re: [Mlterm-dev-ja] proposal of aafont extension)

[Araki K. <j00...@ip...>]

	荒木です:-)

        commit log です。

* -c/--cp932/use_cp932_ucs_for_xft option is added.

	Subject: Re: [Mlterm-dev-ja] proposal of aafont extension
	From: nekoie <ne...@ti...>
	Message-ID: <20020121120416.GA398%ne...@ti...>
	Date: Mon, 21 Jan 2002 21:04:16 +0900

> # （ただ、東風フォントと同じように、「〜」記号は表示されてませんが。
> # 　XFree86を4.2.0にすれば、直っているのでしょうか‥‥？）

        mlterm 側で、アドホックな対処を行ないました。

        -c/--cp932 オプションまたは、~/.mlterm/main に、use_cp932_ucs_for_xft = true
        を設定してください。
        これで、東風フォントや Dynalab フォントで、「〜」などが表示されるよう
        になると思います。

        フォントごとに設定できるようにしようかとも思いましたが、あくまでアドホックな
        対処にすぎない(=将来的には、フォント側で、グリフを入れてくれるはず)と思ってま
        すので、global にオプション指定するようにしました。

        ご確認ください。

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCPURKfTh+ST08KEJQMX4bKEI=?= =?ISO-2022-JP?B?GyRCJEs4fiQxJD8lYSViGyhC?=

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] 縦方向表示対応に向けたメモ
	From: Hironori Sakamoto <hs...@mt...>
	Message-ID: <200...@ud...>
	Date: Tue, 22 Jan 2002 21:57:24 +0900 (JST)

> # ちょっと否定的な反応なんですが、面白そうと思っているので御容赦。

        いえいえ、むしろ、反応していただけるだけでありがたい限りです_o_

        # わたしも、実装すべきか(実用的な範囲内に収まる形で可能か)どうか、
        # という段階で、まだ悩んでますし、Bidi や ISCII 対応の際と違って、
        # 参考にできる実装もないので、とりあえず、意見を伺ってみたい、とい
        # うところでして。
        
> どういう用途を考えておられますか？
> 文書閲覧ならアプリに任せた方が良さそうですけれど。

        <200...@pd...>

        にも書きましたとおり、横表示しか対応していないアプリケーション(例えば
        less など)を使って、縦表示ができれば、小説なんかの閲覧程度なら、いちい
        ち縦対応の専用ソフトを使わなくていいかも、と思った次第です。
        
        # 実用性という点では、説得力ないですね ^_^;
        # 結局のところ、どこまでできるかな、という単なる遊び心が大きいんですが。

> 日本語でも英語の単語は倒すことが多いですが『PC業界』なんかだと
>
>   P
>   C
>   業
>   界
>
> なんて書きますよ。ASCII なら全角 variant を使えますが、ギリシャ文字
> とかは両方ありそうです。例えば『Σプロジェクト』は倒さないけど、
> Σを含むギリシャ語の名前は倒してもいい。
>
> # むしろ、本来の日本語の縦書きは倒さないで書くと思います。
> # 倒す場合は、そこで言語が切り替わっていると思うべきなのかな。

        あくまで、横表示しか対応していないアプリケーションをつかって、縦表示(もどき)
        ができればよい、という話ですので、コンソールアプリケーションからみたとき(=横
        表示)での全角、半角という semantics を変えるわけにはいきません。
        したがって、半角文字は、どうしても横倒しにしてやる必要があります。
        # でないと、一行が画面内におさまらなくなってしまいます。

        この辺は、mlterm や xterm の BIDI / ISCII 対応などが、所詮は対応してないものを
        無理矢理対応させているにすぎないので、それ以上の品質が必要なら、コンソールアプ
        リケーション側での対応が必須なのと同じです。

> (たぶん) X11R6.3 から
>   -*-mincho-medium-r-normal--[f1 f2 f3 f4]-*-100-100-c-*-jisx0208.1983-0
>     f1 =  size * cos(angle)
>     f2 =  size * sin(angle)
>     f3 = -size * sin(angle)
>     f4 =  size * cos(angle)
> という様な指定ができて回転してくれるはずです。
> # Topaz (http://hp.vector.co.jp/authors/VA007663/topaz/index.html)
> # というグラフソフトがそんな感じでやっていた。

        やってみました。
        確かに回転してくれますね ^_^

        とはいえ、使ってみて気づいた点がいくつか。

        1. 回転したとしても、XFontStruct の返す情報は、回転しない状態のものを返してくる。
        2. 当たり前といえば当たり前なんですが、回転すると、

          -+--+---- 行の上端
           |  |
          -+--+---- 行の下端
            ↑
           こういう位置にあるグリフが、

          --------- 行の上端
                    ←ここが背景色で塗り潰された上で、
          ----+---+ 行の下端
              |   | ←ここにグリフが表示されるんですよね。
              +---+
              
        結局、いろいろ面倒な処理が必要になるようですね。

> JISX0208 でも回転が必要なものは 『「」()【】〜…』等あります。
> 『。、，“”ゃッ』等は回転でなく位置の移動ですね。
> さらに、(明朝系の)『ー』はグリフが変わります。
> やっぱり、縦表示用のフォントが必要では。

        結局、いちいち回転処理するのはやめて、素直に縦用フォントを使うのが正解っ
        ぽいですね。

        # しかし、日本語はいいとして、半角フォントで、横倒しになっているフォント
        # ってあるかしら?

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] $B=DJ}8~I=<(BP1~$K8~$1$?%a%b(B

[Hironori S. <hs...@mt...>]

$B:dK\$G$9!#(B

# $B$A$g$C$HH]DjE*$JH?1~$J$s$G$9$,!"LLGr$=$&$H;W$C$F$$$k$N$G8fMF<O!#(B

> $B9SLZ$G$9(B:-)
> $B@hF|Mh!"=DI=<(BP1~$G$-$k$+$J!"$H$+9M$($F$^$9!#(B

$B$I$&$$$&MQES$r9M$($F$*$i$l$^$9$+!)(B
$BJ8=q1\Mw$J$i%"%W%j$KG$$;$?J}$,NI$5$=$&$G$9$1$l$I!#(B

> 1. $B=DI=<($N:]!"H>3QJ8;z$O$I$&$9$k$+(B?$B!#(B
> 1. $B$G!"$b$7!"H>3Q$@$1$I2#$K$OE]$5$J$$!"$H$$$&8@8l$,$"$C$?>l9g(B(*)$B!"(B

$BF|K\8l$G$b1Q8l$NC18l$OE]$9$3$H$,B?$$$G$9$,!X(BPC$B6H3&!Y$J$s$+$@$H(B

  P
  C
  $B6H(B
  $B3&(B

$B$J$s$F=q$-$^$9$h!#(BASCII $B$J$iA43Q(B variant $B$r;H$($^$9$,!"%.%j%7%cJ8;z(B
$B$H$+$ON>J}$"$j$=$&$G$9!#Nc$($P!X&2%W%m%8%'%/%H!Y$OE]$5$J$$$1$I!"(B
$B&2$r4^$`%.%j%7%c8l$NL>A0$OE]$7$F$b$$$$!#(B

# $B$`$7$m!"K\Mh$NF|K\8l$N=D=q$-$OE]$5$J$$$G=q$/$H;W$$$^$9!#(B
# $BE]$9>l9g$O!"$=$3$G8@8l$,@Z$jBX$o$C$F$$$k$H;W$&$Y$-$J$N$+$J!#(B

> 2. 1. $B$G!"%U%)%s%H$N2sE>=hM}$,I,MW$H$J$C$?$H$7$F$b!"(BXlib $B$N4X?t(B
> $B$r;H$C$F!"D>@\!"%U%)%s%H$r2sE>$5$;$?$j$9$k$3$H$O$G$-$^$;$s(B($B$h(B

($B$?$V$s(B) X11R6.3 $B$+$i(B
  -*-mincho-medium-r-normal--[f1 f2 f3 f4]-*-100-100-c-*-jisx0208.1983-0
    f1 =  size * cos(angle)
    f2 =  size * sin(angle)
    f3 = -size * sin(angle)
    f4 =  size * cos(angle)
$B$H$$$&MM$J;XDj$,$G$-$F2sE>$7$F$/$l$k$O$:$G$9!#(B
# Topaz (http://hp.vector.co.jp/authors/VA007663/topaz/index.html)
# $B$H$$$&%0%i%U%=%U%H$,$=$s$J46$8$G$d$C$F$$$?!#(B

> b. $B=DI=<(MQ$N%U%)%s%H$rJLESMQ0U$9$k(B

JISX0208 $B$G$b2sE>$,I,MW$J$b$N$O(B $B!X!V!W(B()$B!Z![!A!D!YEy$"$j$^$9!#(B
$B!X!#!"!$!H!I$c%C!YEy$O2sE>$G$J$/0LCV$N0\F0$G$9$M!#(B
$B$5$i$K!"(B($BL@D+7O$N(B)$B!X!<!Y$O%0%j%U$,JQ$o$j$^$9!#(B
$B$d$C$Q$j!"=DI=<(MQ$N%U%)%s%H$,I,MW$G$O!#(B
----------------------------------- 
$B:dK\(B $B9@B'(B <hs...@mt...> 
 http://www2u.biglobe.ne.jp/~hsaka/

Re: [Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCPURKfTh+ST08KEJQMX4bKEI=?= =?ISO-2022-JP?B?GyRCJEs4fiQxJD8lYSViGyhC?=

[Araki K. <j00...@ip...>]

	荒木です:-)

        さきほど commit した changelog です。
        ほぼ、先日投げましたパッチ相当です。
        
* aafont file format is changed. ([Font Family]-[Font Encoding](:[Percentage]))
* font or vfont is used when XIM fontset is created under AA mode.

	Subject: Re: [Mlterm-dev-ja] 縦方向表示対応に向けたメモ
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Tue, 22 Jan 2002 20:16:36 +0900

> なんか、すごい話ですね。縦横混在ですか? それとも、縦モードは縦のみ
> ですか?

        今考えている枠組では、縦のみです。
        
        # というか、縦横混在ってどういう表示になるんでしょうね?

        今のところ考えている用途としては、横表示しか対応していないエディタ
        やビューワを使った場合でも、*それなりに*縦方向に表示してくれる、と
        いうところです。

        レンダリングまでは(パフォーマンスに少々難がありそうですが)メドが立っ
        てますが、フォントの処理でニッチもサッチもいかなくなって困っています:(

        縦方向の文字列描画までは望みませんが、せめて、XFontStruct に対する回
        転処理が、Xlib でできればよいのですが。

        現在うまい代替案を調査中ですが、なにかこれというアイデアがありました
        らお教えください。

> モンゴル文字は縦向きにしか表記できない、という話を聞いたことがあります
> が、モンゴルではソ連の崩壊のあと、それまでのキリル文字の使用をやめて
> モンゴル文字の使用を復活させようという動きがあったそうですが、それを
> 諦めた、という話をどこかで聞いたことがあります。

        縦向きで、しかも左から右みたいですね。
        うーん....

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCPURKfTh+ST08KEJQMX4bKEI=?= =?ISO-2022-JP?B?GyRCJEs4fiQxJD8lYSViGyhC?=

[Tomohiro K. <tk...@ri...>]

久保田です。

At Tue, 22 Jan 2002 19:09:30 +0900,
Araki Ken wrote:

>         # まだ、先の話ですが、一応今の段階から、ネタふりはしておいたほ
>         # うがよいように思いましたので。
>         
>         先日来、縦表示対応できるかな、とか考えてます。

なんか、すごい話ですね。縦横混在ですか? それとも、縦モードは縦のみ
ですか?

混在はどうすればいいか、なんて考えだすと、頭が豆腐みたいになって
しまいそうですが。いや、どちらにせよ、縦横モード切り替えのコントロール
コードの国際規格でもできない限りだめですし、国際規格にするならそれこそ
オメガみたいに全ての組み合わせを考える必要があるでしょうね。

モンゴル文字は縦向きにしか表記できない、という話を聞いたことがあります
が、モンゴルではソ連の崩壊のあと、それまでのキリル文字の使用をやめて
モンゴル文字の使用を復活させようという動きがあったそうですが、それを
諦めた、という話をどこかで聞いたことがあります。

色モノとしては面白そうですが。

---
久保田智広 Tomohiro KUBOTA <ku...@de...>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

[Mlterm-dev-ja] =?ISO-2022-JP?B?GyRCPURKfTh+ST08KEJQMX4kSzh+JDEkPyVhJWIbKEI=?=

[Araki K. <j00...@ip...>]

	荒木です:-)

        # まだ、先の話ですが、一応今の段階から、ネタふりはしておいたほ
        # うがよいように思いましたので。
        
        先日来、縦表示対応できるかな、とか考えてます。
        
        # 一応、なるべく、日本語や全角文字に依存せず、汎用的に対処したい
        # と思ってます。
        
        縦方向表示のレンダリングまでは、だいたい設計のメドは立っているの
        ですが、最後のスクリーン描画の部分でゆきづまっております。

        1. 縦表示の際、半角文字はどうするか?
           横に倒すか、倒すとしても、右向きに倒すか左向きに倒すかはど
           う判断するのか?

           # 多分、右から左に流れる縦表示の場合には、右向きに倒して、
           # 左から右に流れる縦表示の場合には、左向きに倒すというので
           # いいかな、と思ってます。

        2. 1. で、フォントの回転処理が必要となったとしても、Xlib の関数
           を使って、直接、フォントを回転させたりすることはできません(よ
           ね?)

           その対処策ですが、

           a. VFlib や xvertext を使って、ローカルでフォントのビットマッ
              プを管理する
              => おおがかりな改造が必要となる。
                 Xft が関知してくれないため、アンチエイリアスは(自前でや
                 らない限り)不可能。
                 VFlib などを使った場合、フォントの指定方法が更に複雑に
                 なる。
                 
           b. 縦表示用のフォントを別途用意する
              => ISO8859-1 程度なら、それほど負担ではないかもしれない。
                 ただ、全角文字についても、「。」など、縦と横で表示位置
                 が異なる文字があるが、どうするか?

           c. ひょっとして近い将来、X Protocol が拡張されて、フォントの
              グリフをいじることができるようになるかもしれない。
              => 一番うれしいけど、多分ありえない。
        
        3. いずれにせよ、現在の横表示用のレンダリングエンジンを流用する
           限りは、可変長コラム幅への対応は、多分不可能。
        
        特に問題になるのは、2 です。
        これがなんとかなれば、メドは立ちます。

        1. で、もし、半角だけど横には倒さない、という言語があった場合(*)、
        すべての半角文字を横に倒さない、という表示が望まれそうですので、
        全角文字との兼ね合いが問題になりそうですが、最悪、この辺のポリシ
        ーは、オプション切替でなんとかなりそうですので、それほど気には
        しておりません。

        (*)
        ちゃんと調べていませんが、CJK 以外で、縦表示する言語があった場合
        は、このような形になりそう。

        これらの問題以外や、やめたほうがいいということも含めて、縦方向
        の表示に関するご意見を伺えると幸いです _o_

	では
--
kiken
j00...@ip...

[Mlterm-dev-ja] Kochi Font on mlterm

[Araki K. <j00...@ip...>]

        荒木と申します。

        http://mlterm.sf.net/

        にて、mlterm という端末ソフトウェアを開発しております。

        早速ですが、東風フォントを mlterm 上でアンチエイリアスして表示する際の不
        具合報告をいただいておりまして、それに関連して、お伺いしたいことがあり、
        メールを送らせていただきました。

        # このメールは、mlterm の ML にも CC しております。
        # そのまま CC をつけていただければ、(加入せずとも) mlterm の ML にも配送
        # されます。
        
        不具合の症状は、例えば、JISX0208 の 「〜」(0x2141) などが表示できない、と
        いったものです。

        原因は、おそらくこういうことのようです。
        
        mlterm ではアンチエイリアスフォントの表示に際して、Xft を使用しており、
        この Xft の API が、Unicode での入出力しか受けつけてくれないために、
        JISX0208 の表示には、mlterm 内部で、JISX0208 => Unicode 変換を行なってお
        ります。

        mlterm では、内部での JIS0208 <=> Unicode 置換に際して、かつて
        www.unicode.org/Public/Mapping 以下にあり、現在は obsolete されている JIS0208.TXT(*)
        を使用しております。

        従って、JISX0208 の 0x2141 は、0x301c に変換されます。

(*)
#       Name:             JIS X 0208 (1990) to Unicode
#       Unicode version:  1.1
#       Table version:    0.9
#       Table format:     Format A
#       Date:             8 March 1994
#       Authors:          Glenn Adams <gl...@me...>
#                     John H. Jenkins <Joh...@ta...>

        ところが、東風明朝フォントを ttf2bdf して、BDF での並びを調べた限りで
        は、 www.unicode.org/Public/Mapping の CP932.TXT に元づいた配列になっ
        ているようで、0x2141 相当するグリフは 0xff5e に入っており、0x301c に
        は、何のグリフも入っておりません。

        このため、Xft で表示した場合に、「〜」が表示されないということなのだ
        ろう、と推測しております。

        # 0x301c 以外につきましても、以下のサイトにてまとめられているような
        # JISX0208<=>Unicode の様々な変換テーブル間でマッピングの異なる部分に
        # ついては、同様の問題が生じます。
        # http://www.debian.or.jp/~kubota/unicode-symbols.html

        # ちなみに、X-TT は、xc/extras/X-TrueType/JISX0208/main.c などをみますと、
        # 内部でこの辺の差異を吸収してくれるようでして、X-TT 経由で東風フォント
        # を使う限りでは、この問題は生じないようです。

        この問題の回避策としては、ひとつに、mlterm 側で、様々に存在する
        JISX0208 <=> Unicode 変換テーブルをオプションで切りかえられるようにする
        という方法が考えられます。
        しかし、これですと、ユーザが、変換テーブル間の相違という問題を理解した上
        で、どのフォントがどの変換テーブルに依存しているかということを調べて、い
        ちいち切りかえる必要が生じます。

        # mlterm 側から、どのフォントが使われているか判定できれば、内部で自動的に
        # フォントごとの変換テーブルの差異を吸収することも可能なのですが、どうも
        # 正確に判定することは期待できないようです。
        
        一方、東風フォントの方で、0x301c にも、「〜」のグリフをいれていただく、と
        いう方法も考えられます。
        この場合、Unicode としては、0x301c と 0xff5e に同じグリフが割りあてられ
        ていること自体は問題ないはずですので、個人的には、できればそのようにして
        いただけるとありがたいと思っております。

        # MS Gothic/MS Mincho では 0x301c にも「〜」が入っているようです。
        # ただ、Dynalab フォントでは、東風フォントと同様の問題が生じるようでして、
        # いずれにせよ、そちらへの対処は必要になりそうです。
        # そこで、Xft に JISX0208 をわたすのに使用する 変換テーブルとして、
        # JIS0208.TXT でなく CP932.TXTを使うオプション程度は、mlterm にも実装する
        # つもりではいます。

        とはいえ、わたしは、フォントの実装や、Unicode <=> JISX0208 のマッピング
        について、専門的な知識はほとんどありませんので、このような場合に、どのよ
        うな解決策をとるのが一番よいのか、判断しかねているのが現状です。

        もし、こうすべきだ、ということがありましたら、その点ご指摘いただけると
        幸いです。
        
--- mlterm で問題になるグリフ(JISX0208)
JISX0208 mlterm  東風フォント
0x2140   005C/Na FF3C/F
0x2141   301C/W  FF5E/F
0x2142   2016/A  2225/A
0x215D   2212/N  FF0D/F
0x2171   00A2/Na FFE0/F
0x2172   00A3/Na FFE1/F
0x224C   00AC/Na FFE2/F

--- その他(http://www.debian.or.jp/~kubota/unicode-symbols.htmlから抜粋)
---------------------------------------------------------------------------------------------
変換元                        Unicode への変換結果** / 東アジア文字幅
CCS     Shift_JIS* EUC-JP*    0208    SJIS    CP932   APPLE   0221A   0221B   JAVAA   JAVAB
---------------------------------------------------------------------------------------------
[ASCII]
0x5C    ----       0x5C       ----    ----    ----    ----    ----    005C/Na ----    005C/Na
0x7E    ----       0x7E       ----    ----    ----    ----    ----    007E/Na ----    007E/Na
[JISX0201 ローマ字]
0x5C    0x5C       ----       ----    00A5/Na 005C/Na 00A5/Na 00A5/Na ----    005C/Na 00A5/Na
0x7E    0x7E       ----       ----    203E/N  007E/Na 007E/Na 203E/N  ----    007E/Na 203E/N
[JISX0208]
0x2131  0x81 0x50  0xA1 0xB1  FFE3/F  FFE3/F  FFE3/F  FFE3/F  FFE3/F  203E/N  FFE3/F  FFE3/F
0x213D  0x81 0x5C  0xA1 0xBD  2015/A  2015/A  2015/A  2014/A  2014/A  2014/A  2015/A  2015/A
0x2140  0x81 0x5F  0xA1 0xC0  005C/Na 005C/Na FF3C/F  FF3C/F  005C/Na FF3C/F  FF3C/F  FF3C/F
0x2141  0x81 0x60  0xA1 0xC1  301C/W  301C/W  FF5E/F  301C/W  301C/W  301C/W  301C/W  301C/W
0x2142  0x81 0x61  0xA1 0xC2  2016/A  2016/A  2225/A  2016/A  2016/A  2016/A  2016/A  2016/A
0x215D  0x81 0x7C  0xA1 0xDD  2212/N  2212/N  FF0D/F  2212/N  2212/N  2212/N  2212/N  2212/N
0x216F  0x81 0x8F  0xA1 0xEF  FFE5/F  FFE5/F  FFE5/F  FFE5/F  FFE5/F  00A5/Na FFE5/F  FFE5/F
0x2171  0x81 0x91  0xA1 0xF1  00A2/Na 00A2/Na FFE0/F  00A2/Na 00A2/Na 00A2/Na 00A2/Na 00A2/Na
0x2172  0x81 0x92  0xA1 0xF2  00A3/Na 00A3/Na FFE1/F  00A3/Na 00A3/Na 00A3/Na 00A3/Na 00A3/Na
0x224C  0x81 0xCA  0xA2 0xCC  00AC/Na 00AC/Na FFE2/F  00AC/Na 00AC/Na 00AC/Na 00AC/Na 00AC/Na
[JISX0212]
0x2217  ----       0x8F,A2,97 ----    ----    ----    ----    007E/Na FF5E/F  ----    ----
---------------------------------------------------------------------------------------------

	では
--
kiken
j00...@ip...

patch (was: Re: [Mlterm-dev-ja] proposal of aafont extension)

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] proposal of aafont extension
	From: nekoie <ne...@ti...>
	Message-ID: <20020121120416.GA398%ne...@ti...>
	Date: Mon, 21 Jan 2002 21:04:16 +0900

> -V でない状態では、非常に快適に利用できています。
> # （ただ、東風フォントと同じように、「〜」記号は表示されてませんが。
> # 　XFree86を4.2.0にすれば、直っているのでしょうか‥‥？）

        東風フォントを、xtt 使って、

        xfd -fn -kochi----normal--0-0-0-0-c-0-iso10646-1
        
        こんな感じで表示してみたかぎりでは、0x301c にも、0xff5e にも「〜」が入ってるん
        ですよね。

        0x301c に「〜」が入っているようにみえるのは、XTT が間でなにかやってるだけで、
        東風フォント自体は、CP932.TXT でコードポイントを決定していて、0x301c には何も
        入ってないということかもしれませんが。

        面倒なので、放置してましたが、グダグダいっててもしかたないので、今からちゃんと
        調べてみます。

        # 入ってないということなら(一番イヤなケースですが)、0x301c にも入れてくれるよう
        # に働きかけるというのが正解かしら?
        # CP932.TXT を使う場合と、JIS0208.TXT を使う場合をオプション切り替えというのは
        # 面倒、というか変換テーブル統一して....
        
        で、aafont を拡張するパッチです。

        ISO8859_1=Kochi Mincho-iso8859-1:100;

        のようにしてみてください。

        'l' を使った判定は削除しました。

	では
--
kiken
j00...@ip...

Index: src/ml_font.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_font.c,v
retrieving revision 1.106
diff -u -r1.106 ml_font.c
--- src/ml_font.c	2002/01/19 13:08:33	1.106
+++ src/ml_font.c	2002/01/21 13:49:44
@@ -339,15 +339,17 @@
 parse_xft_font_name(
 	char **  font_family ,
 	char **  font_encoding ,
+	char **  percent ,
 	char *  font_name
 	)
 {
 	/*
 	 * XftFont format.
-	 * [Font Family]-[Font Encoding]
+	 * [Font Family]-[Font Encoding](:[Percentage])
 	 */
 
-	if( ( *font_family = kik_str_sep( &font_name , "-")) == NULL)
+	if( ( *font_family = kik_str_sep( &font_name , "-")) == NULL ||
+		font_name == NULL)
 	{
 	#ifdef  DEBUG
 		kik_warn_printf( KIK_DEBUG_TAG " illegal true type font name(%s).\n" ,
@@ -357,7 +359,7 @@
 		return  0 ;
 	}
 
-	if( ( *font_encoding = font_name) == NULL)
+	if( ( *font_encoding = kik_str_sep( &font_name , ":")) == NULL)
 	{
 	#ifdef  DEBUG
 		kik_warn_printf( KIK_DEBUG_TAG " illegal true type font name(%s).\n" ,
@@ -367,6 +369,9 @@
 		return  0 ;
 	}
 
+	/* may be NULL */
+	*percent = font_name ;
+
 	return  1 ;
 }
 
@@ -389,29 +394,12 @@
 		XFT_ENCODING , XftTypeString , "iso8859-1" ,
 		XFT_SPACING , XftTypeInteger , XFT_PROPORTIONAL , 0)))
 	{
-		u_int  l_width ;
 		u_int  w_width ;
-
-		l_width = xft_calculate_char_width( font->display , xfont , "l" , 1) ;
 		
-		if( 0 < l_width && l_width < fontsize)
-		{
-			w_width = xft_calculate_char_width( font->display , xfont , "W" , 1) ;
-		}
-		else
-		{
-			/*
-			 * XXX
-			 * I don't know why but XftTextExtents() returns full width extents for
-			 * half width characters of some fonts (e.g. Dynalab Font) , which are
-			 * excluded.
-			 */
-
-			w_width = 0 ;
-		}
+		w_width = xft_calculate_char_width( font->display , xfont , "W" , 1) ;
 		
 		XftFontClose( font->display , xfont) ;
-
+		
 		if( w_width > 0)
 		{
 			return  w_width ;
@@ -479,6 +467,8 @@
 		char *  p ;
 		char *  font_family ;
 		char *  font_encoding ;
+		char *  percent_str ;
+		u_int  percent ;
 
 		if( ( p = kik_str_alloca_dup( fontname)) == NULL)
 		{
@@ -489,16 +479,31 @@
 			return  0 ;
 		}
 
-		if( parse_xft_font_name( &font_family , &font_encoding , p))
+		if( parse_xft_font_name( &font_family , &font_encoding , &percent_str , p))
 		{
-			if( col_width == 0)
+			if( percent_str == NULL || ! kik_str_to_int( &percent , percent_str))
 			{
-				/* basic font (e.g. usascii) width */
-				ch_width = get_xft_col_width( font , font_family , fontsize) * cols ;
+				if( col_width == 0)
+				{
+					/* basic font (e.g. usascii) width */
+					ch_width = get_xft_col_width( font , font_family , fontsize) * cols ;
+				}
+				else
+				{
+					ch_width = col_width * cols ;
+				}
 			}
 			else
 			{
-				ch_width = col_width * cols ;
+				if( col_width == 0)
+				{
+					/* basic font (e.g. usascii) width */
+					ch_width = (fontsize * percent) / 200 ;
+				}
+				else
+				{
+					ch_width = (col_width * cols * percent) / 100 ;
+				}
 			}
 
 			if( is_proportional)

Re: [Mlterm-dev-ja] proposal of aafont extension

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] proposal of aafont extension
	From: Takumi ASAKI <as...@os...>
	Message-ID: <200...@os...>
	Date: Mon, 21 Jan 2002 21:44:43 +0900

>> どう実装しても、一行の文字数が固定な限り右側が空いてしまうと思うので、
>> 可能でしたら、先に挙げた、一行の最大文字数を不定にするやり方を
>> 実現して欲しいです。

        朝木さんも指摘しておられますが、一行の文字数を不定にするということは、
        VT100 端末の仕様上不可能ですので、そのようにするわけにはいかないのです _o_
        
> これですが、termcap/terminfoなどとのからみから実現もほぼ無理だと思いますが、
> 実現させたとしてもほとんど意味がないと思いますよ。
> というのは、ターミナルの幅を取得して、自分自身で改行をするアプリも多いですから。

        ターミナルの幅を取得して、というのは、resize コマンドで表示されるところの
        COLUMNS/LINESのことですよね?

        実は、コンソールアプリケーションからみえる COLUMNS/LINES と、実際の mlterm
        のスクリーンのサイズを一致させない、つまり、COLUMNS=110/LINES=45 だけど、実
        際のスクリーンの大きさは、COLUMNS=80/LINES=35 のサイズにする、ということで
        したら実装可能です。
        早い話が横スクロールバーを用意するという話です。
        たしかに、実装は面倒ではありますが、設計レベルで悩むことでもないので、やろ
        うと思えば、まぁできます。
        
        # ついこないだまで、実装するか悩んでたりします。

        ただ、問題もあるんですよね。
        
        例えば、単にウィンドウリサイズすることによって、コンソールアプリケーション
        からみたときの画面サイズを変えるわけにはいかなくなります。
        ウィンドウリサイズは、あくまで、mlterm のみかけのスクリーンサイズを変える
        という話にすぎなくなりますので、コンソールアプリケーションからみたときの
        端末の大きさを変えるには、設定画面などから変えてあげるなど、今までとは別
        の方法が必要になります。

        また、そもそも、X 端末は、(いい悪いは別にして)古来コラム幅固定ということに
        なっておりますし、w3m のテーブル表示など、それを前提にしているコンソール
        アプリケーションも多々ありますから、コラム幅を可変にしたいという話自体が、
        特殊なケースでしかありません(そもそもインド方面への対応という話から始まって
        いるわけですし)
        
        というわけですので、上にあげたウィンドウリサイズのように、コラム幅固定とい
        う通常の使い方にとって、ただ手間になるだけ、というデメリットがある以上は、
        横スクロールは実装しないほうがよいだろう、と思いました。

        その辺の問題を解決しつつ、横スクロール(または、可変長コラム幅の場合に、ウ
        ィンドウの右があいてしまう問題を解決する別の手法)を実装する方法があれば、
        提案していただければ、もちろん、実装いたします。

        # わたしも、なんかやだなぁ、とは思ってますので ^_^;

> そういえば、猫家さんで思い出したんですが、
> 猫家さんのmlterm導入手法のページで記述されている、
> XIMのフォントの問題ですが、現状でもあのままでしょうか。
> # ソースをざっと見ただけでは良く分からなかった…。
>
> ~/.mlterm/fontsの設定を使うなどの手はできませんか?
> FontPathをいじるのは他への影響が大きすぎますし。

        あー、可能です。

        # なんで今まで思いつかなかったんでしょ^_^;

        -A の場合、XIM には ~/.mlterm/font のフォントを、-A -V の場合、~/.mlterm/vfont
        のフォントを使われるようにしました。

        添付のパッチをお試し下さい。

        ただし、/usr/local/etc/mlterm 以下に /usr/local/etc/mlterm/font などが入って
        いる場合、そちらの設定を全部削除しておくか、~/.mlterm/font で、
        /usr/local/etc/mlterm/font の設定を(BOLDの設定も含めて)きちんと全部上書きして
        おかないと、~/.mlterm/font で設定したフォントがつかわれない可能性がありますか
        ら注意してください。

        # で、気付きましたが、etc/font に US_ASCII_BOLD なんてバカな設定をいれてしまっ
        # てますね ^_^;
        # US_ASCII_BOLD は、ISO8859_1_BOLD の間違いです。
         
	では
--
kiken
j00...@ip...

Index: src/ml_font_manager.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_font_manager.c,v
retrieving revision 1.110
diff -u -r1.110 ml_font_manager.c
--- src/ml_font_manager.c	2002/01/19 13:08:33	1.110
+++ src/ml_font_manager.c	2002/01/21 12:57:11
@@ -849,20 +849,28 @@
 
 	list_str_len = strlen( default_font_name) ;
 
-	if( ! is_aa( font_man))
+	if( is_aa( font_man))
 	{
-		if( ( size = ml_get_all_font_names( font_man->font_custom , 
-			&fontnames , font_man->font_size)) > 0)
+		if( is_var_col_width( font_man))
 		{
-			for( counter = 0 ; counter < size ; counter ++)
-			{
-				list_str_len += (1 + strlen( fontnames[counter])) ;
-			}
+			size = ml_get_all_font_names( font_man->v_font_custom ,
+				&fontnames , font_man->font_size) ;
 		}
+		else
+		{
+			size = ml_get_all_font_names( font_man->normal_font_custom ,
+				&fontnames , font_man->font_size) ;
+		}
 	}
 	else
+	{
+		size = ml_get_all_font_names( font_man->font_custom ,  &fontnames ,
+			font_man->font_size) ;
+	}
+	
+	for( counter = 0 ; counter < size ; counter ++)
 	{
-		size = 0 ;
+		list_str_len += (1 + strlen( fontnames[counter])) ;
 	}
 	
 	if( ( list_str = alloca( sizeof( char) * list_str_len)) == NULL)

Re: [Mlterm-dev-ja] proposal of aafont extension

[Takumi A. <as...@os...>]

朝木卓見です。

On Monday 21 January 2002 21:04, nekoie wrote:
> 猫家です。

> どう実装しても、一行の文字数が固定な限り右側が空いてしまうと思うので、
> 可能でしたら、先に挙げた、一行の最大文字数を不定にするやり方を
> 実現して欲しいです。

これですが、termcap/terminfoなどとのからみから実現もほぼ無理だと思いますが、
実現させたとしてもほとんど意味がないと思いますよ。

というのは、ターミナルの幅を取得して、自分自身で改行をするアプリも多いですから。

そういえば、猫家さんで思い出したんですが、
猫家さんのmlterm導入手法のページで記述されている、
XIMのフォントの問題ですが、現状でもあのままでしょうか。
# ソースをざっと見ただけでは良く分からなかった…。

~/.mlterm/fontsの設定を使うなどの手はできませんか?
FontPathをいじるのは他への影響が大きすぎますし。

-- 
  Che Che - Bye Bye
        From: Takumi ASAKI <as...@os...>
	URL: http://www3.osk.3web.ne.jp/~asataku/

Re: [Mlterm-dev-ja] proposal of aafont extension(was: Re: commit log [2002/01/18])

[Takumi A. <as...@os...>]

朝木卓見です。

On Monday 21 January 2002 14:48, Araki Ken wrote:
> 荒木です:-)

>         とすると、Dynalab の fixed pitch フォントが、US-ASCII 相当の文字に対して、
>         全角幅でグリフを格納しているということで間違いなさそうですね。
>         # なんでそんなことをするのか謎ですが....^_^;

「清く正しいfixed-font」として定義されてあるんではないかと邪推。
TrueTypeの仕様としてどうなっているかは知らないのですが。

東風フォントなどはフォントとしてfixedとして定義されているのでしょうか。
TrueTypeフォントの定義情報を表示してくれるツールってないんでしたっけ。

ちなみに、Turbolinux 7 に付属している TLGothicでは
東風フォントと同様に問題なくmltermが利用できるようでした。

AAでの動作をチェックしてるフォントって東風とDyna以外にはあるんでしょうか。

>         そうしますと、これにつきましては、mlterm 側では、これ以上の対処できないと
>         思います _o_

少なくとも、自動的に対処するのはやめておいた方がいいというのには同意。

>         ターミナルの幅が広いのは、'l' 文字が、fontsize より小さくなっているからの
>         ようですね。
>         (結果、'W' によるコラム幅チェックが行われてしまう)

'W'の幅が広いのが問題で、そういう意味ではmltermのターミナルの幅が広いのは正しい動作ですね。
そんなフォントを使うのが悪いというか…。

>         もし、2-2 という選択でよいということでしたら、すぐに実装します。
>         2-2 以外の選択肢がよいぞ、という場合は勿論、ここにあがっている選択肢以外
>         にも良案があれば、提案お願いいたします。

私もこの手法で問題ないと思います。

-- 
  Che Che - Bye Bye
        From: Takumi ASAKI <as...@os...>
	URL: http://www3.osk.3web.ne.jp/~asataku/

Re: [Mlterm-dev-ja] proposal of aafont extension

[nekoie <ne...@ti...>]

猫家です。

>         そういえば、猫家さんも、先日日記に、Dynalab フォントをお買いになられたように
>         書いておられましたが、mlterm で使用すると(特にmlterm -V -A したとき)どんな感
>         じですか?

-V でない状態では、非常に快適に利用できています。
# （ただ、東風フォントと同じように、「〜」記号は表示されてませんが。
# 　XFree86を4.2.0にすれば、直っているのでしょうか‥‥？）

~/.mlterm/vaafont に、プロポーショナルでない等幅のフォントを指定した場合、

> > % mlterm -A -V
> >     ターミナルの幅は狭いが、各文字は全角の幅で表示される。
> >     そのため、ASCIIの文字列には文字間に空白が発生。
> 
>         とすると、Dynalab の fixed pitch フォントが、US-ASCII 相当の文字に対して、
>         全角幅でグリフを格納しているということで間違いなさそうですね。

と同じで、半角文字の幅が倍になっています。



~/.mlterm/vaafont に、プロポーショナルなフォントを指定した場合は、
普通に、正しい間隔で表示されているようです（華康明朝体でしか試してませんが）。
ただ、一行の最大文字数（80文字）で改行しているようなので、
文字が左の方に寄りがちです。
可能なら、一行の最大文字数を不定にして、これ以上右には文字を置けなくなった
状態の時に改行して欲しいです（が、実装は大変そうですね‥‥BackSpaceとか）。



>         1. 朝木さんの提案のように、引数オプションで、すべてのフォントについて、'W'で
>            のコラム幅チェックする、しないをグローバルに設定する
> 
>         2. (v)aafont のフォント指定方法を拡張して、フォントごとに 'W' の幅チェックを
>            おこなわないように指定できるようにする。
(snip)
>         如何でしょうか?
> 
>         もし、2-2 という選択でよいということでしたら、すぐに実装します。
>         2-2 以外の選択肢がよいぞ、という場合は勿論、ここにあがっている選択肢以外
>         にも良案があれば、提案お願いいたします。

2-2で良いと私も思いますが、プロポーショナルフォントの場合は
どう実装しても、一行の文字数が固定な限り右側が空いてしまうと思うので、
可能でしたら、先に挙げた、一行の最大文字数を不定にするやり方を
実現して欲しいです。

-------------------------------
From: nekoie <ne...@ti...>

[Mlterm-dev-ja] Fwd: Second Public review of LI18NUX Locale Name Guideline

[Hironori S. <hs...@mt...>]

$B:dK\$G$9!#(B

citrus $B$N(B ML ( http://www.hauN.org/ml/b-l-j/a/index.html ) $B$G!"(B
Li18nux $B$N(B Locale Name Guideline $B$NBh(B2$B2s8x3+%l%S%e!<$N9pCN(B
  http://www.hauN.org/ml/b-l-j/a/800/840.html
  http://www.li18nux.org/subgroups/sa/locnameguide/index.html
$B$,$"$j$^$7$?$N$G!";29M$^$G$KN.$7$F$*$-$^$9!#(B

# LI18NUX Standard Codeset Name alias table
#   http://www.li18nux.org/docs/html/CodesetAliasTable-20020121.html
# $B$NCf$G!"(B%Standard Name% $B$H$7$F!"(BSHIFTJIS $B$H$+(B TCA-BIG5 $B$H$+(B GB-K $B$H$+!"(B
# $BI8=`E*$K;H$o$l$F$$$k$b$N$H$o$6$o$6JQ$($F$$$k$N$O$I$&$$$&$D$b$j$J$s$@$m!#(B
----------------------------------- 
$B:dK\(B $B9@B'(B <hs...@mt...> 
 http://www2u.biglobe.ne.jp/~hsaka/

[Mlterm-dev-ja] Re: proposal of aafont extension(was: Re: commit log [2002/01/18])

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: proposal of aafont extension(was: Re: commit log [2002/01/18])
	From: Araki Ken <j00...@ip...>
	Message-ID: <7zofjo6yqn.fsf@totally-fudged-out-message-id>
	Date: Mon, 21 Jan 2002 14:48:16 +0900

>            例えば、
>            Kochi Mincho-iso8859-1:150
>            ですと、-w 12 で mlterm を起動した場合、このフォントの横幅は、18 になり
>            ます。
>            Kochi Mincho-iso8859-1:150
>            ですと、mlterm -w 12 で起動した場合、フォントの横幅は、12になります。

        後者は、Kochi Mincho-iso8859-1:100 の間違いです _o_

	では
--
kiken
j00...@ip...

[Mlterm-dev-ja] proposal of aafont extension(was: Re: commit log [2002/01/18])

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] commit log [2002/01/18]
	From: Takumi ASAKI <as...@os...>
	Message-ID: <200...@os...>
	Date: Sun, 20 Jan 2002 23:17:34 +0900

> % mlterm -A -V
>     ターミナルの幅は狭いが、各文字は全角の幅で表示される。
>     そのため、ASCIIの文字列には文字間に空白が発生。

        とすると、Dynalab の fixed pitch フォントが、US-ASCII 相当の文字に対して、
        全角幅でグリフを格納しているということで間違いなさそうですね。

        # なんでそんなことをするのか謎ですが....^_^;
        
        そうしますと、これにつきましては、mlterm 側では、これ以上の対処できないと
        思います _o_

> 1. DynaFont(propotional)
> % mlterm -A
>     ターミナルの幅は広く、文字の間隔も大きい。
> % mlterm -A -V
>     ターミナルの幅は広いが、各文字の間隔は狭い。

        ターミナルの幅が広いのは、'l' 文字が、fontsize より小さくなっているからの
        ようですね。
        (結果、'W' によるコラム幅チェックが行われてしまう)

        こちらにつきましては、以下のような対処策をかんがえてみました。

> このコードを、オプションの指定でON/OFFしたいところですね、こうなったら。

        一応、こちらで考えております対処策としましては、

        1. 朝木さんの提案のように、引数オプションで、すべてのフォントについて、'W'で
           のコラム幅チェックする、しないをグローバルに設定する

        2. (v)aafont のフォント指定方法を拡張して、フォントごとに 'W' の幅チェックを
           おこなわないように指定できるようにする。

        個人的には、2 のほうがいいかな、と思います。

        ただ、2 についても、どう拡張するか、という点でいろいろ選択肢があります。

        1. [Font Family]-fixed-[Font Encoding]
           -fixed- がなければ、'W'の幅チェック行い、あれば、'W' の幅チェックは行な
           わない。
           これが、一番てっとり早いですが、用途が限定されます。
           (Dynalab フォントを使ってる人しかうれしくない)
           
        2. [Font Family]-[Font Encoding]:[Percentage]
           :[Percentage] 指定がなければ、'W' による幅チェックが行なわれる。
           [Percentage]では、fontsize の 何% 分をこのフォントの幅とするかを指定しま
           す。

           # [Font Family]-[Percentage]-[Font Encoding] と間にはさむのは、
           # [Font Encoding] との切れ目がわからなくなる場合がないか恐い(少くとも現在
           # はないと思いますが)ので、 ":" を使ったのですが、":" もまずいでしょうか?

           例えば、
           Kochi Mincho-iso8859-1:150
           ですと、-w 12 で mlterm を起動した場合、このフォントの横幅は、18 になり
           ます。
           Kochi Mincho-iso8859-1:150
           ですと、mlterm -w 12 で起動した場合、フォントの横幅は、12になります。
           
           これだと、Dynalab フォント以外でも、コラム幅を少し{広げ|縮め}たいときや、
           あと少しフォントの横幅が{広がる|縮まる}と見易いんだけどな、というときに
           も微調整ができて便利です。

           # もちろん、-V オプションを付けた場合は、コラム幅決定の際以外は関係なく
           # なります。

        3. [Charset]=[Font Family]-[Font Encoding](;[Font Size],[Font Family]-[Font Encoding]:[Font Width])
           趣旨は、2と同じです。
           この場合、フォントの横幅指定は、デフォルトフォントの指定ではなく、フォント
           サイズごとのフォント指定のところでだけでしか行なえません。
           唯、パーセントでなく、明示的にフォント幅をピクセス値で指定できるので、わか
           りやすくなります。

           e.g.) ISO8859_1=Kochi Mincho-iso8859-1;12,Kochi Mincho-iso8859-1:13
                 フォントサイズが 12 のとき、フォントの横幅を 13 に固定する。

        個人的には、これも 2 がよいかな、と思います。

        如何でしょうか?

        もし、2-2 という選択でよいということでしたら、すぐに実装します。
        2-2 以外の選択肢がよいぞ、という場合は勿論、ここにあがっている選択肢以外
        にも良案があれば、提案お願いいたします。

> 'W'の幅がおかしいだろうというのは分かるんですが、
> フォントに問題があるような気がしないでもないです。
> # Qt/KDEでもfixed pitchで指定したら、間隔広がってたなぁ、そういえば。

        そういえば、猫家さんも、先日日記に、Dynalab フォントをお買いになられたように
        書いておられましたが、mlterm で使用すると(特にmlterm -V -A したとき)どんな感
        じですか?

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] commit log [2002/01/18]

[Takumi A. <as...@os...>]

朝木卓見です。

On Friday 18 January 2002 22:57, Araki Ken wrote:

> 荒木です:-)

>         結局、Xft のコラム幅決定では、'W' の幅が fontsize よりおおきくなる場合に、
>         fontsize / 2 を使うようにしました。
>         多分これで、DynaFont が正常につかえるようになっていると思います。

遅くなりましたが、確認しました。
以下のようになります。

1. DynaFont(fixed pitch)
% mlterm -A
    ターミナルの幅も狭く、問題なく表示、利用できる。
% mlterm -A -V
    ターミナルの幅は狭いが、各文字は全角の幅で表示される。
    そのため、ASCIIの文字列には文字間に空白が発生。

1. DynaFont(propotional)
% mlterm -A
    ターミナルの幅は広く、文字の間隔も大きい。
% mlterm -A -V
    ターミナルの幅は広いが、各文字の間隔は狭い。

と言うところでした。
結局、自然に見えるのは fixed picthで mlterm -A の場合のみでした。

>         一応、font family が Dynalab フォントかどうかで、 'W' 幅をつかうかどうか
>         をチェックするコードも、#if 0 #endif で括っていれてます。

このコードを、オプションの指定でON/OFFしたいところですね、こうなったら。

>         ただ、いずれにせよ、adhoc な解決策ですので、なにか、もっとよい方法があれ
>         ば、お教えください _o_

'W'の幅がおかしいだろうというのは分かるんですが、
フォントに問題があるような気がしないでもないです。
# Qt/KDEでもfixed pitchで指定したら、間隔広がってたなぁ、そういえば。

Vine-2.1CRの付属のだし、フォントが古いのかなぁ。

-- 
  Che Che - Bye Bye
        From: Takumi ASAKI <as...@os...>
	URL: http://www3.osk.3web.ne.jp/~asataku/

Re: [Mlterm-dev-ja] --fade option

[nekoie <ne...@ti...>]

猫家です。

> http://labo02.tir.ne.jp/documents/mlterm/
> > （追記：mltermのヴァージョンを上げたところ、今度は該当フォントの
> > 一文字の横幅が通常の倍近くに。xtermのアンチエイリアス機能では、相
> > 変わらず文字の左側の部分しか見えず。やっぱりXftの修正待ち。）
> 
>         この、横幅が倍近くになる云々というところですが、もし、ここでおっしゃられ
>         ている「当該フォント」というのが、charter フォント(?) --- aafont に何も
>         設定しない場合、多分デフォルトで表示されるフォントだと思います --- のこ
>         とでしたら、Xft の問題ではありません。
>         強いていえば、フォントそのものの問題です。
(snip)
>         したがって、この場合、一文字の横幅が通常の倍近くになるのは正常動作です。
> 
>         # 起動した mlterm 上で、'W' を入力してみてください。
>         # 多分、コラム幅目一杯のおおきさの 'W' が表示されると思います。

なるほど、納得しました。
確かに、'W'がキチンと表示されるのに必要なサイズですね。
-Vオプションをつけて試した場合は、どの文字も綺麗な間隔で表示されますし。

自分のサイトの文書を修正致しました。

-------------------------------
From: nekoie <ne...@ti...>

Re: [Mlterm-dev-ja] commit log (was: mlterm anti alias + DynaFont)

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: [Mlterm-dev-ja] commit log (was: mlterm anti alias + DynaFont)
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Sat, 19 Jan 2002 00:55:50 +0900

>> たとえば、'I'や'l'についても文字幅を求めてやるというので逃げられませんか。
>> これらの文字についてもfontsizeと同じになるプロポーショナルフォントが
>> あるとは思えないのですが。
>
>         'i'の幅チェックで、全角幅を返すフォントを振り落した上で、'W' の幅チェックで
>         コラム幅決定するように致しました。

        'I'や'l'とおっしゃっていただいているのに、いつのまにか頭の中で 'i' に
        いれかわっておりました _o_

        多分、'i'でも問題はないとは思いますが、定番は 'l' かなぁ、という気がしま
        すので、念のため、'l'に直しておきます。

        # commit はまたのちほど。

	では
--
kiken
j00...@ip...

Re: [Mlterm-dev-ja] --fade option

[Araki K. <j00...@ip...>]

	荒木です:-)

	Subject: Re: [Mlterm-dev-ja] --fade option
	From: nekoie <ne...@ti...>
	Message-ID: <20020118174244.GA11760%ne...@ti...>
	Date: Sat, 19 Jan 2002 02:42:44 +0900

> 相変わらず再現性が不明なのですが、
> atermでも試してみたところ、同様の現象が起こりましたので、
> blackboxの方のバグではないかと思います。
> # なんとなく、bbkeysが怪しい気がするものの‥‥
>
> # 別プロセスで複数のmlterm窓を開いた場合にも、矢張りこの現象が起こる時が
> # ありました。が、多分原因はblackboxの方です。

        それでしたら、blackbox のほうがあやしいですね:)

        # とりあえず、mlterm のバグではなさそうで一安心。

        ところで、
        
http://labo02.tir.ne.jp/documents/mlterm/
> （追記：mltermのヴァージョンを上げたところ、今度は該当フォントの
> 一文字の横幅が通常の倍近くに。xtermのアンチエイリアス機能では、相
> 変わらず文字の左側の部分しか見えず。やっぱりXftの修正待ち。）

        この、横幅が倍近くになる云々というところですが、もし、ここでおっしゃられ
        ている「当該フォント」というのが、charter フォント(?) --- aafont に何も
        設定しない場合、多分デフォルトで表示されるフォントだと思います --- のこ
        とでしたら、Xft の問題ではありません。
        強いていえば、フォントそのものの問題です。

        たとえば、フォントサイズを10としたとき(mlterm -w 10)、通常の固定ピッチフ
        ォントですと 'W' の文字幅は、5 dot になるのですが、proportional な charter
        フォントの場合、10 dot になります。
        
        xterm では、この辺については全く考慮せず、すぱっとコラム幅 5 dot として、
        それより横幅の大きいフォントは切れてもしらん、ということになっているようで
        すので、幅が 5 dot よりおおきな文字については、左側部分しかみえない、とい
        うことになります。

        一方、mlterm では(そもそもは久保田さんの提案です)、ここで、コラム幅として
        'W' が収まる 10 dot 分をとることで、ほぼすべての文字を、右半分が切れること
        なしにに表示することができるようにしています。
        
        したがって、この場合、一文字の横幅が通常の倍近くになるのは正常動作です。

        # 起動した mlterm 上で、'W' を入力してみてください。
        # 多分、コラム幅目一杯のおおきさの 'W' が表示されると思います。

        バージョンアップしていただく前は、逆にコラム幅がやたらと小さくなっていたか
        と思いますが、これは、わたしが、Xft の返す情報の解釈を間違っていたからでし
        た _o_

        # わたしは、Xft のバグだと思っていたのですが、違っていたようです。
        # すみません。
        
	では
--
kiken
j00...@ip...