Re: The Future of Linux: 'real' Locale support from X libs or no?
At the risk of reviving a very quickly-quiet thread... I've still an
interest and have acquired some opinions around our software house.
On Thu, Nov 12, 1998 at 01:37:05PM +0000, Alan Cox wrote:
]>Glibc is good, but what about wide char, unicode etc.. etc.. etc.. ad biggum.
] Glibc does wide char, ncurses seems to imply it does (I've not
] checked yet).
Wide Char is good for Motif and several other apps. The main things I've heard
are that
1) We haven't tested against a widechar which solves all our problems
2) *MOST* of what's needed has to do with Unicode, Multibyte or other
Asian-font/encodings, ones outside standard ISO8859.
The general idea (I'm representiong our CDE developer here) is that widechar is
an internalized format, one made for keeping some *specific* language data
encoded for internal ("strlen, strcmp" etc..) use. It is *not* however an
actually international solution.
Now one can easily look at the widely international nature of Linux and see
that ISO8859 (ASCII+european-accented-roman+updowncases-of-3-new) has done
almost all the work.
Chinese, Japanese, Russian, Arabic, Israeli, Indian people simply use English,
or a rather unhelpful bastardization of simple ASCII (Some Chinese put "1-4"
to indicate tonality of their roman-spelled syllables). Even Greek isn't
supported except with a font-replacing-ASCII-chars.
The question is, therefore, whether work is being done to get a good
standardized mapping from any of the above sets into a narrower widechar.
Jon Trulson, the CDE man in our office, says that he only wants certain
specific calls that allow quick manipulation of multibyte. Even a
reasonable mapping system may start to qualify Linux as an Earth OS. |->
] > toward. Is there any interest in what we have thus far at Xi?
] Well I know the currnt KDE doesnt handle 16bit Glyphs, Im not sure about
] the Gtk toolkit on that.
No idea, myself.
] > (hint to some: code pages work only for vts)
] Depends on your Xterminal and fonts ;)
I will say this: maintaining an 8bit string system makes a bleeping lot of
sense. All that's needed is mapping at any user interface. Presenting easy
ways to 1) get the right glyphs to your display and 2) input horridly
obscure ideograms via simple means and 3) get them changed into a unicode or
other highly-interchangible sequence of bytes... would make developers sigh
with relief.
Now, again, X is the one environment which is really able to do 1) and
handles 3) for us within our (recently obsoleted) "Xintl" library. The
ability to present all three would be very very attractive and could keep
Linux as the "sensible" alternative instead of the
syrupy-sweet-costly-kludge of MS.
] The kernel itself uses UTF8 for file names so you can reasonably keep
] a Klingon ext2fs if you wish.
8-o. You are a sick man. :-B. That makes an interesting mental picture:
"Ka'plach% bash -xv MyEnemiesHead | ./meatGrinder > aStakeOfVictory &"
"Ka'plach% kill %1 "
"Ka'plach% kill -9 %1 "
"Ka'plach% kill -WithExtremeViolence %1 "
"Ka'plach% shutdown -r now 'I must crush this defiant process'"
"Ka'plach% @#@#()*$&@)( "
"Ka'plach% sync ; sync ; sync"
Okay... Oracle humor over.
Reply to: