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: MINAMI H. <mi...@ch...> - 2001-12-11 06:02:25
|
On 11 Dec 2001 14:30:24 +0900 Araki Ken <j00...@ip...> wrote: > 一番上の行にあるべき > > ******************************************************************************** > > が消えるのは、ESC Dでスクロールアウトしてしまうからのようなのですが、ど > うして、他のX端末ではそうならないのか、よくわからないで困っています。 これは、ESC-D では画面の下端以外ではスクロールしないことにするとまずいですか? # http://vt100.net/docs/vt100-ug/chapter3.html#IND とかには # いつもスクロールしろとはかかれてないですし。 > 左右の '+' が消える理由もまだ謎です。 左については * で上書きされてる(col=1 でなく 0 にかかれてるから) だと思うのですが、scroll_up の ml_term_screen_goto_beg_of_line を はずしてからは手元では起きていないです。 今手元では vttest の *,+ を描画順に 0-8 に差し換えて下のような感じです。 #たぶん reverse index (ESC-M)をなおせばよい? 11111111111111111111111111111111111111111111111111111111111111111111111111111111 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 6 E4 5 E4 5 E4 5 E4 5 E4 5 E4 5 E4 5 E4 5 8888888888888888888888888888888888888888888888888888888888 5 4 8The screen should be cleared, and have an unbroken bor-8 5 4 8der of *'s and +'s around the edge, and exactly in the8 5 4 8middle there should be a frame of E's around this text8 5 4 8with one (1) free position around it. Push <RETURN>88 5 4 8888888888888888888888888888888888888888888888888888888888 5 4 5 4 5 4 5 4 5 4 5 4 5 4 5 42 7 5 30000000000000000000000000000000000000000000000000000000000000000000000000000000 3 3 3 3 3 3 |
|
From: Araki K. <j00...@ip...> - 2001-12-11 05:42:06
|
荒木です:-)
Subject: [Mlterm-dev-ja] Response for ESC [ c
From: MINAMI Hirokazu <mi...@ch...>
Message-ID: <200...@ch...>
Date: Tue, 11 Dec 2001 14:31:30 +0900
> vt100 escape seq. の "What are you?" (ESC [ c)への応答は
> 現在は未実装になっているのですが、場合によっては永遠に待つことになるので、
> といあえず何か返した方が良いと思います。
> 手持ちのターミナルエミュレータ-では
> rxvt, kterm, aterm, eterm
> => ESC [ ? 1 ; 2 c
> gnome-terminal, powershell
> => ESC [ ? 6 c
> konsole
> => ESC [ > 0 ; 1 1 5 ; 0 c
>
> が返されていたので、 ESC [ ? 1 ; 2 c を返すというのでどうでしょうか。
> (AVOが何なのかは知らないのですが)
はい、わたしも、先程 vttest 使っていて、そのことに気づきました。
南さんのおっしゃられたとおり実装致しました。
今のところ、わたしのところでは、
* ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *
* *
* *
* *
* *
* *
* *
* *
* *
* The screen should be cleared, and have an unbroken bor- *
* der of *'s and +'s around the edge, and exactly in the *
* middle there should be a frame of E's around this text *
* with one (1) free position around it. Push <RETURN> *
* *
* *
* *
* *
* *
* *
* *
* *
*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ *
******************************************************************************+*
+
+
+
+
+
+
こんな感じになっています。
一番上の行にあるべき
********************************************************************************
が消えるのは、ESC Dでスクロールアウトしてしまうからのようなのですが、ど
うして、他のX端末ではそうならないのか、よくわからないで困っています。
左右の '+' が消える理由もまだ謎です。
では
--
kiken
j00...@ip...
|
|
From: MINAMI H. <mi...@ch...> - 2001-12-11 05:31:36
|
vt100 escape seq. の "What are you?" (ESC [ c)への応答は
現在は未実装になっているのですが、場合によっては永遠に待つことになるので、
といあえず何か返した方が良いと思います。
#たぶん使われることはないのでしょうけど。
手持ちのターミナルエミュレータ-では
rxvt, kterm, aterm, eterm
=> ESC [ ? 1 ; 2 c
gnome-terminal, powershell
=> ESC [ ? 6 c
konsole
=> ESC [ > 0 ; 1 1 5 ; 0 c
が返されていたので、 ESC [ ? 1 ; 2 c を返すというのでどうでしょうか。
(AVOが何なのかは知らないのですが)
diff -r -u2 ../../CVS-orig/mlterm/src/ml_term_screen.c src/ml_term_screen.c
--- ../../CVS-orig/mlterm/src/ml_term_screen.c Mon Dec 10 12:39:57 2001
+++ src/ml_term_screen.c Tue Dec 11 14:20:54 2001
@@ -4233,4 +4233,13 @@
int
+ml_term_screen_report_attributes(
+ ml_term_screen_t * termscr
+ )
+{
+ write_to_pty( termscr , "\x1b[?1;2c" , 7 , NULL) ;
+ return 1 ;
+}
+
+int
ml_term_screen_report_cursor_position(
ml_term_screen_t * termscr
diff -r -u2 ../../CVS-orig/mlterm/src/ml_term_screen.h src/ml_term_screen.h
--- ../../CVS-orig/mlterm/src/ml_term_screen.h Mon Dec 10 12:39:57 2001
+++ src/ml_term_screen.h Tue Dec 11 14:16:18 2001
@@ -268,4 +268,6 @@
int ml_term_screen_report_device_status( ml_term_screen_t * termscr) ;
+int ml_term_screen_report_attributes( ml_term_screen_t * termscr) ;
+
int ml_term_screen_report_cursor_position( ml_term_screen_t * termscr) ;
diff -r -u2 ../../CVS-orig/mlterm/src/ml_vt100_parser.c src/ml_vt100_parser.c
--- ../../CVS-orig/mlterm/src/ml_vt100_parser.c Mon Dec 10 12:39:57 2001
+++ src/ml_vt100_parser.c Tue Dec 11 14:27:16 2001
@@ -1227,10 +1227,7 @@
else if( *str_p == 'c')
{
- /* send device attributes */
+ /* send device attributes as AVO */
- #ifdef DEBUG
- kik_warn_printf( KIK_DEBUG_TAG
- " ESC - [ - c is not implemented.\n") ;
- #endif
+ ml_term_screen_report_attributes( vt100_parser->termscr );
}
else if( *str_p == 'd')
|
|
From: Araki K. <j00...@ip...> - 2001-12-11 01:40:53
|
荒木です:-)
Subject: [Mlterm-dev-ja] Re: cut&paste Big5 and UCS - Big5 convertion.
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Tue, 11 Dec 2001 09:41:54 +0900
> その原因も分かりました。XFree86 の XTextListToTextProperty() は、
> "big5-0" を小文字で生成します。ですので、mkf/lib/mkf_xct_parser.c
> の 125 行目の
> if( cs_len == 6 && strncmp( cs_str , "BIG5-0" , cs_len) == 0)
> というのを、
> if( cs_len == 6 && strncasecmp( cs_str , "BIG5-0" , cs_len) == 0)
> と変えると、うまくいきます。(ただし、XTextPropertyToTextList() は、
> "BIG5-0" と大文字でも受け付けるようになっているので、mlterm の
> 生成側は変更する必要がありません。変えたほうがベターだとは思いますが)。
> (XFree86 4.1.0 以前では、"BIG5-0" が小文字でも受け付けるのでしょうか...
> もし生成側を小文字に変えるのなら、このへんも要チェックですね。)
こちら(XFree86 4.1.0)では、XTextListToTextProperty()は、送信時に、大文
字でBIG5-0を生成しますし、受信時も大文字のBIG5-0しか受け付けません。
koi8-r とかは、小文字なのに、なんで、BIG5-0 だけ大文字なんだろう、と不
思議だったのですが....
バグ対応版のみ、大文字のBIG5-0を使うようにします。
> ただし、strncasecmp() は portable ではないので、なんとかしないと
> いけません。
今 K&R 読んでみたら、strncasecmp()だけでなく、strcasecmp() 自体が、標準
関数ではないのですね。
man page でも、strcmp()は、
The strcmp() and strncmp() functions conform to ANSI X3.159-1989 (``ANSI C'').
なんですが、strcasecmp()は、
The strcasecmp() and strncasecmp() functions first appeared in 4.4BSD.
なんて書いてました。
strcasecmp() すでに使ってるんですが、特に今まで問題がでなかったということ
は、そちらは、あまり問題にならないのでしょうか...
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-11 01:20:06
|
荒木です:-)
Subject: [Mlterm-dev-ja] EXEはどこ行っちゃった？
From: "Scott Jonathan" <jo...@ho...>
Message-ID: <F14...@ho...>
Date: Mon, 10 Dec 2001 15:47:20 -0800
> 僕は夕べCVSでコードを取得したけど、コンパイルするとmltermというexecutableが
> 見つけられませんでした。コンパイルの出力を見ても問題なそうです。
>
> 僕何か正しくやっていませんか？それともバッグがありますか？
変ですね。
うまくいけば、mlterm-x.x.x/src/ 以下にバイナリが生成されるはずなんですが...
make install には成功しますでしょうか?
バイナリができないとすると、コンパイルに失敗している気がしますので、コン
パイル時の全メッセージを出力したファイルをgzip して、再度投稿していただけ
れば、何かわかるかも知れません。
# CVS 版は、あまり十分なテストはしておりませんので、コンパイルエラーがで
# る可能性は高いです。
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-11 01:14:04
|
荒木です:-) Subject: [Mlterm-dev-ja] Re: mlterm-rtl3 From: MINAMI Hirokazu <mi...@ch...> Message-ID: <200...@ch...> Date: Mon, 10 Dec 2001 17:26:25 +0900 > backspace の挙動が怪しげだったので vt100 escape sequence をテストするために > --enable-debug + ESCSEQ_DEBUG で作って、vttest (http://dickey.his.com/vttest/vttest.html)の > "Test of cursor movements" をためしてみると、 これ、すばらしいソフトですね。こんなのがあるとは知りませんでした。 早速使ってテストしてみます。 # VT100 シーケンスの実装は、rxvt 附属の xterm.seq 見ながら行き当りばったり # で実装していますので... > bidi support の有無によらないで > > RECEIVED ESCAPE SEQUENCE: ESC - [ - 23 - ; - 70 - H > RECEIVED ESCAPE SEQUENCE: ESC - [ - 42 - C > WARN:[ml_convert_col_to_char_index()] col 80 is larger than ml_image_t::num_of_cols(80) ... modified -> 79 > > で abort してしまいました。 > #原因はまだ追ってないです あ、すみません、これは、デバッグ時に埋め込んだ abort() を消し忘れていました。 別に問題はないです。 > xterm と 最初に食い違うのは IND(ESC-'D') の処理で、これは > * 行頭には戻らない > * 移動方向は「下」にする > > --- src/ml_vt100_parser.c Mon Dec 10 14:24:46 2001 > +++ /data/minami/mlterm-2.0.0.cvs20011202/src/ml_vt100_parser.c Thu Dec 6 20:48:43 2001 > > @@ -657,8 +674,8 @@ > ml_term_screen_scroll_image_upward( vt100_parser->termscr , 1) ; > > /* ml_term_screen_goto_home( vt100_parser->termscr) ; */ > - ml_term_screen_go_upward( vt100_parser->termscr , 1) ; > - ml_term_screen_goto_beg_of_line( vt100_parser->termscr) ;*/ > + ml_term_screen_go_downward( vt100_parser->termscr , 1) ; > + /* ml_term_screen_goto_beg_of_line( vt100_parser->termscr) ;*/ > } > > のが正しいように思いますが、手元の環境がダメな可能性も結構高いので > 確認してみていただけないでしょうか。 すみません、その通りです。 多分 ESC - D シーケンスを使うソフトが少ないので、気づきませんでした。 修正したしました。 行頭に戻る処理も、rxvt を確認したところ、入っていませんでしたので削除し ておきます。 # こちらでも、vttest を使ってテストを継続してみます。 では -- kiken j00...@ip... |
|
From: Araki K. <j00...@ip...> - 2001-12-11 00:55:54
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] character shaping
From: Hironori Sakamoto <hs...@mt...>
Message-ID: <200...@ud...>
Date: Mon, 10 Dec 2001 18:42:24 +0900 (JST)
> > > それから、bidi を有効にすると(w3m-m17n で)カーソル移動ごとに
> > > ちらついて動作が遅くなります。
> > 添付のパッチ(CVS currentへのパッチです)で、解決しますでしょうか?
> こちらはダメでした。
> ところで、再現していますか？
どのような状況か今一つわからないのですが、少なくとも、前回のパッチの有無
に関わらず、ちらつきが気になるというようなことはないです。
パッチを当てると、再描画の回数はかなり減りますので、わたしのところで再現
しないのは、マシンパワーとかなにか、別の問題かしら、と思ったのですが、そ
ういう話ではなさそうですね。
申し訳ありませんが、原因はよくわからないです。
では
--
kiken
j00...@ip...
|
|
From: Tomohiro K. <tk...@ri...> - 2001-12-11 00:33:23
|
久保田です。 At 10 Dec 2001 12:42:24 +0900, Araki Ken wrote: > I fixed Big5 copy and paste problem. > Please checkout current CVS repository and test it. Big5 の copy&paste をやってみました。 LANG=zh_TW.Big5 crxvt-big5 LANG=zh_TW.Big5 mlterm の間でのテストです。 そうすると、 mlterm --> crxvt-big5 は、うまくいきました。が、 crxvt-big5 --> mlterm は、うまくいきません。 その原因も分かりました。XFree86 の XTextListToTextProperty() は、 "big5-0" を小文字で生成します。ですので、mkf/lib/mkf_xct_parser.c の 125 行目の if( cs_len == 6 && strncmp( cs_str , "BIG5-0" , cs_len) == 0) というのを、 if( cs_len == 6 && strncasecmp( cs_str , "BIG5-0" , cs_len) == 0) と変えると、うまくいきます。(ただし、XTextPropertyToTextList() は、 "BIG5-0" と大文字でも受け付けるようになっているので、mlterm の 生成側は変更する必要がありません。変えたほうがベターだとは思いますが)。 ただし、strncasecmp() は portable ではないので、なんとかしないと いけません。 ところで、生成側ですが、うまいぐあいにやりましたね (というか、 こうするほうがむしろ楽なのかな)。これだと、XFree86 のバグありでも なしでも対応することができますね。(XFree86 4.1.0 以前では、"BIG5-0" が小文字でも受け付けるのでしょうか... もし生成側を小文字に変える のなら、このへんも要チェックですね。) --- 久保田智広 Tomohiro KUBOTA <ku...@de...> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ |
|
From: Scott J. <jo...@ho...> - 2001-12-10 23:47:31
|
こんにちは、ジョンといいます。これこのリストに出すのが初めてです。 僕は夕べCVSでコードを取得したけど、コンパイルするとmltermというexecutableが 見つけられませんでした。コンパイルの出力を見ても問題なそうです。 僕何か正しくやっていませんか？それともバッグがありますか？ 僕の使用しているのは以下のとおりです。 Debian 2.2 x86 2.4.13 kernel コンパイラーとか忘れちゃった：（ まだリナクスのNetscapeの中で日本語入力できるようにしていないから、このメール をウィンドウズから書いています。 教えてくれれば嬉しいです。 宜しくお願いします ジョナサン・スコット _________________________________________________________________ かわいい & 使えるブラウザで、インターネット生活もっと楽しくなる！ http://explorer.msn.co.jp/ |
|
From: Hironori S. <hs...@mt...> - 2001-12-10 09:45:17
|
$B:dK\$G$9!#(B > $B9SLZ$G$9(B:-) > > # $BFCJL$J(B font $B$,I,MW$@$C$?$j$7$^$9$+!)(B > $B$o$?$7$O!"(B > -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 > $B%U%)%s%H$r;H$C$FI=<($7$F$$$^$9!#(B $B$3$N%U%)%s%H$GI=<($5$l$^$7$?!#$9$_$^$;$s$G$7$?!#(B # 20pt $B$h$j>.$5$$$N$C$FL5$$$N$+$J$!(B... > > $B$=$l$+$i!"(Bbidi $B$rM-8z$K$9$k$H(B(w3m-m17n $B$G(B)$B%+!<%=%k0\F0$4$H$K(B > > $B$A$i$D$$$FF0:n$,CY$/$J$j$^$9!#(B > $BE:IU$N%Q%C%A(B(CVS current$B$X$N%Q%C%A$G$9(B)$B$G!"2r7h$7$^$9$G$7$g$&$+(B? $B$3$A$i$O%@%a$G$7$?!#(B $B$H$3$m$G!":F8=$7$F$$$^$9$+!)(B ----------------------------------- $B:dK\(B $B9@B'(B <hs...@mt...> http://www2u.biglobe.ne.jp/~hsaka/ |
|
From: MINAMI H. <mi...@ch...> - 2001-12-10 08:27:12
|
南です。 最近忙しかったのであまり追いかけられてなかったのですが、cvs版を試してみました。 久保田さんの書いておられたことを参考にして LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 mlterm -km utf8 -bi で実行して、 setxkbmap il したあとに AltGr+適当なキーを押してみると、方向が切りかわっているようでした。 #ここからはbidiとはたぶん関係ないです backspace の挙動が怪しげだったので vt100 escape sequence をテストするために --enable-debug + ESCSEQ_DEBUG で作って、vttest (http://dickey.his.com/vttest/vttest.html)の "Test of cursor movements" をためしてみると、bidi support の有無によらないで RECEIVED ESCAPE SEQUENCE: ESC - [ - 23 - ; - 70 - H RECEIVED ESCAPE SEQUENCE: ESC - [ - 42 - C WARN:[ml_convert_col_to_char_index()] col 80 is larger than ml_image_t::num_of_cols(80) ... modified -> 79 で abort してしまいました。 #原因はまだ追ってないです とりあえず無視して進むようにした場合のテストの実行結果なのですが、 手元では xterm|rxvt とかなり違っていました。 まずこっちを追い掛けてみようかと思います。 xterm と 最初に食い違うのは IND(ESC-'D') の処理で、これは * 行頭には戻らない * 移動方向は「下」にする --- src/ml_vt100_parser.c Mon Dec 10 14:24:46 2001 +++ /data/minami/mlterm-2.0.0.cvs20011202/src/ml_vt100_parser.c Thu Dec 6 20:48:43 2001 @@ -657,8 +674,8 @@ ml_term_screen_scroll_image_upward( vt100_parser->termscr , 1) ; /* ml_term_screen_goto_home( vt100_parser->termscr) ; */ - ml_term_screen_go_upward( vt100_parser->termscr , 1) ; - ml_term_screen_goto_beg_of_line( vt100_parser->termscr) ;*/ + ml_term_screen_go_downward( vt100_parser->termscr , 1) ; + /* ml_term_screen_goto_beg_of_line( vt100_parser->termscr) ;*/ } のが正しいように思いますが、手元の環境がダメな可能性も結構高いので 確認してみていただけないでしょうか。 |
|
From: Araki K. <j00...@ip...> - 2001-12-10 04:04:17
|
荒木です:-)
Subject: Re: [Mlterm-dev-ja] character shaping
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Mon, 10 Dec 2001 12:01:30 +0900
> それから、mlconfig ですが、ウィンドウの大きさがだんだん大きく
> なってきています。640x480 に収まるように画面を設計したほうが
> いいと思います。(たとえば、下半分を右側に持ってくるとか、
> せっかくタブを使ってるんだから分類してタブを増やすとか)。
です。
なんとか、小さくしてみます。
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-10 04:02:13
|
荒木です:-)
Subject: [Mlterm-dev-ja] Re: character shaping
From: Hironori Sakamoto <hs...@mt...>
Message-ID: <200...@ud...>
Date: Mon, 10 Dec 2001 12:23:46 +0900 (JST)
> CVS 版の Bidi 対応を試して見ましたが、
> shaping が上手く表示できません。
> # shaping 無しの rtl3 はそれなりに表示されていました。
> xterm-152-27 も同様の表示になるので私の環境の問題でしょうか？
> # 特別な font が必要だったりしますか？
わたしは、
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
フォントを使って表示しています。
御使用のフォントに、
0xfb50 - 0xfdff(アラビア表示形A)
が入っているか、確認していただけますでしょうか?
> それから、bidi を有効にすると(w3m-m17n で)カーソル移動ごとに
> ちらついて動作が遅くなります。
添付のパッチ(CVS currentへのパッチです)で、解決しますでしょうか?
> あと、FreeBSD(98) 2.2.8 では biwidth の文字が出なくなって
> しまったので調べてみます。
mkf/lib/mkf_ucs_property.c で、
#define mkf_ucs_property_t mkf_ucs_property_intern_t
#include "table/mkf_ucs_alphabet_property.table"
#include "table/mkf_ucs_extension_a_property.table"
#include "table/mkf_ucs_cjk_property.table"
#include "table/mkf_ucs_hangul_property.table"
#include "table/mkf_ucs_compat_property.table"
#undef mkf_ucs_property_t
この define をしなければ、表示されたりしますか?
では
--
kiken
j00...@ip...
Index: ml_image_line.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image_line.c,v
retrieving revision 1.35
diff -u -r1.35 ml_image_line.c
--- ml_image_line.c 2001/12/08 08:35:39 1.35
+++ ml_image_line.c 2001/12/10 03:48:54
@@ -677,7 +677,10 @@
ml_char_copy( &line->chars[line->visual_order[counter]] , &src[counter]) ;
}
- ml_imgline_set_modified( line) ;
+ if( line->is_modified)
+ {
+ ml_imgline_set_modified( line) ;
+ }
line->is_bidi = 1 ;
|
|
From: Araki K. <j00...@ip...> - 2001-12-10 03:54:05
|
荒木です:-)
* Big5 copy and paste problem is fixed.
(--big5bug option is added)
* minor bugs of bidi are fixed.
* documents are updated except --big5bug option.
* character shaping stops unless mlterm works on bidi mode.
Big5 の copy and paste 問題を修正しましたので commit しました。
それ以外にあがっている問題への対処はまだです _o_
ESC % / シーケンスに対応する過程で、ソースの構成がかなり変わりました
ので、新しいバグが混入しているかもしれません。
では
--
kiken
j00...@ip...
|
|
From: Hironori S. <hs...@mt...> - 2001-12-10 03:25:59
|
$B:dK\$G$9!#(B CVS $BHG$N(B Bidi $BBP1~$r;n$7$F8+$^$7$?$,!"(B shaping $B$,>e<j$/I=<($G$-$^$;$s!#(B # shaping $BL5$7$N(B rtl3 $B$O$=$l$J$j$KI=<($5$l$F$$$^$7$?!#(B xterm-152-27 $B$bF1MM$NI=<($K$J$k$N$G;d$N4D6-$NLdBj$G$7$g$&$+!)(B # $BFCJL$J(B font $B$,I,MW$@$C$?$j$7$^$9$+!)(B $B;n$7$F$_$?$N$O!"(B http://www.sfc.keio.ac.jp/~s01397ms/d/?date=200110 $B$N(B 2001-10-23 $B$r(B w3m-m17n $B$G8+$^$7$?!#(B echo "\0330\0267\0331\0216\0330\0247\0331\0204\0331\0220\0330\0250\0331\0217" $B$G$b$$$$$G$9!#(B $B$=$l$+$i!"(Bbidi $B$rM-8z$K$9$k$H(B(w3m-m17n $B$G(B)$B%+!<%=%k0\F0$4$H$K(B $B$A$i$D$$$FF0:n$,CY$/$J$j$^$9!#(B $B$"$H!"(BFreeBSD(98) 2.2.8 $B$G$O(B biwidth $B$NJ8;z$,=P$J$/$J$C$F(B $B$7$^$C$?$N$GD4$Y$F$_$^$9!#(B ----------------------------------- $B:dK\(B $B9@B'(B <hs...@mt...> http://www2u.biglobe.ne.jp/~hsaka/ |
|
From: Tomohiro K. <tk...@ri...> - 2001-12-10 02:53:09
|
久保田です。 At 09 Dec 2001 02:28:53 +0900, Araki Ken wrote: > cvs update で、最新版のコードを取得して、試してみて下さい。 やっと、BiDi を試してみました。 setxkbmap il とやって、右 Alt + いろんな文字、で入力してみると、奇妙というか おもしろいというか、こんな感じになるんですね。 それから、mlconfig ですが、ウィンドウの大きさがだんだん大きく なってきています。640x480 に収まるように画面を設計したほうが いいと思います。(たとえば、下半分を右側に持ってくるとか、 せっかくタブを使ってるんだから分類してタブを増やすとか)。 --- 久保田智広 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-10 02:44:24
|
久保田です。 At 10 Dec 2001 11:25:18 +0900, Araki Ken wrote: > > ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/ > > > > にある、BIG5.gz を使うべきと思います。 > ありがとうございます。 > Big5 の copy and paste では、XFree86 のバグにも、オプション による切替え > という形で対応しました。 > commit したあと、dev-en の方で、native の方の意見を伺おうと思います。 Big5 変換テーブルについても、native speaker の意見を聞いたほうが いいと思います (そのつもりなのでしょうか)。 --- 久保田智広 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-10 02:36:53
|
荒木です:-) Subject: [Mlterm-dev-ja] Big5 <-> Unicode From: Hironori Sakamoto <hs...@mt...> Message-ID: <200...@ud...> Date: Mon, 10 Dec 2001 10:55:30 +0900 (JST) > Big <-> Unicode の変換テーブルを Unicode.org の(obsolete になった) > BIG5.TXT から変換して使っているようですが、 はい。 > ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/ > > にある、BIG5.gz を使うべきと思います。 > Windows 版 Big5 である CP950 の変換表 > > http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP950.TXT > > と 0xA140-C67E, 0xC940-F9FE の範囲は同じです。 > 0xC6A1-C8FE に関しては、CP950.TXT は未定義ですが、 > xcin.linux.org.tw は PUA(U+F600-F8FF) に割り当てています。 > > HKSCS - Hong Kong Supplementary Character Set > (Big5 + 0x88A0-A0FE, 0xFA40-FEFE) も対応するなら > ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/ にある > BIG5HKSCS.gz を使えばいいと思います。 ありがとうございます。 Big5 の copy and paste 問題が解決したら取り掛かろうと思います。 Big5 の copy and paste では、XFree86 のバグにも、オプション による切替え という形で対応しました。 commit したあと、dev-en の方で、native の方の意見を伺おうと思います。 では -- kiken j00...@ip... |
|
From: Hironori S. <hs...@mt...> - 2001-12-10 01:58:39
|
$B:dK\$G$9!#(B Big5 $B$NOC$,=P$F$$$k$N$G$D$$$G$K!#(B Big <-> Unicode $B$NJQ49%F!<%V%k$r(B Unicode.org $B$N(B(obsolete $B$K$J$C$?(B) BIG5.TXT $B$+$iJQ49$7$F;H$C$F$$$k$h$&$G$9$,!"(B ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/ $B$K$"$k!"(BBIG5.gz $B$r;H$&$Y$-$H;W$$$^$9!#(B Windows $BHG(B Big5 $B$G$"$k(B CP950 $B$NJQ49I=(B http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP950.TXT $B$H(B 0xA140-C67E, 0xC940-F9FE $B$NHO0O$OF1$8$G$9!#(B 0xC6A1-C8FE $B$K4X$7$F$O!"(BCP950.TXT $B$OL$Dj5A$G$9$,!"(B xcin.linux.org.tw $B$O(B PUA(U+F600-F8FF) $B$K3d$jEv$F$F$$$^$9!#(B # $BJQ49$@$1$K;H$&$N$J$i!"(BPUA $B$K$O3d$jEv$F$J$$$[$&$,NI$$$H!"(B # $B;d$O;W$$$^$9!#(B HKSCS - Hong Kong Supplementary Character Set (Big5 + 0x88A0-A0FE, 0xFA40-FEFE) $B$bBP1~$9$k$J$i(B ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/ $B$K$"$k(B BIG5HKSCS.gz $B$r;H$($P$$$$$H;W$$$^$9!#(B ($B$*$=$i$/(B)$B8x<0%5%$%H$G$"$k(B http://www.info.gov.hk/digital21/eng/hkscs/ $B$N$b$N$H$N0lCW$O3NG'$7$^$7$?$,!"(B http://www.microsoft.com/hk/hkscs/ $B$N$b$N$H$O0lJ8;z(B(0x8BC2) $B$@$10c$$$^$9!#(B($B$J$s$G$d$M$s(B) http://www2u.biglobe.ne.jp/~hsaka/w3mnote.cgi?month=200110#20011003190307.04723 $B$NJU$b$_$F$/$@$5$$!#(B native $B$NJ}(B http://trends.ca/~acli/ambrose/not-work/hacking/w3m/ $B$+$i(B w3m-m17n $B$NJQ49I=(B(Unicode.org $B$N(B BIG5.TXT $B%Y!<%9(B)$B$O%@%a$H(B $B$$$o$l$F8+D>$7$?7k2L$G$9!#(B # w3m-m17n $B$bAa$/99?7$;$M$P(B... ----------------------------------- $B:dK\(B $B9@B'(B <hs...@mt...> http://www2u.biglobe.ne.jp/~hsaka/ |
|
From: Tomohiro K. <tk...@ri...> - 2001-12-09 23:19:07
|
久保田です。 At 10 Dec 2001 04:08:49 +0900, Araki Ken wrote: > 手元で確認した限り、<Big5文字列>が複数文字からなるときに、M/Lによる長さ > 指定には、先頭の一文字分2bytes以外は含まれないようです。 これは、XFree86 のバグです。CVS 版では、今年 9 月ごろに修正されています。 CHANGELOG を見ると、 > XFree86 4.1.0.1 (xx September 2001) ... > 640. Improve "true Big5" and "Emacs Big5" support (#4792, Yong Li, #4798, > Tomohiro KUBOTA). > 639. Fix a non-standard character set bug in Xlib (#4792, Ivan Pascal). ... > 636. Fix an Xlib bug that affects conversion from CTEXT to multibyte / > wide character (#4780, Tomohiro KUBOTA, , #4783, Bruno Haible). ... > 632. Fix Xlib's parsing of CTEXT with multi-byte characters in GR (#4761, > Juliusz Chroboczek). といった感じです。(すごいバグバグだった、というのが従来の X.org/XFree86 の状態です。作ったやつは誰だ、と言いたい。それ以上に、CTEXT 関連コード なんて昔からあってすでに枯れきっていると信じていたので愕然としました。 こんなにバグバグなのがなぜ長年にわたり誰も修正しなかったのでしょう。) # たとえば、2 バイト文字で終わる文字列のコピー&ペーストがうまくいかない、 # とか。ただし上記の一部のバグについては、最近 XFree86 に入ったばかりの # Unicode との変換についてのものですので、それについては「枯れていたはず」 # というのはあたりません) ですので、ぼくの意見としては、規格通りの実装だけに対応すればいいと 思います。ただし、native speaker がどう思うか、というのが優先すると 思います。 --- 久保田智広 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-09 19:39:27
|
荒木です:-)
Subject: [Mlterm-dev-ja] Big5 CTEXT
From: Araki Ken <j00...@ip...>
Message-ID: <200...@pd...>
Date: 10 Dec 2001 04:08:49 +0900
> ちゃんと読んでいませんが、lcCT.c あたりを眺めてみて、そういうことかな、
> と思っています。
書き忘れましたが、一応
http://www.xfree86.org/pipermail/i18n/2001-June/002052.html
この辺とかには目を通してはいます。
# でもよくわからない...
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-09 19:20:22
|
荒木です:-)
随分古い話ですが。
Subject: [mlterm: 4] どうもです。
From: Tomohiro KUBOTA <tk...@ri...>
Message-ID: <200...@si...>
Date: Thu, 25 Oct 2001 21:43:16 +0900
> Big5 は、このうち、
> 01/11 02/05 02/15 03/02 M L 2 octets per character
> を使っています。つまり、
> ESC "%" "/" "2" M L "B" "I" "G" "5" "-" "0" 0x02 <Big5文字列>
> となります。
> ここで、M と L は、それ以降の文字列すべて
> (BIG5-0 0x02 内容) の合計バイト数 (14 ビット) を表します。
> ( (M - 128) * 128 ) + (L - 128) が、それになります。
KOI8-R では、
ESC "%" "/" "2" M L "k" "o" "i" "8" "-" "r" 0x02 [KOI8-R char] ESC "%" \
"/" "2" M L "k" "o" "i" "8" "-" "r" 0x02 [KOI8-R char]
のように、KOI8-R 一文字につき、毎回 ESC % / シーケンスを出すことで、CTEXT
の規格通りの動作をしてくれるので、特に問題はないのですが、Big5については
少々疑問があります。
手元で確認した限り、<Big5文字列>が複数文字からなるときに、M/Lによる長さ
指定には、先頭の一文字分2bytes以外は含まれないようです。
af 64 a8 a5 aa 4f 20
なBig5シーケンスだと、CTEXTでは、
1b 25 2f 32 80 89 42 49 47 35 2d 30 02 80 89 42 49 47 35 2d 30 02 \
af 64 a8 a5 aa 4f 1b 28 42 20
こんな感じです。
そこで、XLC_LOCALE/zh_TW.big5 を眺めていると、
byte1 \xa1,\xf9
byte2 \x40,\x7e;\xa1,\xfe
ct_encoding BIG5-0:GLGR:\x1b\x25\x2f\x32\x80\x89\x42\x49\x47\x35\x2d\x30\x02
と書いてありました。
XLC_LOCALE の定義方法については全くわかりませんので、推測ですが、これは以
下のように考えてよいのでしょうか?
まず、ct_encoding が、GLGR である場合、GLGR 領域を全部 Big5 に割り当てる。
その際の指示シーケンスとして、
\x1b\x25\x2f\x32\x80\x89\x42\x49\x47\x35\x2d\x30\x02
を使う。
(事実上、指示シーケンスは、
\x1b\x25\x2f\x32\x80\x89\x42\x49\x47\x35\x2d\x30\x02\x80\x89\x42\x49\x47\x35\x2d\x30\x02
と考えてよい)
一度指示されれば、それ以降は、byte1,byte2 で定義された範囲の文字列が続く
限りは、それをBig5として解釈する。
ちゃんと読んでいませんが、lcCT.c あたりを眺めてみて、そういうことかな、
と思っています。
一方、XLC_LOCALE/koi8-r では、
XLC_CHARSET_DEFINE
csd0 {
charset_name KOI8-R
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINE
と、XLC_CHARSET_DEFINEで、\x1b % / 1を使った文字集合として定義されており
ますので、CTEXT の規格通りのシーケンスが生成されているのだと思っています。
# なぜ、Big5やGBKでは、XLC_CHARSET_DEFINE しないのか、よくわかりませんが...
一応、手元では、この解釈にそって実装し、Big5 の copy&paste ができるように
なっていますが、実際こういう解釈で正しいのか、ご指摘いただけると幸いです。
では
--
kiken
j00...@ip...
|
|
From: Mike F. <mf...@su...> - 2001-12-09 16:25:38
|
Tomohiro KUBOTA <tk...@ri...> writes:
> 久保田です。
>
> すみませんが、ぜんぜん分かりません。たぶん kinput2 の問題だと
> 思います。
>
> At Tue, 04 Dec 2001 11:36:49 +0100,
> Mike Fabian wrote:
>
>> > それともうひとつ、ja_JP というロケールは何の alias になっていますか。
>> > こちらでは、ja_JP.eucJP と同じ意味になります。/etc/locale.alias を
>> > チェックしてください。
>>
>> こちらに同じです：
>>
>> mfabian@gregory:~$ grep ja /usr/share/locale/locale.alias
>> japanese ja_JP.eucJP
>> japanese.euc ja_JP.eucJP
>> ja_JP ja_JP.eucJP
>> ja_JP.ujis ja_JP.eucJP
>> japanese.sjis ja_JP.SJIS
>> mfabian@gregory:~$
>
> XFree86 のロケールについては、どうでしょうか。
> /usr/X11R6/lib/X11/locale/locale.dir
> /usr/X11R6/lib/X11/locale/locale.alias
> を、チェックしてください。
これも同じじゃないか：
mfabian@gregory:~$ grep ja_JP /usr/X11R6/lib/X11/locale/locale.alias
ja_JP ja_JP.eucJP
ja ja_JP.eucJP
ja.JIS ja_JP.JIS7
ja.SJIS ja_JP.SJIS
ja_JP ja_JP.eucJP
ja_JP.ujis ja_JP.eucJP
ja_JP.eucjp ja_JP.eucJP
Jp_JP ja_JP.eucJP
ja_JP.AJEC ja_JP.eucJP
ja_JP.EUC ja_JP.eucJP
ja_JP.EUC_JP ja_JP.eucJP
ja_JP.ISO-2022-JP ja_JP.JIS7
ja_JP.JIS ja_JP.JIS7
ja_JP.jis7 ja_JP.JIS7
ja_JP.mscode ja_JP.SJIS
ja_JP.SJIS ja_JP.SJIS
ja_JP.utf8 ja_JP.UTF-8
japanese ja_JP.eucJP
japanese.euc ja_JP.eucJP
japanese.sjis ja_JP.SJIS
japan ja_JP.eucJP
Japanese-EUC ja_JP.eucJP
ja_JP: ja_JP.eucJP
ja: ja_JP.eucJP
ja.JIS: ja_JP.JIS7
ja.SJIS: ja_JP.SJIS
ja_JP: ja_JP.eucJP
ja_JP.ujis: ja_JP.eucJP
ja_JP.eucjp: ja_JP.eucJP
Jp_JP: ja_JP.eucJP
ja_JP.AJEC: ja_JP.eucJP
ja_JP.EUC: ja_JP.eucJP
ja_JP.EUC-JP: ja_JP.eucJP
ja_JP.ISO-2022-JP: ja_JP.JIS7
ja_JP.JIS: ja_JP.JIS7
ja_JP.jis7: ja_JP.JIS7
ja_JP.mscode: ja_JP.SJIS
ja_JP.SJIS: ja_JP.SJIS
ja_JP.utf8: ja_JP.UTF-8
japanese: ja_JP.eucJP
japanese.euc: ja_JP.eucJP
japanese.sjis: ja_JP.SJIS
japan: ja_JP.eucJP
Japanese-EUC: ja_JP.eucJP
mfabian@gregory:~$ grep ja_JP /usr/X11R6/lib/X11/locale/locale.dir
ja/XLC_LOCALE ja_JP.eucJP
ja.SJIS/XLC_LOCALE ja_JP.SJIS
ja.JIS/XLC_LOCALE ja_JP.JIS7
en_US.UTF-8/XLC_LOCALE ja_JP.UTF-8
ja/XLC_LOCALE: ja_JP.eucJP
ja.SJIS/XLC_LOCALE: ja_JP.SJIS
ja.JIS/XLC_LOCALE: ja_JP.JIS7
en_US.UTF-8/XLC_LOCALE: ja_JP.UTF-8
mfabian@gregory:~$
本当に可笑しいです。
--
Mike Fabian <mf...@su...> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
|
|
From: Araki K. <j00...@ip...> - 2001-12-08 17:40:26
|
荒木です:-)
shaping 処理も実装しました。
これで、(バグがない限り)アラビア文字も正しく表示されるようになりましたので、
xterm の Bidi実装とほぼ対等になったと期待しています。
もし、xterm と違うぞ、などということがありましたら、レポートして下さいませ_o_(*)
(*)
RTL文字列の領域選択に関してだけは、xtermと仕様が異なります。
mlterm-rtl3 には、全画面クリアしたあと、RTL処理がされないというバグがあり
ましたので、その修正も行いました。
大分安定してきたように思いますし、せっかくCVSがあるのに 毎回パッチを出す
のもアレですので、今回から見切り発車で、修正分は CVS リポジトリに突っ込ん
でいます。
cvs update で、最新版のコードを取得して、試してみて下さい。
commit logはこんな感じです。
* Bidi is supported.(FriBidi is required)
* Arabic character shaping is supported.
* ml_image module is cleaned up.
* many minor bugs are fixed.
* mlterm icons are added.(thanks to Kubota Tomohiro san.)
# Bidi については、native でない人ばかりでやっててもどうしようもないので、
# XFree86 i18n-MLにも、協力を求めるメールを投げてみます。
では
--
kiken
j00...@ip...
|
|
From: Araki K. <j00...@ip...> - 2001-12-07 16:09:43
|
I made a serious mistake.
a patch to fix it is attached.
--
kiken
j00...@ip...
Index: ml_image_line.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_image_line.c,v
retrieving revision 1.33
diff -u -r1.33 ml_image_line.c
--- ml_image_line.c 2001/12/07 03:42:45 1.33
+++ ml_image_line.c 2001/12/07 15:55:32
@@ -542,7 +542,7 @@
}
int
-ml_convert_char_index_bidi_to_normal(
+ml_convert_char_index_normal_to_bidi(
ml_image_line_t * line ,
int char_index
)
@@ -567,7 +567,7 @@
}
int
-ml_convert_char_index_normal_to_bidi(
+ml_convert_char_index_bidi_to_normal(
ml_image_line_t * line ,
int char_index
)
|
792 messages has been excluded from this view by a project administrator.
