mlterm-dev-en — mlterm mailing list(English)

[Mlterm-dev-en] commit log[20020124]

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

       Hi,

       I committed changes below.

[20020124]
* 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.

[20020124]
* 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

       font/vfont/aafont/vaafont format was changed.
       (of cource , compatible with older format)

       But documentation about it is not still updated , sorry.

--
kiken
j00...@ip...

[Mlterm-dev-en] commit log [20020123] and plan of 2.2.0 release

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

	Hi,

        I committed changes below.

[20020123]
* ISCII rendering is tuned up.
* etc/font and etc/vfont format is changed. (default font can be specified.)

[20020122]
* -c/--cp932/use_cp932_ucs_for_xft option is added.

[20020122]
* aafont file format is changed. ([Font Family]-[Font Encoding](:[Percentage]))
* font or vfont is used when XIM fontset is created under AA mode.

        BTW , I will release 2.2.0 by the end of this month , though
        I don't know whether ISCII can be explicitly supported or not.

        So I'd like you to test CVS current mlterm.

        Best Regards.

--
kiken
j00...@ip...

[Mlterm-dev-en] commit log [2002/01/20]

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

	Hi,

        I committed changes below these days.
        
[20020120]
* many codes are cleaned up.
* 'l' instead of 'i' is checked for DynaFont problem.

[20020119]
* DynaFont problem is fixed by checking 'i' character width before 'W' character.
  (thanks to Asaki Takumi san)
* font,aafont are read before vfont,vaafont for variable column width fonts.

[20020118]
* XftTextExtents returns full width extents for DynaFont "W" , which makes space between
  characters too wide. fixed(there is still room for improvement).
  (thanks to Asaki Takumi san)
* not only background color but foreground color is faded.

--
kiken
j00...@ip...

[Mlterm-dev-en] commit log [2002/01/15]

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

	Hi,

[20020115-2]
* calculating width of anti alias font was somewhat wrong. fixed.
* variable column width anti alias fonts , which are specified in ~/.mlterm/vaafont ,
  are supported.
* #error instead of #<key>=#error is returned.
* ESC]5380;wall_pictureBEL returns #wall_picture= instead of #error when no wall picture
  is used.

[20020115]
* #<key>=#error instead of #<key>=error is returned when error happens around ESC]5380;ptBEL
  sequence.
* JISX0201 katakana copy&paste failed. fixed.(thanks to Kubota Tomohiro san)
* ESC]5380;pwdBEL is supported.

       First , I made a serious mistake around calculation of Xft font width and fixed it.

       Next , mlterm configuration protocol is almost completed except ISCII , and
       http://www2u.biglobe.ne.jp/~hsaka/w3m/patch/w3mmlconfig.tar.gz , which uses
       the protocol and is made by Sakamoto Hironori san , works fine.

       tar zxvf w3mmlconfig.tar.gz , edit Makefile and make ; make install.
       then w3mmlconfig command will show you a configuration menu based on w3m local-CGI.

--
kiken
j00...@ip...

[Mlterm-dev-en] mlterm-2.1.2pl2

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

	Hi,

        I released mlterm-2.1.2pl2 patch kit.

        It fixes #501928 report in bug track , and that's all.
        #501928 is a report of a compilation error , so version up is
        not necessary for those who could compile 2.1.2pl1.
        
--
kiken
j00...@ip...

[Mlterm-dev-en] commit log [2002/01/13]

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

       Hi.

       I committed changes below.

[2002/01/13-1]
* mlterm configuration protocol is decided and implemented.(see doc/en/PROTOCOL)
* cursor highlight bug is fixed.

[2002/01/13-2]
* MSB of single shifted G3 characters in EUCJP(EUCJISX0213) is set.(thanks to Kubota Tomohiro san)
* ESC]5379;wall_picture=BEL stops wall picture.

       Now mlterm has new feature , that is , ESC]5379;<key>=<value>BEL and
       ESC]5380;<key>BEL sequences , which replace mlconfig(GUI configuration menu) ,
       are supported.

       Please see doc/en/PROTOCOL file for the details.

       Then , http://www2u.biglobe.ne.jp/~hsaka/w3m/patch/w3mmlconfig.tar.gz
       with an attached patch , which uses w3m local-CGI feature , supports it.

       Please install w3mmlconfig.tar.gz as follows and test it !

       1. Change W3M_LIBDIR and PERL in Makefile.
       2. patch -p1 < [attached patch]
       3. make ; make install
       4. w3m file:///$W3M_LIBDIR/mlconfig.cgi

       Curses based configuration menu , which Minami Hirokazu san is working on ,
       is coming soon.

       Best Regards.
       
--
kiken
j00...@ip...

diff -u w3mmlconfig/mlconfig.cgi.in w3mmlconfig.new/mlconfig.cgi.in
--- w3mmlconfig/mlconfig.cgi.in	Sat Jan 12 10:03:50 2002
+++ w3mmlconfig.new/mlconfig.cgi.in	Sun Jan 13 16:21:31 2002
@@ -205,7 +205,7 @@
 		$k =~ /^_/ && next;
 		print TTY "\033]5380;$k\007";
 		$_ = <TTY>;
-		s/^${k}=// || next;
+		s/^#${k}=// || next;
 		chop;
 		$value->{$k} = $_;
 	}
@@ -223,10 +223,17 @@
 		$val = $value;
 	}
 
+	push( @key , "wall_picture") ;
+
 	open(TTY, ">/dev/tty");
 	for $k (@key) {
 		$k =~ /^_/ && next;
-		$val->{$k} eq $val->{"default-$k"} && next;
+		if($val->{$k} eq "" && exists $key_attr->{$k} && $key_attr->{$k}->{type} eq 'checkbox') {
+			$val->{$k} = "false";
+		}
+		if(exists $val->{"default-$k"}) {
+			$val->{$k} eq $val->{"default-$k"} && next;
+		}
 		print TTY "\033]5379;$k=$val->{$k}\007";
 	}
 	close(TTY);

[Mlterm-dev-en] commit log [2002/01/11]

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

	Hi,

        I committed changes below.
        
* cursor form is changed when window is focused or unfocused.
* when a character whose color is reversed is drawn under wall paper or tranparent mode ,
  not background image but the background color of the charcter is used.
  (thanks to Masao Uebayashi san)
* ESC ] 20 ; pt BEL sequence is supported.(thanks to Minami Hirokazu san)

--
kiken
j00...@ip...

Re: commit log [2002/01/10] (was: Re: [Mlterm-dev-en] About some Trad-Chinese characters.)

[Edward G.J. L. <ed...@ms...>]

Hello, Araki Ken san,

  Many thanks.:)

  It looks great, thanks for so quick respone(surprise!:).


On Thu, Jan 10, 2002, Araki Ken wrote:
> 	Hi,
> 
>         this is a commit log.
>         
> * big5 unstandard characters can be converted to and from ucs4.
[...]
>         Now I use both BIG5.gz and BIG5HKSCS.gz.
>         BIG5HKSCS.gz(except 0xa140 - 0xa3bf , 0xa440 - 0xc67e , 0xc940 - 0xf9d5)
>         is used only for HKSCS.
> 
>         Appropriate mapping table is selected by locale info(zh_TW or zh_HK) for the
>         region shared with BIG5.gz and BIG5HKSCS.
> 
>         Then , I think you can show unstandard big5 characters under anti alias mode.
> 
>         Please cvs checkout and test it:)
> 
>         Best Regards.
>         
> --
> kiken
> j00...@ip...

-- 
Warm Regards,
Edward G.J. Lee

commit log [2002/01/10] (was: Re: [Mlterm-dev-en] About some Trad-Chinese characters.)

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

	Hi,

        this is a commit log.
        
* big5 unstandard characters can be converted to and from ucs4.


	Subject: Re: [Mlterm-dev-en] About some Trad-Chinese characters.
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: Thu, 10 Jan 2002 12:33:15 +0900

>>   The another problem is big5 Japanese characters are not the same maping in
>>   BIG5.gz and BIG5HKSCS.gz. Such as U+F6F8 => 0xc6e8(big5), U3042 => 0xc6e8(big5hkscs).

        Now I use both BIG5.gz and BIG5HKSCS.gz.
        BIG5HKSCS.gz(except 0xa140 - 0xa3bf , 0xa440 - 0xc67e , 0xc940 - 0xf9d5)
        is used only for HKSCS.

        Appropriate mapping table is selected by locale info(zh_TW or zh_HK) for the
        region shared with BIG5.gz and BIG5HKSCS.

        Then , I think you can show unstandard big5 characters under anti alias mode.

        Please cvs checkout and test it:)

        Best Regards.
        
--
kiken
j00...@ip...

Re: [Mlterm-dev-en] About some Trad-Chinese characters.

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

	Hi,

	Subject: Re: [Mlterm-dev-en] About some Trad-Chinese characters.
	From: "Edward G.J. Lee" <ed...@ms...>
	Message-ID: <200...@da...>
	Date: Wed, 9 Jan 2002 22:56:30 +0800

>>         Well , big5 to ucs mapping table of mlterm (mkf/lib/table/mkf_big5_to_ucs4.table)
>>         confirms to ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5HKSCS.gz.
           ^^^^^^^^ conforms:)
>>         and u+7881 is mapped to 0xf9d6(big5) and u+88cf is mapped to 0xf9d8.
>>         But these big5 characters are regarded as HKSCS charset , so you cannot
>>         use these mappings without -E big5hkscs option.
>
>   This confuse me somewhat, in
>   ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5.gz
>   There had same maping for those "unstandard" chracters.

        Oh , sorry , I made a serious mistake.
        
        mlterm always regards all in 0x8140 - 0xa0fe , 0xc6a1 - 0xc8fe , 0xf9d6 - 0xfefe
        as hkscs character set when mapping between big5 and unicode in mkf_big5_ucs4.c
        so you cannot convert them to unicode under Big5(not big5hkscs) encoding.

        On the other hand , they are normally regarded as Big5 characters
        in mkf_big5_parser.c , which parses Big5 string , under Big5 encoding.

        That's why you can show them without anti alias , and cannot show with anti alias.

        I'll support unstandard characters in BIG5.gz.
        
>   The another problem is big5 Japanese characters are not the same maping in
>   BIG5.gz and BIG5HKSCS.gz. Such as U+F6F8 => 0xc6e8(big5), U3042 => 0xc6e8(big5hkscs).

        OK , I see.

--
kiken
j00...@ip...

Re: [Mlterm-dev-en] About some Trad-Chinese characters.

[Edward G.J. L. <ed...@ms...>]

Hi,

On Wed, Jan 09, 2002, Araki Ken wrote:
> >   I can display the extra traditional Chinese character(such as
> >   U+7881, U+88CF ...) when I use Arphic TTF(bsmi00lp.ttf). But
> >   if I use -A and use aafont setting:
> >
> >   ISO8859_1=AR PL Mingti2L Big5-iso8859-1;
> >   BIG5=AR PL Mingti2L Big5-iso10646-1;
> >
> >   then I cannot display those extra traditional Chinese characters.
> >
> >   I know it's not the Unicode standard, but I try to change the
> >   map table still cannot display.
> 
>         Well , big5 to ucs mapping table of mlterm (mkf/lib/table/mkf_big5_to_ucs4.table)
>         confirms to ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5HKSCS.gz.
>         and u+7881 is mapped to 0xf9d6(big5) and u+88cf is mapped to 0xf9d8.
>         But these big5 characters are regarded as HKSCS charset , so you cannot
>         use these mappings without -E big5hkscs option.

  This confuse me somewhat, in
  ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5.gz
  There had same maping for those "unstandard" chracters.

  Sorry, I didn't say clearly. I'm using big5 locale(not big5hkscs).
  I can display those extra characters even big5 Japanese charaters,
  but can not display it, when i use AA(-A). The another problem is big5
  Japanese characters are not the same maping in BIG5.gz and BIG5HKSCS.gz.
  Such as U+F6F8 => 0xc6e8(big5), U3042 => 0xc6e8(big5hkscs).

>         # FYI , IS_HKSCS_ONLY macro in mkf/lib/mkf_ucs4_big5.c is used in mkf_map_big5_to_ucs4
>         # to exclude "unstandard" big5 characters.
> 
>         But if you want another mapping table for u+7811 , u+88cf etc , please point it
>         to me.

  Thanks the hint. I can display those "unstandard" chinese characters now.
  I will try to figure out to display the big5 encoding Japanese characters.

> >   Sorry, I have a silly question, can we use big5-0 encoding when
> >   need AA function?
> 
>         "iso10646-1" is used for specifying a font encoding.
>         if your font(Arphic TTF?) is encoded by iso10646-1 , you cannot
>         specify big5-0 as an encoding.(this is the specification of Xft)
> 
>         And in addition , Xft accepts Unicode only.
>         so anyway you cannot avoid big5 => unicode mapping somewhere.

  Thanks, I forgot that Xft accepts Unicode only(Keith had been said
  that before).


-- 
Warm Regards,
Edward G.J. Lee

Re: [Mlterm-dev-en] About some Trad-Chinese characters.

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

	Hi,

	Subject: [Mlterm-dev-en] About some Trad-Chinese characters.
	From: "Edward G.J. Lee" <ed...@ms...>
	Message-ID: <200...@da...>
	Date: Wed, 9 Jan 2002 18:12:35 +0800

>   I can display the extra traditional Chinese character(such as
>   U+7881, U+88CF ...) when I use Arphic TTF(bsmi00lp.ttf). But
>   if I use -A and use aafont setting:
>
>   ISO8859_1=AR PL Mingti2L Big5-iso8859-1;
>   BIG5=AR PL Mingti2L Big5-iso10646-1;
>
>   then I cannot display those extra traditional Chinese characters.
>
>   I know it's not the Unicode standard, but I try to change the
>   map table still cannot display.

        Well , big5 to ucs mapping table of mlterm (mkf/lib/table/mkf_big5_to_ucs4.table)
        confirms to ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5HKSCS.gz.
        and u+7881 is mapped to 0xf9d6(big5) and u+88cf is mapped to 0xf9d8.
        But these big5 characters are regarded as HKSCS charset , so you cannot
        use these mappings without -E big5hkscs option.

        # FYI , IS_HKSCS_ONLY macro in mkf/lib/mkf_ucs4_big5.c is used in mkf_map_big5_to_ucs4
        # to exclude "unstandard" big5 characters.

        But if you want another mapping table for u+7811 , u+88cf etc , please point it
        to me.

>   Sorry, I have a silly question, can we use big5-0 encoding when
>   need AA function?

        "iso10646-1" is used for specifying a font encoding.
        if your font(Arphic TTF?) is encoded by iso10646-1 , you cannot
        specify big5-0 as an encoding.(this is the specification of Xft)

        And in addition , Xft accepts Unicode only.
        so anyway you cannot avoid big5 => unicode mapping somewhere.

--
kiken
j00...@ip...

[Mlterm-dev-en] About some Trad-Chinese characters.

[Edward G.J. L. <ed...@ms...>]

Greetings,

  I can display the extra traditional Chinese character(such as
  U+7881, U+88CF ...) when I use Arphic TTF(bsmi00lp.ttf). But
  if I use -A and use aafont setting:

  ISO8859_1=AR PL Mingti2L Big5-iso8859-1;
  BIG5=AR PL Mingti2L Big5-iso10646-1;

  then I cannot display those extra traditional Chinese characters.

  I know it's not the Unicode standard, but I try to change the
  map table still cannot display.

  Sorry, I have a silly question, can we use big5-0 encoding when
  need AA function? or how can I change the map table to display
  those "unstandard" characters?

  Thanks in advanece.


-- 
Warm Regards,
Edward G.J. Lee

[Mlterm-dev-en] commit log [2002/01/09]

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

       Hi,

       I committed changes below.
       
* -r/--fade/fade_ratio option is added.
* infinite loop owing to malformed escape sequence like "ESC ] ;"
  can be escaped by pressing LF.(Minami Hirokazu san)

       -fade option is the same as aterm's one.

       this option specifies the brightness of background color when mlterm
       is focused out.

       Usage
       
       -r [0-100]
       --fade [0-100]

       or 
       
       fade_ratio = [0-100] (in ~/.mlterm/main)

--
kiken
j00...@ip...

Re: [Mlterm-dev-en] commit log [2002/01/08-2]

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

	Hi,

	Subject: Re: [Mlterm-dev-en] commit log [2002/01/08-2]
	From: Karl Koehler <ko...@or...>
	Message-ID: <Pin...@r5...>
	Date: Tue, 8 Jan 2002 16:51:38 +0100 (MEZ)

> Now I checked out mlterm from cvs , and what failed before .. works,
> that is, on an i686-linux system, configuring with --enable-fribidi,
> bidi works in an utf8-locale, with or without --enable-debug . :)
> I should have checked this earlier .. :|

        That's fine:)
        
        But didn't bidi on 2.1.2 work ?
        Hmmm... well , because cvs version works anyway , I won't mind it:)
        
> ( By the way, the date on the web-page should read 2002-1-2, not
>   2001/1/2 .)

        Oh , I didn't notice it. I fixed , thanks:)
	
--
kiken
j00...@ip...

Re: [Mlterm-dev-en] commit log [2002/01/08-2]

[Karl K. <ko...@or...>]

Hi,

>         I committed changes below.
[ .. ]

You asked about:
	mlterm -E utf8 -bi=false 
Well, that worked with 2.1.2. :) .
Now I checked out mlterm from cvs , and what failed before .. works,
that is, on an i686-linux system, configuring with --enable-fribidi,
bidi works in an utf8-locale, with or without --enable-debug . :)
I should have checked this earlier .. :|

( By the way, the date on the web-page should read 2002-1-2, not
  2001/1/2 .)

	Karl

[Mlterm-dev-en] commit log [2002/01/08-2]

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

	Hi,

        I committed changes below.
        
* fribidi 0.10.0(where FriBidiStrIndex is 32bit , not 16bit) is supported.
* selecting region policy is changed(character is selected after mouse
  pointer passing over it) , and some bug are fixed.

        I tested mlterm bidi feature with fribidi 0.9.0 and fribidi 0.10.0.
        I'm sorry but I don't still find what is the cause of reported
        problems :(

--
kiken
j00...@ip...

Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm

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

	Hi,

	Subject: Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm
	From: Karl Koehler <ko...@or...>
	Message-ID: <Pin...@r5...>
	Date: Mon, 7 Jan 2002 12:56:40 +0100 (MEZ)

> I don't know if this problem is fixed. The backtrace looks different, 
> that's all... :(

         Hmmm... I'm sorry but I don't know why mlterm dumps core.

         Please let me ask you some questions.

         1. Does mlterm -E utf8 -bi=false also dump core ?
         2. Does this problem happen without --enable-debug or --enable-fribidi option ?

         Best Regards.
	 
--
kiken
j00...@ip...

Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm

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

	Hi,

	Subject: Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm
	From: Noah Levitt <nl...@co...>
	Message-ID: <200...@co...>
	Date: Tue, 8 Jan 2002 01:30:44 -0500

> My ~/.mlterm/font is
> ISO10646_UCS2_1=-gnu-fixed-*-*-*-h-8-160-*-*-*-*-iso10646-1
> ISO10646_UCS2_1_BIWIDTH=-gnu-fixed-*-*-*-f-16-160-*-*-*-*-iso10646-1

        ~/.mlterm/font format is

CHARSET=[size],[font];

        so , please write as follows in ~/.mlterm/font.

ISO10646_UCS2_1=8,-gnu-fixed-medium-r-normal-h-8-160-75-75-c-80-iso10646-1;
ISO10646_UCS2_1_BIWIDTH=8,-gnu-fixed-medium-r-normal-f-16-160-75-75-c-80-iso10646-1;

        and

        $ mlterm -w 8 -E utf8

> I get a different stack trace:
> DEBUG: [ml_bidi()] visual order(29) of 0 is illegal.
>
> Program received signal SIGABRT, Aborted.
> 0x402e9971 in kill () from /lib/libc.so.6
> (gdb) bt
> #0  0x402e9971 in kill () from /lib/libc.so.6
> #1  0x402e9775 in raise () from /lib/libc.so.6
> #2  0x402eada3 in abort () from /lib/libc.so.6
> #3  0x08068183 in ml_bidi (order=0x80b1890, src=0x809d2d0, size=29)
>     at ml_bidi.c:99
> #4  0x0805ef1e in ml_imgline_render_bidi (line=0x809c8a8)
>     at ml_image_line.c:910
> #5  0x08051df4 in ml_image_render_bidi (image=0x8073030) at ml_image.c:1025
> #6  0x0805b896 in ml_term_screen_stop_vt100_cmd (termscr=0x8072f28)
>     at ml_term_screen.c:3860
> #7  0x08056354 in ml_parse_vt100_sequence (vt100_parser=0x80a8408)
>     at ml_vt100_parser.c:2426
> #8  0x0806510a in receive_next_event (term_man=0xbffff650)
>     at ml_term_manager.c:619
> #9  0x080669c9 in ml_term_manager_event_loop (term_man=0xbffff650)
>     at ml_term_manager.c:1523
> #10 0x0805fcf9 in main (argc=6, argv=0xbffff994) at main.c:44
> #11 0x402d75b0 in __libc_start_main () from /lib/libc.so.6

        This error means that fribidi_log2vis() returns strange values , but I
        don't still know why this happens...

        Would you please patch an attached file to src/ml_bidi.c , do

        $ mlterm -km utf8 -bi -w 8 2> log
        
        and send me the log file ?

        I want to know what happens around fribid_log2vis() ...

>>          uum ... "f-16" and "h-8" seems somewhat strange and designed only for xterm ,
>>          but is it preferable to support these styles ? > Kubota san
> I don't really know anything about fonts, but I was under
> the impression that these two fonts made sense as values for
> the ISO10646_UCS2_1 and ISO10646_UCS2_1_BIWIDTH parameters.
> (The "f" and "h" stand for full-width and half-width, I
> think.) I am curious as to what usual values for
> ISO10646_UCS2_1 and ISO10646_UCS2_1_BIWIDTH are. I also use
> these fonts in vim, as my "guifont" and "guifontwide".

        what i wrote is inadequate , sorry.

        XLFD font size value of CJK full width fonts(and some other Unicode fonts)
        is usually the same as the half width one.
        For example ,
	
-efont-biwidth-medium-r-normal--12-120-75-75-p-60-iso10646-1
                                ^^

        is full width font for 12 dot and

-efont-fixed-medium-r-normal--12-120-75-75-c-60-iso10646-1
                              ^^

        is half width font for 12 dot.

        "f-16" and "h-8" , both which I think are the same height , seem somewhat strange
        for me.

        That's why i wrote "is it preferable to support these styles?"  , which means
        whether "f-[size]" font shoule be searched for *automatically* or not.
        I am afraid it can have some secondary bad effects. (e.g. loading twice as
        large font as expected...)

        Of cource , specifying these font explicitly in ~/.mlterm/font like
        
ISO10646_UCS2_1_BIWIDTH=8,-gnu-fixed-medium-r-normal-f-16-160-75-75-c-80-iso10646-1;
ISO10646_UCS2_1=8,-gnu-fixed-medium-r-normal-h-8-160-75-75-c-80-iso10646-1;

        is completely ok:)

--
kiken
j00...@ip...

Index: ml_bidi.c
===================================================================
RCS file: /home/ken/cvsroot/mlterm/src/ml_bidi.c,v
retrieving revision 1.8
diff -u -r1.8 ml_bidi.c
--- ml_bidi.c	2002/01/07 00:57:35	1.8
+++ ml_bidi.c	2002/01/08 07:10:41
@@ -9,7 +9,7 @@
 #include  <kiklib/kik_mem.h>	/* alloca */
 
 
-#if  0
+#if  1
 #define  __DEBUG
 #endif
 
@@ -72,7 +72,14 @@
 			/* white space */
 			fri_src[counter] = 0x20 ;
 		}
+
+	#ifdef  __DEBUG
+		fprintf( stderr , "%.4x " , fri_src[counter]) ;
+	#endif
 	}
+#ifdef  __DEBUG
+	fprintf( stderr , "\n") ;
+#endif
 
 	/* initial state */
 	type = FRIBIDI_TYPE_LTR ;
@@ -83,7 +90,7 @@
 	printf( "visual order => ") ;
 	for( counter = 0 ; counter < size ; counter ++)
 	{
-		printf( "%.2d" , order[counter]) ;
+		printf( "%.2d " , order[counter]) ;
 	}
 	printf( "\n") ;
 #endif

Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm

[Noah L. <nl...@co...>]

Hello,

On Tue, Jan 08, 2002 at 10:40:21AM +0900, Araki Ken wrote:
> 
>         Thanks a lot , but I have completely no idea why it happens:(
> 
>         Well , would you tell me fribidi version you use , ./configure options
>         you build mlterm with , and show me your ~/.mlterm/main , ~/.mlterm/font ?

Sorry for not providing this information last time. I am
using fribidi 0.9.1. I compiled mlterm with
--enable-fribidi --enable-debug. My ~/.mlterm/font is
ISO10646_UCS2_1=-gnu-fixed-*-*-*-h-8-160-*-*-*-*-iso10646-1
ISO10646_UCS2_1_BIWIDTH=-gnu-fixed-*-*-*-f-16-160-*-*-*-*-iso10646-1
and I don't have a ~/.mlterm/main or any of the other
configuration files.

> 
>         At my hand,
>         
>         $ LC_CTYPE=en_US.UTF-8 mlterm -w 20 -bi
>         
>         works fine with -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
>         font on NetBSD 1.5 Y current and XFree86 4.1.0.
> 
>          Default font size range is 10 - 24 , and if you want to use 8 dot font ,
>          please do something like

My mistake, I didn't realize that number was what the font
size referred to. 

> 
>          $ mlterm -km utf8 -w 8 -fsrange=8-24

When I run this it uses a size 8 font, but not the one I
want, and I get a different stack trace:

DEBUG: [ml_bidi()] visual order(29) of 0 is illegal.

Program received signal SIGABRT, Aborted.
0x402e9971 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x402e9971 in kill () from /lib/libc.so.6
#1  0x402e9775 in raise () from /lib/libc.so.6
#2  0x402eada3 in abort () from /lib/libc.so.6
#3  0x08068183 in ml_bidi (order=0x80b1890, src=0x809d2d0, size=29)
    at ml_bidi.c:99
#4  0x0805ef1e in ml_imgline_render_bidi (line=0x809c8a8)
    at ml_image_line.c:910
#5  0x08051df4 in ml_image_render_bidi (image=0x8073030) at ml_image.c:1025
#6  0x0805b896 in ml_term_screen_stop_vt100_cmd (termscr=0x8072f28)
    at ml_term_screen.c:3860
#7  0x08056354 in ml_parse_vt100_sequence (vt100_parser=0x80a8408)
    at ml_vt100_parser.c:2426
#8  0x0806510a in receive_next_event (term_man=0xbffff650)
    at ml_term_manager.c:619
#9  0x080669c9 in ml_term_manager_event_loop (term_man=0xbffff650)
    at ml_term_manager.c:1523
#10 0x0805fcf9 in main (argc=6, argv=0xbffff994) at main.c:44
#11 0x402d75b0 in __libc_start_main () from /lib/libc.so.6

> 
>          10 - 24 seems so narrow that I'll set 6 - 30 as font size range by default.
> 
>          BTW , I didn't know such XLFD exist as
> 
>          -gnu-fixed-medium-r-normal-f-16-160-75-75-c-80-iso10646-1
>                                     ^^^^
>          -gnu-fixed-medium-r-normal-h-8-160-75-75-c-80-iso10646-1
>                                     ^^^
>          
>          uum ... "f-16" and "h-8" seems somewhat strange and designed only for xterm ,
>          but is it preferable to support these styles ? > Kubota san

I don't really know anything about fonts, but I was under
the impression that these two fonts made sense as values for
the ISO10646_UCS2_1 and ISO10646_UCS2_1_BIWIDTH parameters.
(The "f" and "h" stand for full-width and half-width, I
think.) I am curious as to what usual values for
ISO10646_UCS2_1 and ISO10646_UCS2_1_BIWIDTH are. I also use
these fonts in vim, as my "guifont" and "guifontwide".

Thanks a lot for your help!

Noah

Re: [Mlterm-dev-en] LOCALE problems

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

Hi,

At Mon, 07 Jan 2002 16:00:07 -0800,
Scott Jonathan wrote:

> Yes, I had it installed, but somehow it had not bothered to ask me which 
> locales to install.;P 

Strange... It may be because of Debconf priority configuration....

> I have done what you asked, and received a problem after. Here is the 
> output from "man man":

"man" is a bit difficult.  Before investigating "man", please check
"locale".  Please type "locale" and read the output.  My Debian Sid
box shows:

LANG=ja_JP.eucJP
LC_CTYPE="ja_JP.eucJP"
LC_NUMERIC="ja_JP.eucJP"
LC_TIME="ja_JP.eucJP"
LC_COLLATE="ja_JP.eucJP"
LC_MONETARY="ja_JP.eucJP"
LC_MESSAGES="ja_JP.eucJP"
LC_PAPER="ja_JP.eucJP"
LC_NAME="ja_JP.eucJP"
LC_ADDRESS="ja_JP.eucJP"
LC_TELEPHONE="ja_JP.eucJP"
LC_MEASUREMENT="ja_JP.eucJP"
LC_IDENTIFICATION="ja_JP.eucJP"
LC_ALL=

Please check this.  Then type "ls foobar" where file "foobar" is not
available.  The message should be displayed in Japanese.  I think
further locale problems which are not related to mlterm should be
asked in debian-i18n, debian-devel, or debian-users mailing lists,
if you are subscribing them.

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

Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm

[Karl K. <ko...@or...>]

Hmm... 
[ .. ]
>         You didn't do anything wrong , I think , and I found a suspicious and very
>         critical bug around kik_list.h
> 
>         Isn't this problem fixed by an attached patch ?
I don't know if this problem is fixed. The backtrace looks different, 
that's all... :(

[...]
WARN: [get_font_intern()] font for attr 151a0 was cached.

Program received signal SIGSEGV, Segmentation fault.
0x403228c2 in chunk_alloc () from /lib/libc.so.6
(gdb) where

#0  0x403228c2 in chunk_alloc () from /lib/libc.so.6
#1  0x40321f64 in malloc () from /lib/libc.so.6
#2  0x401413be in kik_mem_malloc (size=8, file=0x8069f2b "ml_char.c", 
    line=105, func=0x8069f20 "ml_str_new")  at kik_mem.c:105
#3  0x0804ff11 in ml_str_new (size=1) at ml_char.c:105
#4  0x0805f7d1 in ml_imgline_init (line=0x809e078, num_of_chars=1) 
    at ml_image_line.c:40
#5  0x0805f818 in ml_imgline_clone (clone=0x809e078, orig=0x80ab760, 
    num_of_chars=1) at ml_image_line.c:61
#6  0x08054a23 in ml_log_add (logs=0x8085d08, line=0x80ab760) 
    at ml_logs.c:224
#7  0x08057e95 in scroll_upward_region (image=0x8085bf8, boundary_beg=0, 
    boundary_end=53, size=1)
    at ml_image_scroll.c:142
#8  0x0805834e in ml_imgscrl_scroll_upward (image=0x8085bf8, size=1) 
    at ml_image_scroll.c:369
#9  0x0805374c in ml_image_scroll_upward (image=0x8085bf8, size=1) 
    at ml_image.c:1613
#10 0x08053fc0 in ml_cursor_go_downward (image=0x8085bf8, flag=6) 
    at ml_image.c:2077
#11 0x0805c8de in ml_term_screen_line_feed (termscr=0x8085af0) 
    at ml_term_screen.c:3754
#12 0x08055895 in parse_vt100_escape_sequence (vt100_parser=0x809ee88) 
    at ml_vt100_parser.c:1848
#13 0x08057079 in ml_parse_vt100_sequence (vt100_parser=0x809ee88) 
    at ml_vt100_parser.c:2379
#14 0x080661c2 in receive_next_event (term_man=0xbffff164) 
    at ml_term_manager.c:617
#15 0x08067af9 in ml_term_manager_event_loop (term_man=0xbffff164) 
    at ml_term_manager.c:1473
#16 0x08060d8f in main (argc=4, argv=0xbffff494) at main.c:44
#17 0x402cb7ee in __libc_start_main () from /lib/libc.so.6
(gdb) 

[Mlterm-dev-en] commit log [2002/01/08]

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

       Hi,

       I committed changes below.

* mlterm with --enable-debug option can dump core owing to failure of 
  list operations. fixed. (thanks to Karl Koehler)
* ISCII / Bidi codes are more shared.
* mlterm.spec is updated (thanks to Kiyoshi Nishizawa san)
* ISCII characters in backscroll logs cannot be selected(and copyed) correctly.
  fixed.
* Window is not resized when font size is changed. fixed.
* -g option accepts minus x/y position.
* vertical tab sometimes fails. fixed.(thanks to nekoie san)
* default font size range is 6 - 30.

--
kiken
j00...@ip...

Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm

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

	Hi,

	Subject: Re: [Mlterm-dev-en] Re: [I18n]Bidi on mlterm
	From: Noah Levitt <nl...@co...>
	Message-ID: <200...@co...>
	Date: Mon, 7 Jan 2002 17:00:40 -0500

> I checked mlterm out of cvs a couple of hours ago, and I'm
> having crash and other problems with bidi and with utf8
> generally, even after applying your patch. I'm using linux
> 2.4.8 and xfree86 3.3.6. When I start mlterm
> $ LANG=en_US.UTF-8 mlterm
> I get a blank window. The blank window happens with or
> without bidi. I open mlconfig and set the font size to 14
> (it starts at 17), and then it crashes:
>
(snip)
>
> On the other hand, if I specify the font size when I start
> mlterm:
> $ LANG=en_US.UTF-8 mlterm --fsrange=14-14
> then the window opens and I see a prompt. When I press a
> key, it crashes:
(snip)

        Thanks a lot , but I have completely no idea why it happens:(

        Well , would you tell me fribidi version you use , ./configure options
        you build mlterm with , and show me your ~/.mlterm/main , ~/.mlterm/font ?

        At my hand,
        
        $ LC_CTYPE=en_US.UTF-8 mlterm -w 20 -bi
        
        works fine with -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
        font on NetBSD 1.5 Y current and XFree86 4.1.0.

> When I run mlterm with bidi disabled, it works, but it seems
> to refuse to use the fonts I specify in ~/.mlterm/font.
> So, I copied those fonts to their own directory and tried this:
>
> $ ls -l
> -rw-r--r--    1 nlevitt  nlevitt    784156 Dec  9 22:37 unifontd.pcf.gz
> -rw-r--r--    1 nlevitt  nlevitt     74014 Dec  9 22:37 unifonts.pcf.gz
> $ mkfontdir
> $ cat fonts.dir 
> 2
> unifontd.pcf.gz -gnu-fixed-medium-r-normal-f-16-160-75-75-c-80-iso10646-1
> unifonts.pcf.gz -gnu-fixed-medium-r-normal-h-8-160-75-75-c-80-iso10646-1
> $ xset fp $PWD
> $ xset fp rehash
> $ LANG=en_US.UTF-8 mlterm --bi=false
> a font for displaying us ascii chars is not found.
>
> This is dvdeug's version of unifont, which I have used
> successfully with xterm-utf8. What's wrong here?

         Default font size range is 10 - 24 , and if you want to use 8 dot font ,
         please do something like

         $ mlterm -km utf8 -w 8 -fsrange=8-24

         10 - 24 seems so narrow that I'll set 6 - 30 as font size range by default.

         BTW , I didn't know such XLFD exist as

         -gnu-fixed-medium-r-normal-f-16-160-75-75-c-80-iso10646-1
                                    ^^^^
         -gnu-fixed-medium-r-normal-h-8-160-75-75-c-80-iso10646-1
                                    ^^^
         
         uum ... "f-16" and "h-8" seems somewhat strange and designed only for xterm ,
         but is it preferable to support these styles ? > Kubota san

--
kiken
j00...@ip...

Re: [Mlterm-dev-en] LOCALE problems

[Scott J. <jo...@ho...>]

Yes, I had it installed, but somehow it had not bothered to ask me which 
locales to install.;P 

I have done what you asked, and received a problem after. Here is the 
output from "man man":

man(1) 、ニ・ユ・ゥ。シ・゛・テ・ネ、キ、ニ、、、゛、ケ。」、キ、ミ、鬢ッ、ェツヤ、チ、ッ、タ、オ、、...
invalid charset name
man: ・ウ・゛・ノ、マ・ケ・ニ。シ・ソ・ケ 256 、ヌスェホサ、キ、゛、キ、ソ: (echo '.ll 11.8i'; 
/usr/bin/zsoelim /tmp/zmang0FE1Y) | /usr/bin/tbl | /usr/bin/nroff -mandoc 
-Tnippon | less

Input is working, Output is not.:(

Any and all help is appreciated!:)

Jonathan Scott


>From: Tomohiro KUBOTA <tk...@ri...>
>To: "Scott Jonathan" <jo...@ho...>
>CC: mlt...@li...
>Subject: Re: [Mlterm-dev-en] LOCALE problems
>Date: Mon, 07 Jan 2002 19:23:07 +0900
>
>Hi,
>
>At Sun, 06 Jan 2002 17:01:27 -0800,
>Scott Jonathan wrote:
>
> > I recently did an upgrade from Debain Potato 2.2 to Debian Woody 3.0. 
Now
> > my locale settings are all in disarray it seems. Could someone point me 
to
> > information on how to get it back to normal?
>
>I think you have installed "locales" package.  When you installed it,
>didn't you asked about the installing locales?  If you checked
>"ja_JP.EUC-JP EUC-JP", you will have ja_JP.eucJP locale.
>
>If you have not installed the package, please install it.  Otherwise,
>try "dpkg-reconfigure locales" and you will be asked which locales to
>be installed.
>
>---
>久保田智広 Tomohiro KUBOTA <ku...@de...>
>http://www.debian.or.jp/~kubota/
>"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/
>
>_______________________________________________
>Mlterm-dev-en mailing list
>Mlt...@li...
>https://lists.sourceforge.net/lists/listinfo/mlterm-dev-en




_________________________________________________________________
大人気の会話ツール MSN メッセンジャーのダウンロードはこちら 
http://messenger.msn.co.jp/