Re: tlug: Re: Japanese input

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Matt" == Matthew J Francis <asbel@example.com> writes:

    Matt> On 11-Jun-98 Stephen J. Turnbull wrote:

    >> You can use Unicode/UCS-[24] internally if you want.  This
    >> simplifies a lot of things.  However, a monolingual Chinese
    >> will find a Japanese input method useless.  So input cannot be
    >> `uniquely specified without "knowing" anything about locales.'

    Matt> Natch, that's not quite what I meant.

I don't think what you meant is quite coherent in the face of the real 
problems.

    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.

    >> Also, some such information _absolutely must_ be included, for
    >> bidirectional languages (Semitic, mostly, but also vertical
    >> Japanese, most probably).  This is emphatically not a "locale",
    >> but the handling will have some similar elements.

    Matt> Agreed that makes for a very tricky problem. The closest
    Matt> solution apparent to me is twofold:

    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.

    Matt>   2. A "richer" text widget, with facility for control
    Matt> information about how to render different languages and
    Matt> texts in arbitrary ways.

Arbitrary.  Hm.  Sounds like Xlib to me.  We don't want to go that
far....

    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.

    Matt> Are there standards related to this sort of thing already? 
    Matt> (and if not why not?) I definitely don't want to end up with
    Matt> just another set of incompatible extensions for embedded
    Matt> text markup...

ISO-10646 Level 3, Unicode.  There are combining characters and
directional characters in there.  Everybody I know hates them but
doesn't know how to get rid of them.

    Matt> Almost everything other widget worth consideration is
    Matt> basically a container of either Labels or Entries.

    Matt> What exactly is in the labels is a slightly different
    Matt> problem, but gettext, for example, shows you can at least
    Matt> make a framework to help.

The issue here is that from a QC standpoint, _all_ widgets are worthy
of consideration, and are you really sure they all use labels?

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.

    Matt> This has the of course the reverse effect that even as
    Matt> "general" methods are generally unportable to Emacs, Emacs'
    Matt> own solutions are unportable from it. For better or worse,
    Matt> almost noone else uses elisp...

Well, of course not.  There is no Emacs, just E-Lisp.  Or conversely,
the E-Lisp interpreter is Emacs, they are inseparable.

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

    Matt> To reiterate once more, I'm not arguing that the bullet is
    Matt> silver, but that at the moment we are *firing
    Matt> blanks*. Whether or not there is one perfect solution to all
    Matt> the evils of i18n, m17n, l11n is irrelevant, and not to be
    Matt> used as an excuse for not trying to improve matters.

I disagree that we are firing blanks.  In an open-source, open-network
environment, we cannot take the MS attitude that interoperability
doesn't matter.  I know that you don't intend slighting that; I
disagree.

There was another eruption of the "WTF XEmacs doesn't use a standard
widget set" flamewar on the XEmacs beta list.  Basically it comes down 
to the fact that all of the candidates are far less robust than XEmacs 
can afford at this time.  They all have fatal design flaws that make
it impossible to use in XEmacs in the time frame of the next release
or two.

They may be not be design flaws outside of the Emacs context; I don't
really understand the issues (they're typically buried deep in the
event loop).  But if you can bring either Emacs on board, you've
suddenly got half the world using your widgets.  (In any case, half
the world that's capable of helping make them better.)  But it's not
going to happen at the current state of the art.

I see this as an argument for breadboarding at a high level as opposed 
to fixing things in stone in low-level widget sets.

--------------------------------------------------------------
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