Following is a post made by Elias Martenson some time ago.
This little tidbit of information does not seem to be in the ncurses
manpages, and isnt easy to find on google. I think it would be
nice if it was included in or linked to by popular UTF-8 FAQ's such
as Markus's one.
~
Yes, I agree.
With some cleanups as such, the gist of Elias's post would make a
worthwhile
addition to the utf-8 faq, imo. Also, if it could somehow be added to
the ncurses
manpage that would be a good place too...
If you want to use UTF-8, you're pretty much done! Just work with
1) A gcc based RDE called Dev-4 C++ for Windows 98.
There are bootable CD-based distro's if you cant install one normally.
2) gcc running in the cygwin emulator. I can't seem to make vim do anything
reasonable, so I create the utf-8 file in Windows using Word 2000 (or UniPad),
and copy it
the MS-IME for Japanese seems to support unconversion. (when some text
is highlighted and the conversion key is hit, the text is returned to
candidate selection mode.)
Ive looked into the Canna conversion server, it doesnt seem to support
any unconversion of kanji characters. I dont know if
For the (aspirant) multilinguals among us, I would say no. The ability
to change input methods on the fly, halfway through filling in a form,
is somewhat cruicial.
(For this, xim seems to be mostly useless.)
It's already been stated that you can specify GTK_IM_MODULE=xim in
your environment,
Iconv is just clumsy. You can't even make (sane) wrappers to do this
stuff. It's as if it were designed by people just converting big chunks of
raw text. Maybe it's just me but I'm not seeing that in real world apps.
On the other hand, the iconv API is more flexible the way it is. It
can
(To avoid confusion, we don't call our encoding UTF-8. We tend to
say UTF-8 when we mean UTF-8, and utf8 when we mean the more general
not-necessarily-Unicode encoding.
This is an insane way to make a distinction, just as silly as trying to
differentiate between kilobits and kilobytes with
If you see html lang=ja then the page should use the font
specified by the Japanese setting by default. [..] Encoding
is fairly irrelevent to this, afaik
http://ken2403king.kir.jp/form.htm
Thats a funny one, indeed. When I opened it in Mozilla it was
displayed as .For a moment I thought
I recall that we had about two years ago heated discussions here on
whether UTF-8 support should be implemented by
a) hardwired mechanisms fully optimized to make good use of UTF-8's
neat properties
b) relying entirely on ISO C's generic multi-byte functions, to make
sure that even
Sometimes I get e-mail messages in utf8 from M$ clients. This fails.
Have others seen this? How to fix??
As a previous user of outlook in a corporate environment, I can verify
that it
does seem to perform a corrupt on send action whenever the encoding is
utf-8. Even the copy in the saved folder
10 matches
Mail list logo
