Re: Typing Right-To-Left language characters in GtkEntry

["Edward H. Trager" <ehtrager umich edu>]

On Thursday 2005.06.09 14:43:20 -0400, Behdad Esfahbod wrote:
> On Thu, 9 Jun 2005, Edward H. Trager wrote:
> 
> > Just a little note I would like to add here: mlterm (http://mlterm.sourceforge.net)
> > is the only terminal emulator I am aware of that seems to work somewhat OK for Arabic
> > (for example, you can use the terminal version of vi or vim to edit a document containing
> > Arabic.  As far as I can tell, one has to more or less stick with using the bitmap GNU unifont
> > in order to maintain legibility in the terminal, but it does seem to work).
> > It would be nice if Gnome's gterminal or KDE's konsole could handle
> > Arabic and other complex-text-layout (CTL) scripts.  Have others had this wish too?
> > I have a partial idea of what some of the issues are, but I'm sure my understanding of these
> > issues is incomplete.
> 
> That's the last thing I like to see working.  The terminal
> emulator is simply not receiving enough information to apply
> the bidirectional algorithm correctly.  Vim, Emacs, ncurses,
> slang, etc should implement CTL inside if they want.  A very
> simplistic bidi support can be implemented in the terminal, which
> is what mlterm (and BiCon to some extents) do.  That works when
> you are sending an stream of characters to the terminal, but as
> soon as escape-sequence tricks start, it fails miserably.
> 

Hi, Behdad et al., 

Well, think about the problem from a purely practical standpoint of how things in
an *ideal* operating system *should* work.  Now of course "ideal" is horribly subject
to interpretation, so I'll just say that my definition of "ideal operating system" includes
both a command-line terminal interface (CLI) and GUI (which are both present in the OSes of today
such as Linux, Mac OS X, FreeBSD, etc.).  If you don't like the word "ideal", we could substitute
the word "more perfect" ... .  In the OSes of today like Linux and OSX, I can manage files 
with non-Latin-script file names pretty easily using the GUI-based file management tools, but, unfortunately,
not nearly so easily using the CLI.  This is a shame, because when I manage Latin-script file names,
I can easily take advantage of the respective power and advantages of either the CLI or the GUI as I
so choose, with no limitations (other than the limitations of the GUI or CLI itself).  But for non-Latin-script
file names, using the CLI suddenly becomes quite limiting. 

Now, if I had no point of comparison, I wouldn't complain.  That is, if the CLI exhibited the same limitations
for Latin file names as for non-Latin file names, then I'd keep my mouth shut.  But that's not the case.  As
any experienced *nix user knows, and as quite a number of inexperienced Linux and OSX users are discovering every
day, the CLI is extremely powerful for all kinds of file manipulations.  As a human, I have no trouble
dealing with one script versus another, so why can't the computer's CLI deal with different scripts as easily
as the GUI does?  You see my point.  To the average user, it makes no bloody sense.  And maybe I'm not
the average user -- which is perhaps why I can say : it is wrong.  It is broken.  It needs to be fixed.

In summary, I agree with you that vim, Emacs, ncurses, and slang should, in an ideal world, also have good
bidi support for Arabic and other semitic scripts, as well as good CTL support for Indic and Indic-derived
scripts too.  But, at the same time, in an ideal world, the CLI would have equivalently transparent support
for all scripts.

- Ed Trager
Bioinformatics, Kellogg Eye Center
Univ. Michigan, Ann Arbor

> 
> --behdad
> http://behdad.org/
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
> 
>