Re: Thai/Devanagari in GNOME Terminal

[Chookij Vanatham <chookij vanatham eng sun com>]

Robert, Ralph, Steve,

Here is my input but quite a bit long.

] 
] > Since I'm native Thai person, I can share some information about how
] > Thai script works in Terminal emulator.
] 
] Have you tried the Thai support in xterm? As far as I know it's
] acceptable, but we'd like more feedback...
I'm going to test it out and provide feedback.
Just in case, if you can give me the quick point to download it
and, for sure, I have only Solaris to test it.


] 
] > In term of, bidrectional script like arabic/hebrew, I think we should
] > check how their bahaviors would be first. May be someone from native
] > language can give us more info like I did for Thai.
] 
] Again, this is apparantley working fine in xterm without recourse to
] pango. (At least our native Persian speaker is happy, barring a few minor 
] bugs)
Is this xterm the same one supporting Thai ?


] 
] > Like Robert says, it's not necesary to be highly complex, and,
] > at least, I will be able to use "vi" or other tty-based applications
] > running well with Thai/Arabic/Devanagari... in gnome-terminal.
] 
] It might be interesting to try to adopt the shaping code, but the only 
] thing in modules/ that xterm doesn't already support is Devanagari.
] 
I think it would make sense if terminal uses pango for shaping.


] I don't know. I've been wanting a terminal that would do proportional
] fonts for years. It seems to me if we can afford semi-transparent
] backgrounds in our xterms, we can afford to apply some layout heuristics
] to the content. =)
I think, using proportional fonts in terminal emulator would make a lot of
things harder to do.
Do we really need to use "proportional fonts" in terminal emulator ?
I would say "no" but I like to hear other opinion too.

Regarding the vowel/tonemark/diacritic of those complex text script
(Thai/Devanagari) and also ligature of devanagari script, here is what
we do in Thai terminal emulator.
The cursor (black box) for those vowels/tonemarks in terminal emulator will
be displayed at the same position (x,y position) of their own display cells
(cons+vowel, cons+vowel+tonemark). Then, let says, we use "vi" to edit
Thai text, the black box cursor will not move if those vowel/tonemark are
combined with consonant.
This idea I think we can do it for ligature shaping for Hindi as well.

Just point out that, these vowels/tonemarks glyph (when they combine
with consonant), their glyph widths will be zero. This is a bit different
than the case of proportional font from my opinion.

] Tab stops are easy, of course. Too bad no one uses them 'properly' in this
] sense. Word-justifying so you get the proper number of characters per line
] makes tables readable but looks terrible. Reliable identification of
] indents and columns is probably too much to ask, but for mixed text,
] roughly fitting the proportional bits (like arabic or hindi) into the box
] they "should take up" if they were rendered fixed might work ok.
Regarding table/tab stop, in Thai terminal emulator, we use this method
to make sure that table/tab-stop are still rendered correctly.
This method we call "compensation". Here is the detail.
We know that vowel/tonemark cause the table shrank. Terminal provides
2 things. One is called "trigger string" and the other is called
"compensate character". The idea is that, in each line, the terminal
emultor is scanning for "trigger string". If it has been found, the
terminal will insert "compensate character" which is usually "space"
after "trigger string". Trigger string can be the sequence of 2 spaces
or any special code where we want "compensate character" to be added.
After adding compensation character (space), the table will not be shunk.
If the terminal displays 2 columns of data which are seperated by space.
Then, the aligement of 2 columns are still ok.
(This is not garantee 100% but mostly, 80% or more and acceptable).
The thing needs to check more is about "ligature" because this is
N-1 relationship so the number of compensation characters should be counted
differently.

] Everywhere I have been so far I have found dumb terminals working in
] either a font all of one size, or a combination of two related sizes
] (e.g. single width Latin mixed with double width Chinese). I saw a number
] of ISCII dumb(ish) terminals in India which worked this way, supporting
] multiple Indian languages. Someone told me there are variations of how
] these work, though. There is a code in India called ISCLAP, which was
] developed for paging, and codes precomposed cells, instead of the phonetic
] elements. For various error tolerance reasons, having 5000 precomposed
] cells in better than a small set of phonetic symbols. There is a similar
] code for Thai paging. I was told that some dumb terminals use a similar
] code, but I never followed up on this.
Let me know if I can find more information on this. I'd like to check it out.

] > >From my (not very long) exprience with working on terminal emulation
] from
] > Windows with bidirectional Hebrew support, and similar programs, it will
] > probably can never be perfect. For instance, in many cases there is no
] > good way to determain the base directionality of a piece of text.
] 
] This is what RLM and LRM are for. :) Also, we plan to have an override in
] a popup menu.  But for light use, it will be fine.
That's right. You can control direction by using RLM/LRM/RLO/LRO....

] > Furthermore, the application running in the xterm may have a real
] > bidirectional support. Therefore the terminal emulation should make it
] > easy for the user to disable the bidirectional support. They may be less
] > important for other proggrams, but a terminal emulation basically
] > displays the output of other programs, and not much more.
] 
] Indeed, this is why there are some "disable/enable bidi" control sequences
] that I will soon implement.
Wow!!! This is the good idea. Let me know more info about this.

Chookij V.