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

[Mlterm-dev-en] commig log , BIG5 copy&paste

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

        I committed changes below.

* prefer_utf8_selection and xct_process_mode options are removed , and copy_paste_via_ucs
  option is added.
* BIG5HKSCS is separated into BIG5 and HKSCS.
* memory leaks when copy&paste combined chars. fixed.
* illegal chars based on ISO2022 are accepted if at all possible in ISO2022-based encodings.
* ISO2022 parser doesn't parse correctly when sequence is splited. fixed.

        For the 4th item above , I changed many sources under mkf/ , so there may
        be still some critical bugs.

        
        BTW , I found I could copy and paste Big5 text from mlterm to rxvt
        without --big5bug option , though my XFree86 4.1.0 is buggy around Big5 CTEXT.

        I tested and the result is like this.
        
        If "BIG5-0" is used after "\x1b\x25\x2f\x32..." in CTEXT , rxvt doesn't accept
        correct Big5 CTEXT , but accepts wrong Big5 CTEXT.
        If "big5-0" is used after "\x1b\x25\x2f\x32..." is used in CTEXT , rxvt doesn't
        accept wrong Big5 CTEXT , but accepts correct Big5 CTEXT.

        # this is another matter , but mlterm in cvs after 20011215 detects buggy
        # sequence automatically and copy&paste from rxvt to mlterm works without
        # --big5bug option. I forgot to add it to ChangeLog , sorry.

        Would you please start mlterm as follows

        $ LC_CTYPE=zh_TW.Big5 mlterm -km big5 --big5bug=false

        and copy and paste from mlterm to rxvt.

        if it is ok , I'll remove --big5bug option.

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

Re: [Mlterm-dev-en] commit log , and Big5HKSCS etc.

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

	Hi,

	Subject: Re: [Mlterm-dev-en] commit log , and Big5HKSCS etc.
	From: "Edward G.J. Lee" <ed...@ms...>
	Message-ID: <200...@da...>
	Date: Mon, 17 Dec 2001 19:33:43 +0800

>   I'm sorry reply so late. I confirm the author of Big5 charmap, here
>   is his comment.

        Thanks a lot:)
        
        I finally decided that characters mapped in PUA should be available.

        Next , it seems that Big5HKSCS should be separated into Big5 and HKSCS,
        doesn't it.
        I intend to use different fonts for Big5(-*-big5-0,-*-big5.eten-0) and
        HKSCS(-*-big5hkscs-0).

>   And I also mail to Anthony Fok, maybe he will kindly to comment
>   something.

        I'm looking forward to his comment:)

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

Re: [Mlterm-dev-en] commit log , and Big5HKSCS etc.

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

Hi,

  I'm sorry reply so late. I confirm the author of Big5 charmap, here
  is his comment.

  And I also mail to Anthony Fok, maybe he will kindly to comment
  something.


=== the comment of T.H. Hsieh ===
: * UTF8 selection is received as it is.                                        
:                                                                               
:         I replaced BIG5 <=> UCS table based on                                
:         http://www.unicode.org/Public/MAPPINGS/OTHERS/BIG5.txt                
:         with the new one base on                                              
:         ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5HKSCS.gz.           
:                                                                               
:         I found some characters(in C6A1-C8FE as well as HKSCS) are mapped to  
: +UNICODE                                                                      
:         PUA in it. I don't know whether it is ok or not and why it is like    
+that                                                                           
: +(especially                                                                  
:         those in C6A1-C8FE) , but I decided to include them anyway.           
:         Is it preferable to ingore PUA mapped characters ?                    

These C6A1-C8FE characters are called "Eten extension". Historically
these mapping comes from the old Chinese system running on MS-DOS
plateform. Its name is called "Eten Chinese system". Because in that
old days only that system is available, so most of people in Taiwan
are comfortable with its implimentation. The "Eten extension" defines
a lot of symbols and rarely used characters. Since so many people are
comfortable with it, so in the recently days many companies and/or
orgnizations in Taiwan who want to implement the mapping from Big5
to other encodings (say, Unicode), they all want to take these "Eten
extension" into consideration. For example, the Arphic Tech. CO., LTD.
maps these characters to the PUA of Unicode. Since these extra symbols
and characters are not found in the Unicode definition, but they should
be there for compatibility, so they do this mapping.

Forthermore, in glibc-2.2, the BIG5 encoding definition is also adjusted
to include the "Eten extension" and follows the implementation of Arphic
Tech. Co., LTD. Similarly for BIG5HKSCS for Hong Kong. Such extension
is also available in XFree86-4.X. So, I suggest that this extension should
be also available in mlterm.

:         Then , I implemented Big5HKSCS support , too. (just still prototype)  
:         mlterm doesn't regard Big5HKSCS as supplement of Big5 but as a new    
: +character set                                                                
:         including Big5 , and assumes that a font whose XLFD encoding name is  
: +"big5-0"                                                                     
:         or "big5hkscs-0" should include both Big5 and HKSCS , but I don't know
: +if
:        these are ok or not.                                                   
:                                                                               
:        Please tell me the right way around them.                              

The Big5 FontSet now we use is:

        -*-iso8859-1, -*-big5-0

For the Big5HKSCS, according to Debian's patching (maybe also available
in the new comming XFree86) is

        -*-iso8859-1, -*-big5-0, -*-big5hkscs-0

In my memory, they seems to separate the Hong Kong extension characters
out to a new font named -*-big5hkscs-0, such that the pure Big5 part is
compatible to the one Taiwan people using. For more details, you may
contact

        Anthony Fok <an...@th...>

He is responsible to the Debian Chinese porting and Hong Kong Chinese
patching.
=== The comment of T.H. Hsieh ===


On Sat, Dec 15, 2001, Araki Ken wrote:
> 
>         I committed changes below.
> 
> * ESC H (set tab) ESC [ 0 g (clear tab) ESC [ 3 g (clear all tabs) are supported.
> * Big5HKSCS encoding/charset is supported.
> * US ASCII font is not changed when encoding is changed to ISO8859 variant or UTF8. fixed.
> * huge memory leaks when window is resized. fixed.
> * input text is received in order of XmbLookupString => XLookupString => Xutf8LookupString.
> * UTF8 selection is received as it is.
> 
>         I replaced BIG5 <=> UCS table based on
>         http://www.unicode.org/Public/MAPPINGS/OTHERS/BIG5.txt
>         with the new one base on
>         ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5HKSCS.gz.
> 
>         I found some characters(in C6A1-C8FE as well as HKSCS) are mapped to UNICODE
>         PUA in it. I don't know whether it is ok or not and why it is like that (especially
>         those in C6A1-C8FE) , but I decided to include them anyway.
>         Is it preferable to ingore PUA mapped characters ?
> 
>         Then , I implemented Big5HKSCS support , too. (just still prototype)
>         mlterm doesn't regard Big5HKSCS as supplement of Big5 but as a new character set
>         including Big5 , and assumes that a font whose XLFD encoding name is "big5-0"
>         or "big5hkscs-0" should include both Big5 and HKSCS , but I don't know if
>         these are ok or not.
>         
>         Please tell me the right way around them.
> 
>         Regard,
>         
> --
> kiken
> j00...@ip...
> 
> _______________________________________________
> Mlterm-dev-en mailing list
> Mlt...@li...
> https://lists.sourceforge.net/lists/listinfo/mlterm-dev-en

-- 
Warm Regards,
Edward G.J. Lee¡]§õªG¥¿¡^

[Mlterm-dev-en] commit log

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

        I committed changes below.

* prefer_utf8_selection includes auto_detect_utf8_selection.
  that is , true/false/auto can be used as value.
* conv_to_generic_iso2022 and pre_conv_xct_to_ucs options are obsoleted.
* xct_process_mode(-c/--xct) option is added.
  this accepts ucs , raw or normal value.
* new "copy&paste" tab is added to mlconfig
* --ucshater => --ucs2other
  --ucslover => --all2ucs

        Regard,
--
kiken
j00...@ip...

[Mlterm-dev-en] commit log

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

        I committed changes below.

* prefer_utf8_selection (-U/--utf8sel) , auto_detect_utf8_selection (-o/--autoutf8)
  options are added.
* when window resized , font changed or encoding changed , screen may not be redrawn
  or cursor position may be strange. fixed.

        if prefer_utf8_selection option is true , mlterm prefers utf8 to ctext 
        in selection with other X applications.
        otherwise , if auto_detect_utf8_selection is true and tty encoding is
        a subset of UTF8 (e.g. eucJP , eucKR ...) , mlterm works the same as the
        case prefer_utf8_selection option is true.
  
        Regard,

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

[Mlterm-dev-en] commit log , and Big5HKSCS etc.

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

        I committed changes below.

* ESC H (set tab) ESC [ 0 g (clear tab) ESC [ 3 g (clear all tabs) are supported.
* Big5HKSCS encoding/charset is supported.
* US ASCII font is not changed when encoding is changed to ISO8859 variant or UTF8. fixed.
* huge memory leaks when window is resized. fixed.
* input text is received in order of XmbLookupString => XLookupString => Xutf8LookupString.
* UTF8 selection is received as it is.

        I replaced BIG5 <=> UCS table based on
        http://www.unicode.org/Public/MAPPINGS/OTHERS/BIG5.txt
        with the new one base on
        ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5HKSCS.gz.

        I found some characters(in C6A1-C8FE as well as HKSCS) are mapped to UNICODE
        PUA in it. I don't know whether it is ok or not and why it is like that (especially
        those in C6A1-C8FE) , but I decided to include them anyway.
        Is it preferable to ingore PUA mapped characters ?

        Then , I implemented Big5HKSCS support , too. (just still prototype)
        mlterm doesn't regard Big5HKSCS as supplement of Big5 but as a new character set
        including Big5 , and assumes that a font whose XLFD encoding name is "big5-0"
        or "big5hkscs-0" should include both Big5 and HKSCS , but I don't know if
        these are ok or not.
        
        Please tell me the right way around them.

        Regard,
        
--
kiken
j00...@ip...

[Mlterm-dev-en] commit log

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

        Hi,

        I committed chanages below.

* mlconfig is replaced by the new one designed by Kubota Tomohiro san(thanks)
* mlconfig works asynchronous.
* documentation for big5_buggy option is added.
* memory leaks when pre_conv_xct_to_ucs option is changed more than twice. fixed.

        Regard,

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

Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

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

        Hi,

	Subject: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)
	From: "Edward G.J. Lee" <ed...@ms...>
	Message-ID: <200...@da...>
	Date: Wed, 12 Dec 2001 11:47:06 +0800

>   But when I use Tcl/Tk APP will not
>   do the cut&paste from/to mlterm even English text.

        I understand this reason.
        This is because mlterm ignores XA_STRING property which Tcl/Tk sends to copy
        and paste text.
        
        I fixed it and now I can copy and paste at least English text.
        
        Please cvs checkout and test it.

        BTW , Tcl/Tk-8.3 I use doesn't support CTEXT , so I don't know whether mlterm
        can copy and paste CTEXT with Tcl/Tk.

--- commit log.
* mlterm can core dump in kik_locale_init(). fixed.
* XA_STRING property is supported in copy and paste.
* cursor-control characters inside ESC sequences are partially supported.
  (Thanks to Minami Hirokazu san)
  
--
kiken
j00...@ip...

Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

[<th...@li...>]

: >         Hi,
: > 
: >       Subject: Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and
: +XIM(mlterm-cvs)
: >       From: Araki Ken <j00...@ip...>
: >       Message-ID: <200...@pd...>
: >       Date: 13 Dec 2001 09:45:08 +0900
: >         
: >         I commited fixes to use XRegisterIMInstantiateCallback.
: >         there may be still some bugs , but it seems to work fine with
+kinput2
: +, skkinput
: >         and ami at hand.
: 
:   xcin is Ok too. Thanks. :)

Yes, xcin is OK :-))

Just one information: The problem of rxvt:

: Finally, I should comment that although rxvt-2.7.8 has a similar
: problem, as mentioned by Edward G.J. Lee, but the reason is different.
: RXVT now completely follows the X11R6 XIM standard, i.e., it calls
: XRegisterIMInstantiateCallback(). The reason that xcin should start
: before rxvt is that otherwise, rxvt will silently turn off any possibility
: to connect to any XIM servers. It tries to search and connect to any 
: valid XIM server when it starts. If it falses, then turn off it. I my
: point of view, I don't think this is necessary to "try to search and   
: connect". I think just leave this job to Xlib then everything is OK.

is also fixed by the rxvt developer: Geoff Wing <gc...@rx...>.
The patch is attached in the end of the mail.

Best Regards,
  
T.H.Hsieh

Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

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

        Hi,

	Subject: Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)
	From: Araki Ken <j00...@ip...>
	Message-ID: <200...@pd...>
	Date: 13 Dec 2001 09:45:08 +0900
        
        I commited fixes to use XRegisterIMInstantiateCallback.
        there may be still some bugs , but it seems to work fine with kinput2 , skkinput
        and ami at hand.

        please checkout CVS repository and test it.

        following is the changelog.

* memory leaks around encoding parsers. fixed.
* XIM codes are rewritten. XRegisterIMInstantiateCallback() is used.

        Regards,

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

Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

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

        Hi,

	Subject: Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)
	From: Araki Ken <j00...@ip...>
	Message-ID: <7z4rmwx80w.fsf@totally-fudged-out-message-id>
	Date: 13 Dec 2001 09:45:08 +0900

>         But the idea above is just my own decision , and if you all say
>         XRegisterIMInstantiateCallback() should be used and is necessary ,
>         I'll do it from now and wait for a while , please.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          I'll do it from now. Please wait for a while.

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

Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

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

	Hi,

	Subject: Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)
	From: th...@li...
	Message-ID: <200...@li...>
	Date: Wed, 12 Dec 2001 23:33:22 +0800

> This should not happen for a standard X11R6 XIM client. I searched
> the whole source of mlterm, but I cannot find the function call of
> XRegisterIMInstantiateCallback() anywhere. This is the standard
> call of X11R6 to provide the ability of the XIM client to connect
> to the XIM server once it is available now.

        Yes , but I don't use it now for the reason below.

> However, I note that since mlterm has the ability to choose/change
> the XIM server in *run time*. So I am not sure that if this is the
> reason that you don't want to use XRegisterIMInstantiateCallback()
> call in mlterm, or you just missed this point. 

        It is my decision not to use XRegisterIMInstantiateCallback() ,
        this is because it is quite troublesome to process not only Open / Close
        but Register / Unregister for switching multiple XIMs.
        (that is , I cut corner:))

        Of cource , it is possible , but I thought XRegisterIMInstantiateCallback()
        may not be necessary , since even if XIM is killed and mlterm purges it ,
        pressing XIM_OPEN keys after XIM is revived enables you to use it again anyway.

        But the idea above is just my own decision , and if you all say
        XRegisterIMInstantiateCallback() should be used and is necessary ,
        I'll do it from now and wait for a while , please.

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

Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

[<th...@li...>]

Firstly I should say sorry that I haven't joined the mlterm
mailing list:

mlt...@li...

Although I send this mail to this mailing list, but it may be
rejected. So, if someone finds that this mail might be useful,
please help me to deliver it to the mailing list. :-))

: >   1. xcin start before mlterm:
: > 
: >      if I kill xcin under mlterm then mlterm will hang. It
: >      seems that mlterm's XSetICValues() xcin cannot return it,
: >      so mlterm hang there.
: 
:         what I think happens is as follows.
: 
:         If you kill xcin on mlterm , the destroy event happens while you are
: +inputting
:         something from keyboard(that is , while mlterm is receiving keyboard
: +events
:         with *XmbLookupString*) , so mlterm hangs up in XmbLookupString before
: +receiving
:         the destroy event.
: 
:         I tried it on rxvt and the same problem happened.
: 
:         I think this problem cannot be avoided unless XLookupString is always
: +used in
:         receiving us ascii text.
: 
:         But if XLookupString is used like that , it will cause another problem
: +and
:         I don't want to do it.
: 
:         If you want to kill xcin on mlterm , please do it after selecting
: +"unused" as
:         Input Method on mlconfig or pressing keys assigned for XIM_CLOSE (,
: +which stop
:         using XIM).

I have checked out the newest source from the mlterm CVS (date:
2001/12/12 22:30). I tested it with xcin. There is no such problem
described above, i.e., I can safely kill xcin when the mlterm is
the foreground window. Maybe this problem is already fixed :-))

: >   2. no xcin start before mlterm:
: > 
: >      I start xcin after mlterm, but mlterm cannot connect
: >      to xcin even has the proper XMODIFIERS. It seems mlterm
: >      detect no XIM server then forget it even start XIM server
: >      after mlterm start. Tung-Han Hsieh had found same problem
: >      from rxvt-2.7.8.
:         
:         This is my mistake. Please test an attached patch.

The source I checked out from the CVS already contains your patch.
However, my test showed that xcin cannot start after mlterm is running,
otherwise mlterm cannot accept the input from xcin. Even worse, if in
the beginning I start xcin and then mlterm (mlterm can accept the input
from xcin), and then I kill xcin, and restart xcin again, mlterm still
cannot accept the input from xcin.

This should not happen for a standard X11R6 XIM client. I searched
the whole source of mlterm, but I cannot find the function call of
XRegisterIMInstantiateCallback() anywhere. This is the standard
call of X11R6 to provide the ability of the XIM client to connect
to the XIM server once it is available now.

The standard way is like this: the XIM client does not try to open
the connection to the XIM server directly (i.e., call the XOpenIM()).
Instead, it should call XRegisterIMInstantiateCallback() to register
its own XIM connection function. Then it leaves the actually connection
to the Xlib. If Xlib found that there is a valid XIM server running,
it will call the registered connection function provided by the XIM
client and establish the XIM connection. Because Xlib is the first
place to know that if the XIM server is now running or not, so we let
it to decide if this is the time to establish the connection or not.

However, I note that since mlterm has the ability to choose/change
the XIM server in *run time*. So I am not sure that if this is the
reason that you don't want to use XRegisterIMInstantiateCallback()
call in mlterm, or you just missed this point. If you need a simple
example about the usage of XRegisterIMInstantiateCallback(), I could
provide one.

Finally, I should comment that although rxvt-2.7.8 has a similar
problem, as mentioned by Edward G.J. Lee, but the reason is different.
RXVT now completely follows the X11R6 XIM standard, i.e., it calls
XRegisterIMInstantiateCallback(). The reason that xcin should start
before rxvt is that otherwise, rxvt will silently turn off any possibility
to connect to any XIM servers. It tries to search and connect to any
valid XIM server when it starts. If it falses, then turn off it. I my
point of view, I don't think this is necessary to "try to search and
connect". I think just leave this job to Xlib then everything is OK.


Best Regards,

T.H.Hsieh

[Mlterm-dev-en] commit log

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

        Hi,
        I committed changes below.

* garbages can be left on screen in scrolling. fixed.
* The implementation of VT102 INS/DEL lines functions was buggy. fixed.
* If XMODIFIERS's xim is executed after mlterm started , mlterm won't use it
  even if XIM_OPEN key is pressed. fixed.

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

Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

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

        Hi,

	Subject: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)
	From: "Edward G.J. Lee" <ed...@ms...>
	Message-ID: <200...@da...>
	Date: Wed, 12 Dec 2001 11:47:06 +0800

>   when I use Tcl/Tk APP will not do the cut&paste from/to mlterm
>   even English text.

        I don't still check this problem , sorry.
        I'll do it later.

>   Another thing is about XIM server(I use XCIN). There sre
>   two problems:
>   1. xcin start before mlterm:
> 
>      if I kill xcin under mlterm then mlterm will hang. It
>      seems that mlterm's XSetICValues() xcin cannot return it,
>      so mlterm hang there.

        what I think happens is as follows.

        If you kill xcin on mlterm , the destroy event happens while you are inputting
        something from keyboard(that is , while mlterm is receiving keyboard events
        with *XmbLookupString*) , so mlterm hangs up in XmbLookupString before receiving
        the destroy event.

        I tried it on rxvt and the same problem happened.

        I think this problem cannot be avoided unless XLookupString is always used in
        receiving us ascii text.

        But if XLookupString is used like that , it will cause another problem and
        I don't want to do it.

        If you want to kill xcin on mlterm , please do it after selecting "unused" as
        Input Method on mlconfig or pressing keys assigned for XIM_CLOSE (, which stop
        using XIM).
        
>   2. no xcin start before mlterm:
> 
>      I start xcin after mlterm, but mlterm cannot connect
>      to xcin even has the proper XMODIFIERS. It seems mlterm
>      detect no XIM server then forget it even start XIM server
>      after mlterm start. Tung-Han Hsieh had found same problem
>      from rxvt-2.7.8.

        This is my mistake. Please test an attached patch.

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

diff -u -r -N mlterm/src/ml_xic.c mlterm.new/src/ml_xic.c
--- mlterm/src/ml_xic.c	Mon Dec 10 12:31:35 2001
+++ mlterm.new/src/ml_xic.c	Wed Dec 12 15:05:06 2001
@@ -289,9 +289,7 @@
 
 	if( win->xic)
 	{
-		/* already activated */
-		
-		return  0 ;
+		ml_xic_deactivate( win) ;
 	}
 	
 	if( strcmp( xim_name , "unused") == 0)

[Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

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

Hi,

  I try the CVS version, but still have problem of Big5
  text cut&paste(aterm,Tcl/Tk vs. mlterm).

  aterm don't have CTEXT ability, but rxvt <=> aterm is
  OK.(aterm-0.4.2, rxvt-2.7.8). Kadu san has the patch
  for aterm's CTEXT. But when I use Tcl/Tk APP will not
  do the cut&paste from/to mlterm even English text.
  * http://www.bb.wakwak.com/~akk/kadu/index.html

  rxvt vs. mlterm can do cut&paste under -big5bug argument
  now. Thanks.:)

  Another thing is about XIM server(I use XCIN). There sre
  two problems:

  1. xcin start before mlterm:

     if I kill xcin under mlterm then mlterm will hang. It
     seems that mlterm's XSetICValues() xcin cannot return it,
     so mlterm hang there.

  2. no xcin start before mlterm:

     I start xcin after mlterm, but mlterm cannot connect
     to xcin even has the proper XMODIFIERS. It seems mlterm
     detect no XIM server then forget it even start XIM server
     after mlterm start. Tung-Han Hsieh had found same problem
     from rxvt-2.7.8.
     * http://www.linux.org.tw/pipermail/xcin/2001-December/003387.html


thanks.:-)
-- 
Warm Regards,
Edward G.J. Lee

[Mlterm-dev-en] commit log

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

        I committed changes below.

* the number of redrawing in bidi mode is reduced.
* ml_image modules is cleaned up.
* INDEX/RINDEX vt100 implementation was wrong. fixed.
* ESC # , ESC E , ESC [ ? l 3 , ESC [ ? l 5 , ESC [ ? h 3 , ESC [ ? h 5 are supported.
* "ESC [ ; ..." is regarded as "ESC [ 0 ; ..."
* buffer overflow in parsing ESC [ ... sequence is fixed.
* the size of mlconfig window is shrunk.

        Minami Hirokazu san pointed to me that mlterm didn't pass
        vttest(http://dickey.his.com/vttest/vttest.html) , so I fixed most of
        the problems except tab setting/resetting function.

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

[Mlterm-dev-en] cut&paste Big5 and UCS - Big5 convertion.

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

        Hi,

        I fixed Big5 copy and paste problem.
        Please checkout current CVS repository and test it.

--- commit log
[20011210]
* 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.

        BTW I found XmbTextListToTextProperty() generates strange CTEXT
        sequence when TextList contains Big5.
        I asked it to Kubota Tomohiro san , and he pointed to me XFree86
        ChangeLog below.
        
> > 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).

        XFree86 4.1.0 or before all have these bugs.
        
        Even if these bugs exist , applications which use XmbTextListToTextProperty()
        can communicate with each other in Big5 , but the problem is that mlterm
        doesn't use Xlib i18n functions.
        
        I don't know which way is preferable , but at the present time I avoid this
        problem by adding a new option.
        if your XFree86 is buggy , start mlterm as follows

        $ mlterm --big5bug

        or add
        
        big5_buggy = true

        in ~/.mlterm/main , and you can copy and paste Big5 characters on buggy XFree86.


        In addition , mlterm has another Big5 problem.
        mlterm now uses BIG5.TXT which was in http://www.unicode.org/Public/MAPPINGS/EASTASIA/OTHER/
        (and obsoleted) to convert between BIG5 and UCS.

        But according to Sakamoto Hironori san ,

        ftp://xcin.linux.org.tw/pub/xcin/i18n/charset/BIG5.gz

        should be used as a convertion table , so I will do so.

        
        Are there any problems ?
        I would like native speakers' comments about these.

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

[Mlterm-dev-en] character shaping

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

        Hi,

        I committed changes to CVS repository.
        commit log is as follows.
        
* 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.)
        
        I implemented Arabic character shaping.
        Thus arabic characters can be shown on mlterm like xterm , I think.
        please test it.
        
        some more bugs around Bidi were found after mlterm-rtl3 , and fixed.

        Kubota Tomohiro san contributed mlterm icons(mlterm-NNxNN.xpm), which
        are in doc/icon/ directory :) Thanks a lot.
        
--
kiken
j00...@ip...

Re: [Mlterm-dev-en] cut&paste problem

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

Hello KUBOTA san,

Thanks for your explanation, I have to do some homeworks.:)

I hope you don't mind, I Cc to CLE-devel and Debian-Chinese
list, maybe they will be interested about this discussion.
And maybe some people can comment my point of view(I don't
have too much knowledge about this topic and GB/GBK).


On Fri, Dec 07, 2001, Tomohiro KUBOTA wrote:
> Hello,
> 
> At 07 Dec 2001 02:16:41 +0900,
> Araki Ken wrote:
> 
> > rxvt/aterm copy and paste Big5 characters with ISO2022 ESC % / ... sequence ,
> > but mlterm doesn't still implement it.
> > At the present time mlterm converts Big5 to UTF-8 or CNS11643 in sending or
> > receiving characters with other X applications.
> 
> I think converting Big5 into CNS11643 is a bad idea because it is
> not popular in Taiwan.

Big5 encoding(charset) is the popular use in Taiwan, but
has some problem. Big5 has 13094+ characters only. It
means some daily use characters are absent, so if mlterm
can support CNS11643, it will be useful for some people.

CNS11643 is the Taiwan goverment standard. And library,
they use CCCII(75684 characters), all because not enough
characters in Big5.

> When sending a CTEXT which contains Big5 characters:
>  - use "XFree86 Big5" way.
> 
> When receiving a CTEXT which contains Big5 characters:
>  - accept "XFree86 Big5" and "Emacs Big5" ways.
> 
> When sending a CTEXT which contains CNS11643 characters:
>  - (optional) use "XFree86 Big5" as far as possible (within CNS11643-{1,2}).
>  - (optional) use "CNS11643" way for other than CNS11643-{1,2}.

Actually, CNS11643 plane 1,2 which correspond to Big5 level 1,2.

> When receiving a CTEXT which contains CNS11643 characters:
>  - (optional) accept "CNS11643" way.
> 
> Note that:
>  - "XFree86 Big5" is a way used in XTextListToTextProperty().
>    Based on XFree86's xc/doc/specs/CTEXT/ctext "6 Non-Standard
>    Character Set Encoding".
>    01/11 02/05 02/15 03/02 M L "b"  "i"  "g"  "-"  "5" STX (contents)
>    Note that "big-5" may be in capital (uppercase).
>    The contents is the raw byte sequence of the Big5 string.
> 
>  - "Emacs Big5" is a way used by Emacs.  (Is this CNS11643?)
>    Based on XFree86's xc/doc/specs/CTEXT/ctext "11 Extensions".
>    It seems to use  ESC $ ( 0  and  ESC $ ( 1.
> 
>  - "CNS11643" is the way I don't know.  (Used only by mlterm?)
>    Are there any instances of this?
> 
> This is because:
>  - "XFree86 Big5" is the way which is widely used in Taiwan.  Because
>    Big-5 support is primarily for Taiwan people, mlterm should also
>    use this way as far as possible.
>  - I discussed with Handa-san (a developer of Mule/Emacs) and we agreed
>    that future Emacs will use "XFree86 Big5" for sending/receiving,
>    while "Emacs Big5" will be accepted for receiving for compatibility.
> 
> 
> Could you tell me where is the CTEXT composer and parser of mlterm?
> Since RTL is a heavy work, I will research this problem until you
> finish RTL.
> 
> 
> References:
> 
> XFree86 Big5 bugs (adopted into XFree86 CVS tree in this September)
> http://www.xfree86.org/pipermail/i18n/2001-July/002091.html
> 
> Detailed explanation on Big5 and CTEXT by Tung-Han Hsieh
> http://www.xfree86.org/pipermail/i18n/2001-June/002052.html
> 
> ---
> 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

-- 
Warm Regards,
Edward G.J. Lee¡]§õªG¥¿¡^

Re: [Mlterm-dev-en] mlterm-rtl3

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

        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
 	)

Re: [Mlterm-dev-en] cut&paste problem

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

        Hi,

	Subject: Re: [Mlterm-dev-en] cut&paste problem
	From: Tomohiro KUBOTA <tk...@ri...>
	Message-ID: <200...@si...>
	Date: Fri, 07 Dec 2001 09:43:32 +0900

> I think converting Big5 into CNS11643 is a bad idea because it is
> not popular in Taiwan.

        I see.
        
        This problem has been listed in my personal todo since a long time ago ,
        but I couldn't decide how to deal with ESC % / sequence in a generic
        ISO2022 parser.

> Could you tell me where is the CTEXT composer and parser of mlterm?
> Since RTL is a heavy work, I will research this problem until you
> finish RTL.

        mkf/lib/mkf_iso2022_parser.[ch] is the core ISO2022 parser.
        
        you can see dummy codes for ESC % / sequence after
        
        if( *iso2022_parser->parser.str == NON_ISO2022_CS)
        {
                ....


        I have an idea about this problem , so I'll also challenge it later :)
        
--
kiken
j00...@ip...

[Mlterm-dev-en] mlterm-rtl3

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

        Hi,

        I retried to implement RTL character support using FriBidi.

        http://f-cubed.com/ken/mlterm/mlterm-2.1.0-pre20011207-rtl3.tar.gz
        
        Please test this and give us your comments:)

        <HOW TO>
        First of all , install the latest FriBidi library (http://fribidi.sourceforge.net/)
        to your system.

        and then , compile mlterm as follows.
        
        $ ./configure --enable-fribidi
        $ make
        $ make install

        $ mlterm -km utf8 -bi

        you can't use bidi support without -bi option.

        otherwise , you can also use bidi by adding

        use_bidi = true

        to ~/.mlterm/main.

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

Re: [Mlterm-dev-en] cut&paste problem

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

Hello,

At 07 Dec 2001 02:16:41 +0900,
Araki Ken wrote:

> rxvt/aterm copy and paste Big5 characters with ISO2022 ESC % / ... sequence ,
> but mlterm doesn't still implement it.
> At the present time mlterm converts Big5 to UTF-8 or CNS11643 in sending or
> receiving characters with other X applications.

I think converting Big5 into CNS11643 is a bad idea because it is
not popular in Taiwan.

When sending a CTEXT which contains Big5 characters:
 - use "XFree86 Big5" way.

When receiving a CTEXT which contains Big5 characters:
 - accept "XFree86 Big5" and "Emacs Big5" ways.

When sending a CTEXT which contains CNS11643 characters:
 - (optional) use "XFree86 Big5" as far as possible (within CNS11643-{1,2}).
 - (optional) use "CNS11643" way for other than CNS11643-{1,2}.

When receiving a CTEXT which contains CNS11643 characters:
 - (optional) accept "CNS11643" way.

Note that:
 - "XFree86 Big5" is a way used in XTextListToTextProperty().
   Based on XFree86's xc/doc/specs/CTEXT/ctext "6 Non-Standard
   Character Set Encoding".
   01/11 02/05 02/15 03/02 M L "b"  "i"  "g"  "-"  "5" STX (contents)
   Note that "big-5" may be in capital (uppercase).
   The contents is the raw byte sequence of the Big5 string.

 - "Emacs Big5" is a way used by Emacs.  (Is this CNS11643?)
   Based on XFree86's xc/doc/specs/CTEXT/ctext "11 Extensions".
   It seems to use  ESC $ ( 0  and  ESC $ ( 1.

 - "CNS11643" is the way I don't know.  (Used only by mlterm?)
   Are there any instances of this?

This is because:
 - "XFree86 Big5" is the way which is widely used in Taiwan.  Because
   Big-5 support is primarily for Taiwan people, mlterm should also
   use this way as far as possible.
 - I discussed with Handa-san (a developer of Mule/Emacs) and we agreed
   that future Emacs will use "XFree86 Big5" for sending/receiving,
   while "Emacs Big5" will be accepted for receiving for compatibility.


Could you tell me where is the CTEXT composer and parser of mlterm?
Since RTL is a heavy work, I will research this problem until you
finish RTL.


References:

XFree86 Big5 bugs (adopted into XFree86 CVS tree in this September)
http://www.xfree86.org/pipermail/i18n/2001-July/002091.html

Detailed explanation on Big5 and CTEXT by Tung-Han Hsieh
http://www.xfree86.org/pipermail/i18n/2001-June/002052.html

---
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] cut&paste problem

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

        Hi,

	Subject: [Mlterm-dev-en] cut&paste problem
	From: "Edward G.J. Lee" <ed...@ms...>
	Message-ID: <200...@da...>
	Date: Fri, 7 Dec 2001 01:10:24 +0800

>   I'm using mlterm cvs version. When I do cut&paste between
>   mlterm vs rxvt/aterm, Chinese(Big5) cannot paste each other.

        Thanks for your report :)

        rxvt/aterm copy and paste Big5 characters with ISO2022 ESC % / ... sequence ,
        but mlterm doesn't still implement it.
        At the present time mlterm converts Big5 to UTF-8 or CNS11643 in sending or
        receiving characters with other X applications.
        
        that is why you can't copy and paste between mlterm and rxvt/aterm.

        I'll try it after I finishes implementing RTL support.

        # Yesterday's RTL patch was seriously bad , but I retried with FriBidi
        # and it seems to work better at hand.
        # I'll throw the patch after testing it.

>   Thanks mlterm, it's a great work. :)

        You're welcome:)

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