As is commonly the case in such discussions, you have ignored all of my real points and chopped logic on your own. So there seems to be no point in discussing this further.
On Tue, Aug 4, 2009 at 5:01 PM, Yoshiki Ohshimayoshiki@vpri.org wrote:
At Tue, 4 Aug 2009 15:49:42 -0700, Edward Cherlin wrote:
On Mon, Aug 3, 2009 at 9:25 PM, Yoshiki Ohshimayoshiki@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.
Yes, as the A describes, _nobody_ has a standard mapping table, because ISO-2022-JP is in fact not standardized. That's what the word _ill-defined_ means.
And so on for the rest of your irrelevancies.
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
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev