Hello-

Two comments/questions:

1)

> > UNICODE is a character encoding ...
>
> Wrong.  Unicode is not a character encoding.  There are many different
> character encodings which are used to encode unicode, notably utf-8,
> ucs16 and perl's own utf-8 like encoding.
I was not aware that perl's encoding is "UTF8-like".  How does it differ
from regular UTF8?  Do any potential problems result?


2)

A big problem in Win32 browsers for multi-byte encodings, including UTF8,
(MS and new netscape, although not old netscape) is that
you cannot copy characters out of the browser.  (MS seems to copy
into Word, but all my other programs receive question marks).

> > Not really. All M$-Win32 browsers support UTF-8 flawlessly.
>
> I'm glad UTF-8 display is working well for you. Unfortunately, we have run
> into a few UTF-8 bugs in Netscape Navigator which were a problem for our
> application. I hope it's not too much off-topic to list the two
> big ones, in
> case other readers run into them also:
>
> - There are some non-negligible setup issues (nicely detailed in
> one of Alan
> Wood's Unicode Resource Pages,
> http://www.hclrss.demon.co.uk/unicode/netscape.html). Unfortunately, you
> have to set up a *single* "unicode" font for dealing with all characters,
> whereas most machines just have fonts for specific scripts lying around
> (i.e., a font for Japanese, a font for Korean, etc.) If you select a
> Japanese font for Unicode display it will work fine for Japanese and other
> characters in the font, but won't be able to deal with Korean or other
> characters which aren't included. Netscape misbehaved and crashed
> a lot when
> I tried to get it to use the huge Microsoft Unicode font with all of the
> characters.
>
> - Text input boxes in forms only accept characters in the "ANSI"
> system code
> page. You can't enter or edit Japanese data, even if you can display it.
>
> IE5 does not have these problems and, of course, it's much more stable. If
> you (and the browsers viewing your pages) can stick to IE5, UTF-8
> shouldn't
> be a problem.

Mark Lewellen

Reply via email to