On Fri, 13 Jul 2001, Carl W. Brown wrote:
Carl,
> > and I'm sick and tired
> > of receiving Windows-1252 messages *mislabelled* as ISO 8859-1 with
> > proprietary extension characters that are not supposed to be sent along
> > the wire in messages labelled as ISO 8859-1.
>
> Just wait until 1/1/2002 when many people will be caught napping and the
> Euro takes affect. iso-8859-1 will be obsolete and windows-1252 (revised
> code page with the same name) and iso-8859-15 will be the proper code pages
> to display the Euro sign (At different code points of course).
I have nothing against using ISO 8859-15, but I have some reservation
about Windows-1252 getting leaked out in the wild (I'd rather make
Windows-1252 converted to UTF-8 or ISO 8859-15 before sending it out to
the wire). Anyway, I have to live in the real world where Windows-1252 is
used widely and it's fine as long as Windows-1252 is properly labelled
as such. What makes me annoyed is that programs like Eudora lie about
MIME charset (i.e. it declares it's sending out ISO 8859-1 while it
actually sends out Windows-1252).
> > version, but even MacOS version is far behind other mail clients like
> > Mozilla/Netscape6/Netscap 4.x and MS OE in terms of I18N.
> Last year I worked on a project where we gave up sending UTF-8 HTML code
> pages because Netscape 4.7 did not properly support UTF-8 and Netscape 6.0
> was not out. This was a Korean web site and Netscape 4.7 could not handle
> Korean UTF-8.
> UTF-8 support in Netscape was a hack. It took rewriting NS to support
> Unicode natively to get decent UTF-8 support. UTF-8 pages can be
Hmm, are you sure? Netscape 4.7 can handle Korean pages in UTF-8
as long as you limit Hangul syllables to the repertoire of KS X 1001
(2350 of them). Of course, I agree that NS 4.x was not written bottom
up for Unicode support and its UTF-8 support is kinda hack and that
Mozilla/NS 6's Unicode handling is much smoother than that of NS 4.x.
> multi-lingual. To try to support UTF-8 pages with a code page based product
> is borderline insane. To make it work you should use Unicoded encoded fonts
> and therefore must write test in Unicode. You must have script detection to
> determine font selection. This is why NS had to be rewritten and IE which
> was Unicode to begin with, handle UTF-8 and many others don't.
I agree with you on most of points, but it's not so insane to support
Unicode and many other encodings with non-Unicode-based *fonts* (with
Unicode at the hub/center of implementation) as shown by (Solaris and)
Mozilla in a sense. Especially, it's reasonable thing to do when there
are lots of non-Unicode-based *fonts* distributed and used everyday by
target users. This is not to say Mozilla does not use Unicode-based fonts.
It makes use of both of them.
Jungshik Shin
