Re: [I18n]Re: Thai XIM
Excited to hear about mlterm. I'll try it soon. :)
Regarding the Thai XIM, the input method is just one-by-one character
(no sophisticated thing like CJK), plus input sequence check, whose
strictness can be adjusted using XMODIFIERS, as stated in my mentioned
page. It would be great if mlterm also provides the string conversion
callback, so that the XIM can handle the context-sensitive cases.
Regarding tis620 fontsets below...
On Wed, Nov 28, 2001 at 10:18:41AM +0900, Tomohiro KUBOTA wrote:
> At Wed, 28 Nov 2001 10:01:26 +1100,
> Chanop Silpa-Anan wrote:
> > tis620-0 is the offical one. please patch the code I'll try the mlterm
> > soon. I think it is the same as tis620.2533-1, just the naming that is
> > different.
> Thank you very much for your effort. However, I found that tis620-0
> font is slightly different from tis620.xxxx-x fonts. Combining characters
> in tis620-0 fonts have negative expand (i.e., glyphs are written leftward
> from the specified location) while all characters in tis620.xxxx-x fonts
> are exactly fixed-width. Can we rely on the structures of fonts?
I think the "negative expansion" is something unrelated to the encoding
fields in XLFD. Rather, it should be distinguished using the XLFD spacing
field: proportional/monospace/charcell. The -p- fonts are allowed
to have negative expand, while the -m- and -c- fonts are not. (Well,
I know there exist Thai fonts of -m- or -c- categories that still
have negative offsets. That's not the right thing. We try to fade out
the adoption of such hack soon.)
I think xterm and emacs approaches are interesting. They rely on -c-
fonts in rendering Thai on the screen matrix. And xiterm+thai should
be fixed somehow to follow this, so that the fake monospace fonts can
For the time being, we can rely on tis620-0 fonts provided by ETL.
They are true -c- fonts provided for emacs. :)
Information Research and Development Division, NECTEC