Quick Primer on Unicode
Hi Ed,
Thanks for your reply.
I don't like Windows at all, Microsoft or otherwise --too complex, too
incoherent-- but this Windows 98 machine was a gift from Priscilla.
I�m glad to hear utf-8 is being well supported. Lord knows, it's about time.
I've priced Linux desktops, really quite reasonable: $500 shipped to my
doorstep, keyboard, monitor, complete with a printer from Walmart. Linux
laptops start at around $1,000.
I'm interested in the "El Cheapo".
Your web page is excellent, very informative. Be careful: don't mess with
perfection.
I still have to read the part about fonts. Remember, I'm only interested in
non-X, console fonts.
How about a utf-8 text console?
Mlterm!
Elvis
PS
I was looking for your 'mlterm.png', because it didn't print on my hardcopy. It
looks graphical to me, framed in an X window. I was hoping it would run as a
virtual console, without the support of X, a true utf-8 terminal emulator, with
only enough graphics to support font operations, very simple, fixed pitch
fonts.
In other words, can I run Mlterm as a virtual console, through a utf-8 style
tty?
(Did tty devices ever do right-left processing? How did the Chinese enter text
back in 1965? What about top to bottom, and vice versa, does it make a
difference? I'm wondering what a shell command would look like in a mixed-mode
tty, you know, the command in English, the file names in Chinese.)
No, it didn�t make a difference. The direction of the tty is not an issue,
because the teletype writer, an invention of western civilization, by
definition, only works left to right, one 'line' at a time.
Could you imagine typing from top to bottom? You'd have to reverse the
orientation of the paper spindle. It would unroll from right to left. /Carriage
Return/ would move the print head to the top of a page. You'd need a /Column
Feed/ control to advance the paper.)
Keyboard maps for mlterm would make sense, because the map belongs in the
terminal emulator, not in the editor (as you describe when you discuss 'vim'
and 'Yudit'). I know, this is a pragmatic issue, but there are too many
keyboard maps, in all the wrong places. I'm only interested in console-mode
vim.
(Is Yudit included in the standard distribution?)
Of course, console-mode 'vim' could have right-left and up-down editing modes.
Nor does the keymap belong in the kernel keyboard driver, well, it did, once
upon a time, back when there was only one console. Now it seems to just get in
the way.
(Hey, here's an idea: What if we made people compile a keymap file using gcc?
That would get rid of that aweful configuration language (I'm taking a page
from the Microsoft playbook: a keyboard driver is a DLL. Only you need to buy
their Device Driver Development Kit to do it.)
No, you still couldn't do it. How would you parameterize the scanner?
Answer: you'd need a configuration language. A DLL is more than just an array
definition.)
"Keyboard maps are insufficient for typing CJK..."
You answered another question I had. CJK input methods must be more like
handwriting, than typing. Do they use a stylus? Input methods can be graphic
too, like fonts. I've never actually seen a CJK input method (just curious). I
guess the number of shear number of keys becomes overwealming. Let me google
Mike Fabian's page.
I'm beginning to get the idea of 'locales'. You need to parameterize all I/O
routines involving "characters" (and "strings"), like scanf(), printf(),
getchar(), putchar() etc. so that a program compiled on a Linux computer in
France will run correctly on a Linux computer in Greece, where a different
character set may be involved. This is done using environment variables.
But, you'd still have representation problems, since only the ascii portion of
latin-1 and greek character sets peacefully coexist, I mean, you just couldn't
put accented latin vowels in a stream destined for an ISO 8859-7 locale, could
you?
Not without language translation of the stream. Translating messages from
French to Greek would imply a change of character set, and the text would come
out looking right, but I don't think standard I/O does that yet.
It could, with message maps.
With Unicode, that part of the locale (the charset) becomes irrelevant, even if
the messages appeared in their original languages, which is better than
expleted deletives, like "[EMAIL PROTECTED] *&%^65".
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
