Re: tlug: Re: Japanese input

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

On 15-Jun-98 Stephen J. Turnbull wrote:

> >>>>> "Matt" == Matthew J Francis <asbel@example.com> writes:
>  
>      Matt>   One solution to this could be the language-tagging method
>      Matt> specified in Unicode Technical Report #7 (available from
>  
>  This is getting on towards supporting locales, don't you think?

Yes, in the widgets. That's tangential, however, to my original assertion
that a general input protocol/server can be designed without any
particular knowledge of the locale of the conversions it serves; it need
not know of locale, only of conversion. Alright, admittedly the line is
a fine one.


>      >> Hebrew, unfortunately, is not r->l.  It's bidrectional.
>  
>      Matt> Ouch. Is that bidirectional as in "Can be written either
>      Matt> r->l or l->r", in the same way that Japanese can be written
>      Matt> either horizontally or vertically, or "Always both r->l and
>      Matt> l->r", as in Boustrophedon?  (Or something even more
>      Matt> awkward?)
>  
>  That last is ancient Greek for writing on stone tablets, ie, r->l
>  followed by l->r so that you don't have to lug those heavy stone
>  chisels and the scaffolding back to the other end of the Parthenon
>  when you do a CR?  ;-)

:). It's also supposed to be a more efficient method for reading
modern languages such as English, presumably due to the time saved by
not having to do a "visual carriage return" to find the start of the
next line. There was a Freshmeat announcement a while ago about a
small proglet for re-formatting ASCII text this way... it's in my
in-tray somewhere as something to try out for a laugh.
  After all, when I resort to pen and treeware it's already as likely
to be in Cirth or Pilot-glyph as plain Roman, so one more aid to
illegibility surely can't hurt ]:)


>  Look at any commercial truck in Japan; it'll be written back to front.
>  On both sides.  :-)  So Japanese, even the modern dialect, is
>  _horizontally_ bidirectional by user preference.

That's true, although not necessarily something that's wanted in a basic
text widget. For similar reasons English is often written vertically on
signs, but it's not something you'd expect to do in contexts less than
WP or DTP; the principle of the text-edit control seems to be that of
"minimum correct markup" to the script.

One very real problem, however, could be the combination of programs
that have been designed with horizontal Entry widgets with languages
that are only written vertically.


>      Matt> I know a (very) little about Arabic, but can you please
>      Matt> enlighten as to what problems lie with Devanagari?
>  
>  Arabic is context-dependent in the sense of initial, medial, and final
>  forms; a good Arabic font contains several thousand glyphs to get the
>  various forms and their joins correct, thus-I-have-heard.
>  
>  In Devanagari, the glyphs combine in complicated topologies like
>  Korean Hangul; it just so happens that within a "syllable" the order
>  is typically right to left, but syllables are ordered left-to-right.
>  I have seen this script entered, and the combining and scrambling of
>  the glyphs is reminiscent of the Kama Sutra.

Implementing that, then, would likely require the close attention of
native writers of the relevant languages. Leaving sufficient flexibility
to allow their implementation, though, should be achievable without.

Are there good Free fonts for Arabic and Devanagari?


[Markup of odd scripts]

>  I think automatic is quite possible.  But...
>  
>  Good and automatic, not soon.  But eventually---and therefore you must
>  plan your protocol for upward compatibility, and in the meantime
>  provide sensible ways for the user to force the desired behavior.
>  
>  Large projects will not consider a widget set that looks like it will
>  need a protocol revision in the near future.

[...]

>  This is true.  What I am saying is that there are large projects like
>  XEmacs that would like to move to a standard widget set, but will not
>  do so unless the QC is shown to be quite high, and the maintainers
>  responsive to bug reports.

These points are good - but we are skipping, I think, a little too far
ahead of implementation. Once there is code, it will stand criticism
of its generality and future-proofness.


>      >> As for unportable ... XEmacs can be configured as a widget
>      >> which can replace most text widgets.  Hmm....
>  
>      Matt> Yet strangely enough, I don't see anyone doing that. Whether
>      Matt> it's not what people want, or genuinely just through lack of
>      Matt> good PR I couldn't say.
>  
>  It's an awfully heavy-weight way to enter name and address in a web
>  browser HTML order form, wouldn't you say?

Yes, I would so say. Something a little lighter-weight is needed...


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 Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 8 August, Tokyo Station Yaesu central gate 12:30
*** 20 June: TLUG will be at the Tokyo Linux Fair
http://tlug.linux.or.jp/projects/linux-fair/fair.html
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp