Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Japanese input (was RE: tlug: Japanese)




Hi,

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

[...]

>  Brother, you are in for some unpleasant surprises :-)  Check out
>  locale (5), o-negai-shimasu.  No silver bullet here.

Hmm, but that seems to relate mostly to the 'traditional' charset
support. Yudit is Unicode all the way through, so character mapping and
input can be uniquely specified without "knowing" anything about locales.
If you meant something else I'm not seeing, please to enlighten...


[Input servers]

>  Nope.  Symptomatic of the fundamental fact that "tastes differ."  In
>  any case, that was an example to demonstrate feasibility.  I think it
>  would be insane to try to overload a Japanese server with algorithms
>  for Devanagari or Arabic.  Multiple servers.

Silly and unnecessary to want to do it all at once; So, throw in dynamic
loading of conversion sets, and I don't see how it could be slower or
more hungry than the existing one-locale servers.


>  Such a server would be just as big as the two put together.
>  Memory-hungry?  For dictionaries, yes.  Incompatible, though, they
>  can't be combined.  No silver bullet here.

Colour me unconvinced, but for fairness I will go and have a *really*
good look at all the code (probably this weekend) before putting my head
more firmly on the chopping block.



[...]
  
>  As Gaspar pointed out, most of the code sucks EGG.  Don't reuse the
>  code (most of it).

Code does of course have an immense memetic (informational) reuse value
as well as genetic (implementational). "Code reuse" can be effected
without necessarily actually using code.


>  Please to reuse protocols.

Ryoukai, hearing and understanding.


[...]

>  Notwithstanding, I am not an expert, I don't know crap about this.
>  Many people in this discussion admit to having read none of the
>  relevant standards (I don't know where you stand).  Some people are
>  ready to jump in and start coding when they don't know the difference
>  between wide characters and multibyte characters, or the difference
>  between LANG, LC_ALL, and LC_TYPE.

I know the limits of my knowledge - although sometimes to start coding
is a very good way to find that out. I am actively researching, although
I can't afford to buy much treeware at the moment; pointers to any
relevant online documentation would of course be greatly appreciated...


>      Matt>  - Working/improving the necessary support into the widget
>      Matt> library text-entry and text-display level would help
>      Matt> enormously. There's no reason this couldn't be done while
>      Matt> retaining support for current input methods.
>  
>  Uh-huh.  I'll believe it when I see it; there's nobody here offering
>  support for such a heavy effort.  Programmers will work on what's fun.

Yudit already *has* this. Even Gaspar's code there as it is now has
both raw XLib, Qt, and Motif versions of the (entry and edit) widgets;
because it's quite cleanly written, it should stand porting to other
toolkits with little fuss.
And who's to say if I find this fun, others can't? =^^=


>      Matt>  - Then some widgets, adding other support as and if
>      Matt> necessary. If the GTK/GNOME/KDE/etc. people find them worthy
>      Matt> of integrating, they can.
>  
>  No.  Some is not enough.  Partial support will _not_ take over the
>  world.  Viz. the Japanese on Netscape on Linux madness.  w3.el under
>  Mule has full multilingual support, input and output.  Why doesn't
>  anybody use it?  Because it doesn't support tables, plugins and the
>  like well, if at all.
>  
>  Specializing to the input issue, people will use a complete widget
>  set; using an add-on widget set where some capabilities are supported,
>  and others not, will drive both developers and users away.  No silver
>  bullet here.

Not a silver bullet, but at least a loaded gun to hand to the developers.
90% or more of text display in typical programs is done with standard
widgets; Entry, Edit, Menu, Label. Replace them with ones that understand
internationalised input and display properly, and you're 90% of the way
there. Make it easy for developers to extend this to new widgeta, and
you're a little closer. Make sure it's easy to switch message languages,
and a little closer still. All these things can be done from within the
widget set...


>      Matt> If you think that's mad, I'll gladly suffer the label. When
>      Matt> I can send mail and write text in any program of my choice,
>      Matt> entering text in Japanese and English, quoting someone else
>      Matt> in Greek, and with menus and messages in Tengwar, without
>      Matt> jumping through hoops, I will rest happy...
>  
>  May we both live so long!

Amen, brother :)
If Yudit can do it, others can too; with a little luck and a lot of elbow
grease, they will. Never said it would be quick...

(Hmm, actually that is one thing Yudit doesn't have, yet - Tengwar
mappings. Where'd I put that Quenya TTF font...)


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


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links