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

Wed Aug 5 00:15:06 EDT 2009

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 Ohshima<yoshiki at 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 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.

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 at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>

-- 
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.org/worknet (Edward Mokurai Cherlin)