Re: tlug: Re: Japanese input

["Matthew J. Francis" <asbel@example.com>]

On 12-Jun-98 Stephen J. Turnbull wrote:
>      Matt> What I meant was, that unlike with the multitude of
>      Matt> old-style national-language charsets, with Unicode you can
>      Matt> say "Give me Chinese input" and have input turned into
>      Matt> Chinese-in-Unicode,
>  
>  But there is no such thing as Chinese-in-Unicode without locale
>  information.  Just Unicode.  I don't know that that's not good enough;
>  but I don't think it's necessarily "Chinese", especially in a
>  multilingual context.

That is more a problem of things other than input, such as rendering. I'm
aware of, for example, the slight font differences between the relevant
east Asian languages WRT the unified Han code-points.
  One solution to this could be the language-tagging method specified in
Unicode Technical Report #7 (available from unicode.org). I do think this
is a problem that needs shaving carefully with Occam's razor, though.


>      Matt>   1. A somewhat "smart" text renderer, with a set of
>      Matt> defaults for how different codepages are displayed
>      Matt> (e.g. "English l->r, Hebrew r->l, Japanese r->l and vertical
>      Matt> with breaking every 20 lines"). If that is really
>      Matt> insufficient control, then...
>  
>  Hebrew, unfortunately, is not r->l.  It's bidrectional.

Ouch. Is that bidirectional as in "Can be written either r->l or l->r",
in the same way that Japanese can be written either horizontally or
vertically, or "Always both r->l and l->r", as in Boustrophedon?
(Or something even more awkward?)


>      Matt> (1) would correspong to the existing sort of "text edit
>      Matt> control"; if you need to do something more than the
>      Matt> simplistic markup it would provide, then you have need of
>      Matt> something more like a Word Processor.
>  
>  Arabic.  Devanagari.

I know a (very) little about Arabic, but can you please enlighten as to
what problems lie with Devanagari?

I see mutterings in various places about a supplied sample algorithm
for marking up text of varying direction, but as I don't yet have the
Unicode book I can't comment on that. In general, I think that if someone
wants to use languages of varying direction together, there will be
some way to figure out a good markup automatically; and, if there is not,
then there just won't be a sensible way to do it.


>      Matt> Almost everything other widget worth consideration is
>      Matt> basically a container of either Labels or Entries.
>
>  The issue here is that from a QC standpoint, _all_ widgets are worthy
>  of consideration, and are you really sure they all use labels?

Now looking closely; this does appear to be true for GTK's built-in
widgets (There are relatively speaking few enough of those anyway). I
don't see why it shouldn't also be true with Qt and Motif.

Considering that programs (not including Emacs) which choose to display
and input text in non-widget-set ways are quite probably less
internationalis{ed,able} than most even now, the QC burden is mostly
theirs rather than the widget set's. Although it would be nice if
everyone's QC problems were solvable in one stroke, I suggest no such
thing.


>  If you don't get that, then projects like XEmacs are not going to use
>  the widgets; better we live with and incrementally improve the poor
>  man's widget set we've got, than introduce a whole new set of
>  compatibility issues.

As far as I can see, (X)Emacs is unlikely to move to a general
widget set in any case, at least in the forseeable future. As you say,
they prefer the solid stability of their custom widgets.


[Emacs]

>  As for unportable ... XEmacs can be configured as a widget which can
>  replace most text widgets.  Hmm....

Yet strangely enough, I don't see anyone doing that. Whether it's not
what people want, or genuinely just through lack of good PR I couldn't
say.


Cheers,
-Matt.

"The results of this intrusion into your life will be used 'responsibly'
in ways you cannot even begin to imagine. Of course, the innocent have
nothing to fear from the rapidly expanding data industry."
 - Radiohead, Airbag/How Am I Driving?

--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
After June 13, the next meeting is 8 August at Tokyo Station
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp