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

Re: [Mlterm-dev-en] font error

[ghita t. <ga...@gw...>]

I actually convert the file to utf8 and then open, the error is gone. However I get weird characters for the arabic script even though I open mlterm with -bi option as the file has both engish and arabic
plz help
thanks

----- Original Messh age -----
From: ghita tijani <ga...@gw...>
Date: Monday, April 23, 2007 9:58 pm
Subject: [Mlterm-dev-en] font error
To: mlt...@li...


> Hello,
>  I am using mandriva 2007. I installed mlterm as I need to be able to 
> edit both english and arabic. when I open a file with arabic script in 
> it I ge the following error messages. Do the messages mean that I 
> don't have the font installed, which I am not sur e how to check. Or 
> am supposed to install them. If that is the case whatis the name of 
> the package. thanks in advance.
> 
> font -misc-sazanami 
> gothic-medium-r-normal-*-*-140-*-*-c-*-jisx0208.1983-0 couln't be loaded.
>  font -misc-ar pl new sung-medium-r-normal-*-*-140-*-*-c-*-gbk-0 
> couln't be loaded.
>  font -misc-ar pl new 
> sung-medium-r-normal-*-*-140-*-*-c-*-gb2312.1980-0 couln't be loaded.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> 
> _______________________________________________
> Mlterm-dev-en mailing list
> Mlt...@li...
> 

Re: [Mlterm-dev-en] font error

[MINAMI H. <mi...@mi...>]

ghita tijani wrote:
>  I am using mandriva 2007. I installed mlterm as I need to be able to edit
 > both english and arabic. when I open a file with arabic script in it I ge
 > the following error messages.
...
> font -misc-sazanami gothic-medium-r-normal-*-*-140-*-*-c-*-jisx0208.1983-0 couln't be loaded.
>  font -misc-ar pl new sung-medium-r-normal-*-*-140-*-*-c-*-gbk-0 couln't be loaded.
>  font -misc-ar pl new sung-medium-r-normal-*-*-140-*-*-c-*-gb2312.1980-0 couln't be loaded.

Hmm, Mandriva seems to shipping mlterm with their own font configuration
which tries to use Japanese/Chinese fonts.
When you need only English and Arabic, the warnings should be harmless.

However, to use Arabic, you need a font which supports Arabic.

Though I'm not familiar with Mandriva, general information
about how to configure mlterm with Arabic fonts may be found
on the web:
http://www.k2.dion.ne.jp/~oibane/aonl/en/mlterm.htm
http://www.arabeyes.org/download/documents/howto/arabic-howto-en/xwindows.html
http://faculty.washington.edu/heer/enablingarabic.htm

minami

[Mlterm-dev-en] font error

[ghita t. <ga...@gw...>]

Hello,
 I am using mandriva 2007. I installed mlterm as I need to be able to edit both english and arabic. when I open a file with arabic script in it I ge the following error messages. Do the messages mean that I don't have the font installed, which I am not sur e how to check. Or am supposed to install them. If that is the case whatis the name of the package. thanks in advance.

font -misc-sazanami gothic-medium-r-normal-*-*-140-*-*-c-*-jisx0208.1983-0 couln't be loaded.
 font -misc-ar pl new sung-medium-r-normal-*-*-140-*-*-c-*-gbk-0 couln't be loaded.
 font -misc-ar pl new sung-medium-r-normal-*-*-140-*-*-c-*-gb2312.1980-0 couln't be loaded.

Re: [Mlterm-dev-en] Arabic and mlterm

[Nicholas H. <he...@es...>]

Minami,

	I'm not sure how I did it, but with Debian's "dpkg-reconfigure
locales" command I was able to change my whole locale from POSIX to
en_US.UTF-8.  Now I can launch mlterm from any terminal and from the icon
also and it works beautifully.  :-)  Thanks so much for all your help.

Nicholas

On Thu, 5 Apr 2007, MINAMI Hirokazu wrote:

> Nicholas Heer wrote:
> > So it seems that mlterm works
> > when LC_CTYPE=en_US.UTF-8, but does not work when LC_CTYPE="POSIX".
>
> Sorry, your uxterm seems to tweak LC_CTYPE, not LANG.
>
> If your locale is POSIX,
> mlterm will assume you are using ISO-8859-1 (to make dummies happy)
> and do not try to parse its input as UTF-8.
> It's not surprising you cannot see Arabic in this case.
>
> >  So is
> > there any way to change LC_CTYPE from "POSIX" to en_US.UTF-8?  I've looked
> > in all my Linux and Unix books for an explanation of how to change locales
> > and I can't find anything.  And I can't understand the man pages for
>  > locale and setlocale.
>
> LC_CTYPE is just yet another environment variable used to override LANG.
> As far as LC_CTYPE is one of a UTF-8 locale, mlterm will accept
> UTF-8 by default (even if LANG is undefined/POSIX/C/etc).
>
> However, if you don't have to use different values for LANG and
> LC_CTYPE, you should leave LC_CTYPE undefined and use LANG.
>
> Please try
>   LANG=en_US.UTF-8 mlterm
> and if this works, consider to change LANG to be en_US.UTF-8.
>
> >  It doesn't matter, however, if I don't succeed in
> > changing the locale since I can always run mlterm from an uxterm, but I'm
> > curious as to why mlterm acts this way on my computer.
>
> Basically, mlterm and application running on mlterm must agree
> which encoding to use. The encoding must of course support
> the character set you want (in this case, Arabic).
>
> Since uxterm seems to set LC_CTYPE to a UTF-8 locale,
> mlterm launched from uxterm and apps run from the mlterm
> will use UTF-8 (ignoring LANG).
> You should be able to use Arabic in this case.
>
> If neither LANG nor LC_CTYPE was defined, you can't expect so much.
>
> Is this clear enough?
>
> minami
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Mlterm-dev-en mailing list
> Mlt...@li...
> https://lists.sourceforge.net/lists/listinfo/mlterm-dev-en
>

Re: [Mlterm-dev-en] Arabic and mlterm

[MINAMI H. <mi...@mi...>]

Nicholas Heer wrote:
> So it seems that mlterm works
> when LC_CTYPE=en_US.UTF-8, but does not work when LC_CTYPE="POSIX".

Sorry, your uxterm seems to tweak LC_CTYPE, not LANG.

If your locale is POSIX,
mlterm will assume you are using ISO-8859-1 (to make dummies happy)
and do not try to parse its input as UTF-8.
It's not surprising you cannot see Arabic in this case.

>  So is
> there any way to change LC_CTYPE from "POSIX" to en_US.UTF-8?  I've looked
> in all my Linux and Unix books for an explanation of how to change locales
> and I can't find anything.  And I can't understand the man pages for
 > locale and setlocale.

LC_CTYPE is just yet another environment variable used to override LANG.
As far as LC_CTYPE is one of a UTF-8 locale, mlterm will accept
UTF-8 by default (even if LANG is undefined/POSIX/C/etc).

However, if you don't have to use different values for LANG and
LC_CTYPE, you should leave LC_CTYPE undefined and use LANG.

Please try
  LANG=en_US.UTF-8 mlterm
and if this works, consider to change LANG to be en_US.UTF-8.

>  It doesn't matter, however, if I don't succeed in
> changing the locale since I can always run mlterm from an uxterm, but I'm
> curious as to why mlterm acts this way on my computer.

Basically, mlterm and application running on mlterm must agree
which encoding to use. The encoding must of course support
the character set you want (in this case, Arabic).

Since uxterm seems to set LC_CTYPE to a UTF-8 locale,
mlterm launched from uxterm and apps run from the mlterm
will use UTF-8 (ignoring LANG).
You should be able to use Arabic in this case.

If neither LANG nor LC_CTYPE was defined, you can't expect so much.

Is this clear enough?

minami

Re: [Mlterm-dev-en] Arabic and mlterm

[Nicholas H. <he...@es...>]

Dear Minami,

	I haven't yet discovered how to change any of the environment
variables connected with locale.  However I think I know why mlterm works
in an uxterm and why it doesn't in an xterm.  If I give the command
"locale" in an xterm I get the following:

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

If I give the same command in an uxterm I get:

LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

If I give the same command in an mlterm launched from an xterm I get the
same result as I do when I give the command in an xterm.  However, when I
give the "locale" command in an mlterm launched from an uxterm I get the
same result as I got before in the uxterm.  So it seems that mlterm works
when LC_CTYPE=en_US.UTF-8, but does not work when LC_CTYPE="POSIX".  So is
there any way to change LC_CTYPE from "POSIX" to en_US.UTF-8?  I've looked
in all my Linux and Unix books for an explanation of how to change locales
and I can't find anything.  And I can't understand the man pages for
locale and setlocale.  It doesn't matter, however, if I don't succeed in
changing the locale since I can always run mlterm from an uxterm, but I'm
curious as to why mlterm acts this way on my computer.

Nicholas Heer


On Wed, 4 Apr 2007, Nicholas Heer wrote:

> Dear Minami,
>
> 	Thank you very much for your help.  I'll try changing the value of
> $LANG as you suggest.
>
> Nicholas
>
> On Wed, 4 Apr 2007, MINAMI Hirokazu wrote:
>
> > Nicholas Heer wrote:
> > > 	I have finally succeeded in getting mlterm to work with Arabic on
> > > my Debian Linux computer.  But it only works properly if I load it from a
> > > unicode xterm (uxterm).
> >
> > Your default locale do not seem to support Arabic.
> >
> > Please check the values of LANG. i.e. try
> >   echo $LANG
> > on uxterm and on mlterm (without being launched from uxterm).
> >
> > If those two value are different, try to run mlterm from
> > some other terminal emulator with the former:
> > ex.)
> >   LANG=ar_XX.UTF-8 mlterm
> >
> > ... and if mlterm works as you wish with the value,
> > you should use it as your LANG somehow.
> > # how to set LANG depends on your distribution / desktop environment.
> >
> >
> > minami
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Mlterm-dev-en mailing list
> > Mlt...@li...
> > https://lists.sourceforge.net/lists/listinfo/mlterm-dev-en
> >
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Mlterm-dev-en mailing list
> Mlt...@li...
> https://lists.sourceforge.net/lists/listinfo/mlterm-dev-en
>

Re: [Mlterm-dev-en] Arabic and mlterm

[Nicholas H. <he...@es...>]

Dear Minami,

	Thank you very much for your help.  I'll try changing the value of
$LANG as you suggest.

Nicholas

On Wed, 4 Apr 2007, MINAMI Hirokazu wrote:

> Nicholas Heer wrote:
> > 	I have finally succeeded in getting mlterm to work with Arabic on
> > my Debian Linux computer.  But it only works properly if I load it from a
> > unicode xterm (uxterm).
>
> Your default locale do not seem to support Arabic.
>
> Please check the values of LANG. i.e. try
>   echo $LANG
> on uxterm and on mlterm (without being launched from uxterm).
>
> If those two value are different, try to run mlterm from
> some other terminal emulator with the former:
> ex.)
>   LANG=ar_XX.UTF-8 mlterm
>
> ... and if mlterm works as you wish with the value,
> you should use it as your LANG somehow.
> # how to set LANG depends on your distribution / desktop environment.
>
>
> minami
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Mlterm-dev-en mailing list
> Mlt...@li...
> https://lists.sourceforge.net/lists/listinfo/mlterm-dev-en
>

Re: [Mlterm-dev-en] Arabic and mlterm

[MINAMI H. <mi...@mi...>]

Nicholas Heer wrote:
> 	I have finally succeeded in getting mlterm to work with Arabic on
> my Debian Linux computer.  But it only works properly if I load it from a
> unicode xterm (uxterm).

Your default locale do not seem to support Arabic.

Please check the values of LANG. i.e. try
  echo $LANG
on uxterm and on mlterm (without being launched from uxterm).

If those two value are different, try to run mlterm from
some other terminal emulator with the former:
ex.)
  LANG=ar_XX.UTF-8 mlterm

... and if mlterm works as you wish with the value,
you should use it as your LANG somehow.
# how to set LANG depends on your distribution / desktop environment.


minami

[Mlterm-dev-en] Arabic and mlterm

[Nicholas H. <he...@es...>]

	I have finally succeeded in getting mlterm to work with Arabic on
my Debian Linux computer.  But it only works properly if I load it from a
unicode xterm (uxterm).  It doesn't work properly if loaded from any other
terminal or from the Debian menu or a desktop icon.  Why is this?  Is
mlterm designed to work only from an uxterm or have I misconfigured it in
some way?

Nicholas Heer

[Mlterm-dev-en] Indic script handling questions

[Rich F. <da...@ae...>]

Could anyone familiar with the code explain how mlterm handles
reordering for Indic scripts (and possibly also bidi text). In
particular I'm interested in the relationship between logical order of
characters in the terminal buffer and the display order, and the
interaction between cursor positioning functions/insert/delete and
existing characters already in the terminal. I'm also very interested
in what is supposed to happen with characters that 'should' have
different character-cell widths in different contexts, for example the
Devanagari "ra".

Whatever the behavior is, are there any standards on which is it
based, or was the behavior invented for mlterm?

Rich

Re: [Mlterm-dev-en] Arabic translation

[Seiichi S. <me...@se...>]

On Sat, Aug 12, 2006 at 06:32:19PM +0300,
 Khaled Hosny wrote:

> As an Arabic speaker, I translated mlconfig.pot to Arabic, the file is
> attached.

Applied, thanks.

-- 
Seiichi

[Mlterm-dev-en] Arabic translation

[Khaled H. <kha...@eg...>]

First I'd like to thank every one made this great terminal emulator
available, I really like it :).

As an Arabic speaker, I translated mlconfig.pot to Arabic, the file is
attached.
I don't know if there is any files need to be translated other than this
one, if so, let me know this.

-- 
Khaled Hosny

Egyptian GNU/Linux user
Member of Arabeyes translation team [http://www.arabeyes.org]
My Blog: [http://khalid_hosny.manalaa.net]

[Mlterm-dev-en] fontsize and scim problem

[Jesse W. <jes...@gm...>]

Hi, I switched from gnome-terminal to mlterm recently, it is wired
that scim can be invoked only when fontsize is set to the default
value 16. I am using ubuntu dapper with locale en_US.UTF-8. Thanks in
advance.

-- 
Cheers
Jesse Woo

[Mlterm-dev-en] Odd transparency problem with OroborOSX

[Ambrose LI <ac...@ad...>]

Hi,

I am seeing a very strange problem with mlterm 2.9.3 (and an earlier version)
when it is running under OroborOSX. (mlterm running on Linux and displayed
remotely on a Mac)

When anti-alias is used (either with the old "anti-alias" method or the new
"xft" method), the characters (foreground, not background) becomes transparent.
This causes parts of the characters to become unreadable because the window
under the mlterm window either is white or is too light-coloured.

This does not happen when anti-aliasing is not used, and it seems that mlterm
is the only program that has this problem. It also only happens when I run
mlterm under OroborOSX; if I use the stock "X11" application that comes with
the system, this does not happen either.

I wonder if anyone else is seeing this or knows what the problem is (or how
to fix this). Thanks very much.

Regards,
Ambrose

[Mlterm-dev-en] Unicode and XEmacs

[Taka F. <fu...@co...>]

    Hello Guys,
    
    I am a happy user of Mlterm (+ XEmacs), and I really
    like AA fonts on them.
    
    I am now considering to move on to Unicode, and to me
    this means to use Mlterm + XEmacs in UTF-8 encoding.
    What I did are, 1) in ~/.mlterm/main, changed
    a few settings:
    - ENCODING=UTF-8
    - not_use_unicode_font = true  # needed for SKK
    and 2) in .xemacs/init.el, added 
----
(require 'un-define)
(coding-system-put 'utf-8 'category 'utf-8)
(set-coding-category-system 'utf-8 'utf-8)
(set-language-info
 "Japanese" 
 'coding-priority (cons 'utf-8
                        (get-language-info "Japanese" 'coding-priority)))
(set-language-environment "Japanese")
---
    
    Everything seemed to be OK at first, but I experienced a
    very subtle problem.  Occasionally, some Japanese
    characters disappear.  The missing charactors are
    sometimes replaced with a blank, but usually no space is
    left at all.  The problem disappears when I sweep the
    cursor around them, or when I refresh the screen with
    Ctrl-L.
    
  * The symptom remains unchanged in:
    Linux FC-3, FC-5
      Mlterm-2.9.2/2.9.3 + XEmacs-21.4.19
    
    Cygwin
      Mlterm-2.9.2 + XEmacs-21.4.19
    
  * It occurs for files encoded in UTF-8, euc-jp, or
    iso-2022-jp. 
    
  * I tried to reproduce the problem on XEamcs on X, but
    the results are negative.
    
  * Also tried to do so about 'cat' command, but could not
    find any problems. (This test is not very thorough,
    though.) 
    
  * It looks like setting of not_use_unicode_font does not
    matter. 
    
  * In all the tests,  Mlterm was with 
    use_variable_column_width = true
    use_anti_alias = true

    Best regards,
    

-- 
--                                               Taka Fukuda
--                                    fukuda at computer.org
    
    

Re: [Mlterm-dev-en] mlterm, tibetan, and bitmap fonts?

[Seiichi S. <me...@se...>]

On Tue, Apr 04, 2006 at 04:52:12PM -0400,
 Rich Felker wrote:

> No, there's an older font named "Tibetan Machine" that's the same
> glyphs, but with a minimal amount of precombining done in order that
> the remainder of the necessary combinations can be made with simple
> overstrike using characters positioned to the left of their cell with
> zero width. It's actually several fonts that have to be used together
> because each one is limited to 8 bits.

Is that font in PCF or BDF format?
created by THDL?

> > Actually, we do not need yet another custom encoding and
> > re-encode every font for it.
> 
> I don't understand what you mean by this.. ?

Using font-specific encodings for combined glyphs is
inefficient for maintenance.

e.g.,
 - custum encoding for Tibetan Machine font
 - custom encoding for Tibetan foo font
 - custom encoding for Bengli foo font
 - custom encoding for Bengli bar font
 - custom encoding for Malayalam foo font
              :
              :

Using GPOS/GSUB tables is a nice solution to avoid it because
process for reading the tables can be used for any fonts.

Actually, mlterm-2.9.x already has a feature to render pre-combined
glyphs in the bitmap font using libiscii for Indic scripts. But
this feature has been broken and maintenance is too hard for us.

In mlterm-3.x, we may drop support for a server-side font
rendering and add support for libraries such as pango and
m17nlib.


> The number of such fonts I can count on one hand, and none of them are
> appropriate for use in a terminal emulator unless you want to fit at
> most 80 columns on a full 1280x960 screen...

You mean that (small) truetype fonts are not easy readable?


> In general, I would think the target audience of mlterm is people who
> want to be able to use multi (probably very many) languages in a
> common terminal. At least that's my goal. Using truetype fonts with
> opentype info is incredibly unrealistic for a terminal...you'll end up
> needing 200 megs of memory or more just to load everything. The
> realistic solution is the classic solution for terminals: using small
> character cell bitmap fonts. However this needs to be adapted to
> support combining and double-width characters nicely...that's what I'm
> trying to figure out how to do, and what solves the general problem of
> supporting arbitrary scripts efficiently.

Hmm... I don't guess so.
On modern systems, I think memory usage for loading a truetype font
does not matter much.

Regards,

-- 
Seiichi

[Mlterm-dev-en] mlterm-2.9.3 released

[Seiichi S. <me...@se...>]

Hi all,

This is to announce the release of mlterm version 2.9.3.

  http://prdownloads.sourceforge.net/mlterm/mlterm-2.9.3.tar.gz


Overview of changes from 2.9.2
==============================

* Improvements for compatibility with xterm:
  - Log file handling [kzys]
  - Function keys [seiichi] (Thanks to Konosuke Watanabe)
  - Sequence for setting scroll region [seiichi]
    (Thanks to SHIOTA Shoichi and Takashi SHIRAI)
  - Behavior of saving/restoring cursor [minami]
    (Thanks to Thomas Dickey for suggestions)
  - Termcap and Terminfo [minami, seiichi]
  - Turn off mouse position reporting by a "reset" sequence [minami]
    (Debian Bug #55637)
* Improvement build prosess for cross-compiling [minami]
* Workaround for missing rgb.txt [minami]
* Updated documents [kzys, minami, seiichi]
* Bug fix for broken selection requester [minami]
* Added support for SCIM-1.4.x [seiichi]
* Removed support for SCIM-1.0.x [seiichi]
* Removed support for uim-0.x.x [seiichi]
* Hebrew mapping table for "kbd" input method [seiich]
* Revided a scroll caching mechanism [seiichi] (SF Bug #1161050)
* Suppressed a check for libxpg4 of FreeBSD [seiichi]
  (Thanks to SHIOTA Shoichi and MANTANI Nobutaka)
* Fixed a bug of alignment of full width chars when variable column width is
  enabled [minami] (Thanks to Oibane)
* Vietnamese translation for mlconfig [Pham Thanh Long]
* Other Bug fixes:
  - SF Bug #1206515 [Takeshi Hakamata]
  - SF Bug #1161055 [seiichi]
  - Debian Bug #302231 [Andreas Jochens]
  - Debian Bug #313970 [Jens Seidel]
  - Debian Bug #350590 [seiichi]
  - SUSE Bug #105320 [mfabian]

-- 
Seiichi

Re: [Mlterm-dev-en] SCIM support (dlopen problem) question

[Cezary B. <tr...@gm...>]

Seiichi SATO wrote:
> On Tue, Apr 18, 2006 at 12:36:23AM +0200,
>  Cezary Baginski wrote:
> 
>> - does it already work? (last time I checked the CVS - same problem)
> 
> Yes, it works on my debian box at least.
> 

Thanks for the information.

Results: current CVS version works fine and RPM builds/works fine on 
Fedora Core 5 with scim-1.4.4-14.


I deeply appreciate the work of all the contributors of Mlterm - it is 
definitely one of the *most* important tools for me.

Re: [Mlterm-dev-en] SCIM support (dlopen problem) question

[Seiichi S. <me...@se...>]

On Tue, Apr 18, 2006 at 12:36:23AM +0200,
 Cezary Baginski wrote:

> - does it already work? (last time I checked the CVS - same problem)

Yes, it works on my debian box at least.

> - is someone working on it?

Yes, some people use it on OpenBSD and FreeBSD.

> - does anyone want it fixed except me?

I don't know.

> - has this been mentioned/dealt with on the Japanese mailing list?

No. The primary mailing list is mlterm-dev-en.

-- 
Seiichi

Re: [Mlterm-dev-en] Vietnamese translation

[Seiichi S. <me...@se...>]

On Mon, Apr 17, 2006 at 09:21:46PM +0700,
 Ph???m Thｾｭ爾nh Long wrote:

> I've finished the Vietnamese translation for mlterm-2.9.2.
> 
> Download: http://ngonngu.net/bNb/L10n/mlterm-2.9.2-vi.po
> 
> I hope it will be included in the next release of mlterm.

I committed it to CVS just now.
Thanks for your work.

-- 
Seiichi

[Mlterm-dev-en] SCIM support (dlopen problem) question

[Cezary B. <tr...@gm...>]

SCIM support in mlterm hasn't been working for a while (currently 
scim-1.4.4), and since SCIM is now recommended instead of IIIMF in 
Fedora, I tried to get it to work.

I ran to the same problems as mentioned here:

	http://sourceforge.net/mailarchive/message.php?msg_id=14519519
	http://sourceforge.net/mailarchive/message.php?msg_id=15094519

I'm thinking about fixing this myself, so I was wondering:

- does it already work? (last time I checked the CVS - same problem)
- is someone working on it?
- does anyone want it fixed except me?
- has this been mentioned/dealt with on the Japanese mailing list?


Thanks for any info.

[Mlterm-dev-en] Vietnamese translation

[L. <pt...@gm...>]

Hi,
I've finished the Vietnamese translation for mlterm-2.9.2.

Download: http://ngonngu.net/bNb/L10n/mlterm-2.9.2-vi.po

I hope it will be included in the next release of mlterm.

-- 
lngt @ ngonngu.net

Re: [Mlterm-dev-en] mlterm, tibetan, and bitmap fonts?

[Rich F. <da...@ae...>]

On Sun, Apr 02, 2006 at 10:44:41PM +0900, MINAMI Hirokazu wrote:
> > After reviewing the situation, it seems the the TCRC font (the most
> > popular one) uses overstriking hacks wherever possible to fit all
> > glyphs in the single-byte range. This is obviously not acceptable as a
> > glyph encoding because the ability to use overstrike is very
> > font-specific and generally incorrect. There's another somewhat
> > established encoding, from the "Tibetan Machine" font, which could be
> > used instead. My understanding is that it contains all possible
> > stacks and does not use overstriking.
> 
> There seems to be some fonts in TCRC and
> I'm not sure how they relate each other and which is the most popular...
> Does "Tibetan Machine" mean "TibetanMachineUniAlpha.ttf"?
> If not, where can I get the "Tibetan Machine" font?

No, there's an older font named "Tibetan Machine" that's the same
glyphs, but with a minimal amount of precombining done in order that
the remainder of the necessary combinations can be made with simple
overstrike using characters positioned to the left of their cell with
zero width. It's actually several fonts that have to be used together
because each one is limited to 8 bits.

I can't seem to find it on the web again right now.. sorry about that.
There's also a version called Tibetan Machine Web which is similar but
with even more font files, since it avoids using codepoints that might
conflict with other uses (control codes, etc.).

> > Hmm, it seems like I said two rather conflicting things here. What I
> > meant to say is that, while supporting script-specific glyph encodings
> > separate from character encodings is a possible solution (and probably
> > results in maximal font quality), what we really need is a mechanism
> > for all fonts (including bitmap fonts) to carry with them anchor point
> > information for combining, so that the terminal emulator can perform
> > arbitrary combining/stacking rather than just a fixed set of glyphs.
> 
> Actually, we do not need yet another custom encoding and
> re-encode every font for it.

I don't understand what you mean by this.. ?

> A OpenType font can contain information about contained glyphs
> like  GSUB or GPOS table. We can convert from Unicode to
> combined-forms using them without additional definitions.
> 
> So if we support such feature, i.e. reading GSUB/GPOS table,
> every OpenType font which contain Tibetan glyphs and has
> correctly coded should work.

The number of such fonts I can count on one hand, and none of them are
appropriate for use in a terminal emulator unless you want to fit at
most 80 columns on a full 1280x960 screen...

In general, I would think the target audience of mlterm is people who
want to be able to use multi (probably very many) languages in a
common terminal. At least that's my goal. Using truetype fonts with
opentype info is incredibly unrealistic for a terminal...you'll end up
needing 200 megs of memory or more just to load everything. The
realistic solution is the classic solution for terminals: using small
character cell bitmap fonts. However this needs to be adapted to
support combining and double-width characters nicely...that's what I'm
trying to figure out how to do, and what solves the general problem of
supporting arbitrary scripts efficiently.

As for users who just want a few languages, not full level-3
combining, precombined glyphs might be a lighter-weight and simpler
solution to the problem. Some scripts already have these;
unfortunately for me Tibetan does not.

Rich

Re: [Mlterm-dev-en] mlterm, tibetan, and bitmap fonts?

[Kenichi H. <ha...@m1...>]

In article <114...@cr...>, MINAMI Hirokazu <mi...@mi...> writes:
> The problem is, implementing a reader for OpenType's tables
> may not so easy. There are so many OpenType features other
> than combining and too many broken fonts.
> If you need to support only one font, hard-coding a conversion table
> for the font and see what happens then would be far more easier.

> IIRC, m17n-lib is distributed with a companion library, libotf,
> and accessing OpenType tables may be trivial with it.
> But I'm not yet have enough time to try... 

Yes, libotf is a handy library to lookup/drive OpenType
tables.  But, we usually have to reorder character seqeucne
before applying OpenType's GSUB and GPOS features on it.
For instance, see this page for how to use Devanagari
OpenType fonts.

http://www.microsoft.com/typography/otfntdev/devanot/shaping.aspx

And that reordering require knowlege about each script.
Does mlterm have a layter for such a processing?

---
Kenichi Handa
ha...@m1...

Re: [Mlterm-dev-en] mlterm, tibetan, and bitmap fonts?

[MINAMI H. <mi...@mi...>]

On Wed, 2006-03-08 at 18:04 -0500, Rich Felker wrote:
> On Wed, Mar 08, 2006 at 03:48:47AM -0500, Rich Felker wrote:
> > On Tue, Mar 07, 2006 at 02:45:57AM +0900, MINAMI Hirokazu wrote:
> > > The plan I had was:
> > > 
> > > By assuming specific font, the conversion table can be hard-coded.
> > > i.e. when the glyph ordering of the font to be used is known,
> > > we can write conversion rules like following:
> > > 0x0f40, 0x0f72 => glyph ID xxxx
> > > 0x0f40, 0x0f7f => glyph ID yyyy
> > 
> > Yes... Maybe the most appropriate solution is to make a special
> > encoding for precombined Tibetan and include the mappings to that
> > encoding in mlterm so it could use fonts in that encoding. Actually...
> > there are already such encodings for nasty pre-Unicode hacks
> > (basically they were fake latin1 fonts with Tibetan characters in
> > place of the letters). For the sake of being able to use these legacy
> > fonts too, they could be used as the basis for such an encoding.
> 
> After reviewing the situation, it seems the the TCRC font (the most
> popular one) uses overstriking hacks wherever possible to fit all
> glyphs in the single-byte range. This is obviously not acceptable as a
> glyph encoding because the ability to use overstrike is very
> font-specific and generally incorrect. There's another somewhat
> established encoding, from the "Tibetan Machine" font, which could be
> used instead. My understanding is that it contains all possible
> stacks and does not use overstriking.

There seems to be some fonts in TCRC and
I'm not sure how they relate each other and which is the most popular...
Does "Tibetan Machine" mean "TibetanMachineUniAlpha.ttf"?
If not, where can I get the "Tibetan Machine" font?

> > > With Xft, drawing for non USASCII/ISO8859-1 characters are processed in 
> > > xwindow/x_window.c:x_window_xft_draw_string32().
> > > the function takes an array of UCS4 codes like 0x0f40, 0x0f72... .
> > > 
> > > So it may be possible to hack the function to watch input
> > > and if the input sequence were Tibetan chars to be combined,
> > > intercept them and call XftDrawGlyphs() instead.
> > 
> > Again I don't think special-casing Tibetan is appropriate. The same
> > issues apply to all combining characters, including most South Asian
> > languages, mathematical combining marks, etc. and they can all be
> > handled in a unified way IMO.
> 
> Hmm, it seems like I said two rather conflicting things here. What I
> meant to say is that, while supporting script-specific glyph encodings
> separate from character encodings is a possible solution (and probably
> results in maximal font quality), what we really need is a mechanism
> for all fonts (including bitmap fonts) to carry with them anchor point
> information for combining, so that the terminal emulator can perform
> arbitrary combining/stacking rather than just a fixed set of glyphs.

Actually, we do not need yet another custom encoding and
re-encode every font for it.

A OpenType font can contain information about contained glyphs
like  GSUB or GPOS table. We can convert from Unicode to
combined-forms using them without additional definitions.

So if we support such feature, i.e. reading GSUB/GPOS table,
every OpenType font which contain Tibetan glyphs and has
correctly coded should work.


The problem is, implementing a reader for OpenType's tables
may not so easy. There are so many OpenType features other
than combining and too many broken fonts.
If you need to support only one font, hard-coding a conversion table
for the font and see what happens then would be far more easier.


IIRC, m17n-lib is distributed with a companion library, libotf,
and accessing OpenType tables may be trivial with it.
But I'm not yet have enough time to try... 

 
regards,