On Saturday, March 30, 2002, at 03:24 , Dan Kogai wrote:
Okay. I've checked
http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/
One more time and it seems that other missing encodings are available
as well, such as korean. I'll look into that.
I think I have found the reason why some of the encodings were missing
from Tcl's *.enc, which later turned into *.ucm.
Apple makes use of Unicode compound characters too extensively, which
doesn't go well with .ucm, not to mention *.enc
http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT
# Apple additions - vertical forms
0xEB41 0x3001+0xF87E # vertical form for IDEOGRAPHIC COMMA
^^^^^^Mac Japanese, then Unicode Character
Encode/macJapan.ucm
<UF8B5> \xEB\x41 |0 # Private Use
So they are already conflicting. While MacJapanese doesn't have many,
MacKorean does have lots of them. No wonder it is not listed on Tcl.
I wonder which one I should trust but I have reasons to believe Apple
is still considering the map @ unicode.org canonical. Take HFS+, for
example. The word 'Hangul' consists of two syllables, two characters in
KSC5601 (han-gul). But on HFS+, it is broken up to h-a-n-g-u-l.
Though it is possible to mangle enc2xs to make such mappings (it can
handle, in theory, any nbyte-nbyte conversion), the UCM format does not
seem to be designed that way.
Hmm.... Let me think about it for a while... Well, it's only vendor
mapping and Encode support has already matched that of major browsers.
So it is already practical enough and I believe the level of support is
good enough for 5.8.0. Maybe those vendor mapping that are missing be
diverted to Encode::Vendors::(Apple|MS) or something....
Dan the Encode Maintainer
