[etoys-dev] Re: OT: Unicode vs ISO-2022-JP (was Re: Fonts)

[Yoshiki Ohshima]

At Tue, 4 Aug 2009 15:49:42 -0700,
Edward Cherlin wrote:
> 
> On Mon, Aug 3, 2009 at 9:25 PM, Yoshiki Ohshima<yoshiki at vpri.org> wrote:
> > At Mon, 3 Aug 2009 19:20:45 -0700,
> > Edward Cherlin wrote:
> >>
> >> >  Mine is rendering and retransmitting Japanese mixed with Hangul
> >> > correctly in ISO-2022-JP-2 (defined in RFC 1554 and supports mixed
> >> > Japanese and Chinese text nicely).  As Bert wrote, if you are reading
> >> > it through the forums gateway, that may be the problem.
> >>
> >> Can you send to this list in Unicode? A lot of software doesn't
> >> support ISO-2022-JP correctly in any form. It is a large and complex
> >> standard, almost never implemented in full.
> >
> >  There are a fewer software that supports ISO-2022-JP-2 for various
> > reasons, but it is still a member of ISO-2022 family, which a
> > reasonable emailer should support.
> 
> That's like saying a Python 2.6 interpreter should be happy with
> Python 3.0. Nobody supports all of ISO-2022. And as far as I know,
> nobody outside Japan supports this particular insular national
> non-standard.
> 
> http://unicode.org/faq/han_cjk.html
> Q: I have heard there are problems in Japanese and other East Asian
> mapping tables. Where can I find information about these problems?
> 
> "Sometimes the standard is ill defined, and each vendor has a choice
> in how to implement the Unicode mapping table...Implementations of ISO
> 2022 encodings like ISO-2022-JP differ not only in the mapping tables
> for the sub-encodings but also in the supported sets of escape
> sequences and their invocation pattern."

  Yes, as the answer to this "Q" describes, the Unicode consortium
does not and cannot provide the standard mapping table and round-trip
conversion is not guaranteed.

> > And, because vast majority of
> > (pretty much "virtually all") email traffic in Japan use ISO-2022-JP
> > (which is the standard anyway);
> 
> Not any more.

  Well, just looking at emails in my inbox, it is still the case.

> > so I'd send emails with some Japanese
> > characters in ISO-2022-JP.
> 
> Regardless of whether the rest of us can read them? And regardless of
> the fact that Unicode UTF-8 is the international standard?

  But ISO 2022 is an international standard, too.

> > And
> > anybody who wants to talk about the glyph differences in Japanese and
> > Korean (if "plain text" is preferred) would get better results with an
> > emailer that supports ISO-2022-JP-2.
> 
> Nonsense. You can't claim that you can reliably see glyph differences
> in plain text, when you don't know what fonts the recipient uses. When
> you want to discuss glyphs, send pictures.

  Well, I just wrote "better results".

> All right, now I claim that *you* are an unwitting member of the
> cultural conspiracy of Japanese Supremacists, for insisting on
> national standards over the international standard in an international
> discussion. You have been misled by the Japanese Ultranationalist echo
> chamber.

  Whoa.  Can you also help Etoys development, too?

> >> How widely is ISO-2022-JP-2 implemented? I have never heard of it
> >> before. Certainly Firefox does not support it separately from
> >> ISO-2022-JP.
> >
> >  It doesn't have to be separated entry for ISO-2022-JP and
> > ISO-2022-JP-2.
> 
> Nonsense. They are _different_.

  I'm saying that in the menu for choosing encodings they don't have
to be separated, as one is a super set of another.

> > If you save my email as it is to a file, open the file
> > with Firefox by specifying file://... and change the encoding to
> > ISO-2022-JP, Firefox certainly display it correctly.
> 
> Absolutely not. I tried it. And it is completely foolish of you to
> claim such a thing without evidence.

  How can you be so sure?  See the attached picture.

> >> > But you know that there is discrepancy between
> >> > Unicode claim and practice.  Like the round-trip conversion guarantee,
> >> > when the Unicode consortium cannot provide a standard mapping table and
> >> > the claim is false.
> 
> I have sources that say otherwise. What is your source?
> 
> http://www.unicode.org/faq/han_cjk.html
> Q: I have heard that UTF-8 does not support some Japanese characters.
> Is this correct?

  This is a wrong "Q" in the list, but in another "Q", it does say
that there are different mapping tables.

> The non-kanji in JIS X 0208 also correspond to their own code points
> in the BMP.

  And the mapping is not unique in some of these tables.

> >> The round-trip conversion guarantee does not include all prior
> >> standards. There is a list. You would have to provide specifics (which
> >> we could better discuss offline) for me to comment on the details.
> >
> >  Hmm.  JIS X 0208 was the national standard and predates Unicode.
> 
> National, yes, standard, not exactly.

  Huh?  JIS stands for "Japanese Industrial Standards".

> >> >  But anyway, the discussion here is whether you can tell the
> 
> CJK
> 
> >> > languages supported by a font by looking at its name or not.  And
> >> > answer is no.
> 
> This turns out not to be the case in the case of Chinese, Japanese,
> and Korean that I was talking about. Actually, it is Yes on Linux and
> Mac, No only on Windows.

  On what Linux?

  You can just tell this is not true by looking at:

http://www.wazu.jp/gallery/Fonts_Japanese.html

Are "aqua", "cinecaption", "Heart", "Mona", etc. are Japanese?

-- Yoshiki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firefox.png
Type: image/png
Size: 68931 bytes
Desc: not available
Url : http://luna.immuexa.com/pipermail/etoys-dev/attachments/20090804/4b61f30d/firefox-0001.png