[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 23.0.60; describe-char gives wrong information
From: |
Peter Dyballa |
Subject: |
Re: 23.0.60; describe-char gives wrong information |
Date: |
Tue, 8 Jan 2008 14:06:29 +0100 |
Am 08.01.2008 um 06:55 schrieb Kenichi Handa:
Character U+039F can't hardly belong to a Chinese encoding. It's a
Greek character, taken off an ISO 8859-7 font.
Actuallyy many CJK charsets contain Greek letters. As you
are in de_DE locale, the order of iso-8859-7 and gb18030 in
charset list is arbitrary. Try C-x C-m l greek RET C-u C-x
=. iso-8859-7 should be preferred.
Hello!
I actually intended to emphasise that I was living and working in an
UTF-8 area. And of course I thought it's absurd ordering a Greek
letter into a Chinese encoding. To me it seems to belong more to
German(y), since one of their last kings came from Bavaria.
In my understanding de_DE.UTF-8 says I'm coming from a German
location in an UTF-8 world, outside any proprietary CJK encodings.
Its psili modifier or
COMBINING COMMA ABOVE is at U+0313, outside any Chinese encoding, too
(although GB18030-2000 defines both as 0xA6AF and as 0x8130BE35).
Isn't Unicode, as in the name "Unicode Emacs," more
appropriate?
For the moment, I don't have a good idea about how to order
character sets that are outside of users locale. Perhaps,
if the character doesn't belong to any of:
(get-language-info current-language-environment 'charset)
the "preferred charset" line should not be showned.
This returns in my UTF-8 *scratch* buffer an absurd
(iso-8859-1)
I never set a language-environment because I had found with others
that this is bringing me back into the world of 7 bit encodings
(maybe also 8 bit).
By the way, in emacs-unicode-2, the default fontset is not
yet tuned well for Unicode. For instance, for Latin,
currently only these fonts are registered:
"ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-9"
"ISO8859-10" "ISO8859-13" "ISO8859-14" "ISO8859-15"
"VISCII1.1-1"
Why is ISO 8859-16 missing?
Similarly GNU Emacs 23.0.60 handles Ὀ (i.e. one letter Omicron
with
psili):
character: Ὀ (8008, #o17510, #x1f48)
preferred charset: gb18030 (GB18030)
code point: 0x81369132
syntax: w which means: word
category: g:Greek
buffer code: #xE1 #xBD #x88
file code: #xE1 #xBD #x88 (encoded by coding system utf-8-
unix)
display: by this font (glyph code)
-monotype-arial unicode ms-medium-r-normal--10-98-74-74-p-99-
gb18030.2000-0 (#x9132)
[...]
And although it claims taking GREEK CAPITAL LETTER OMICRON WITH PSILI
at U+1F48 off Arial Unicode MS, which has this glyph, it uses an open
box to display it. Because U+1F48 is not defined in GB18030? The byte
sequence (code point) 0x81369132 is not defined in GB18030-2000.
If that font doesn't contain that character, with the above
change, that font won't be used.
Arial Unicode has U+1F48. It does not have it in a gb18030.2000-0
font encoding, because this code point is not defined in
GB18030-2000. So one of the first mistakes is to assume U+1F48 is
defined in GB18030-2000 and another one is to use a partial font
encoding like gb18030.2000-0 instead of a more complete and in an
UTF-8 environment more appropriate iso10646-1 font encoding.
--
Greetings
Pete
Math illiteracy affects 7 out of every 5 Americans.
- Re: 23.0.60; describe-char gives wrong information, Kenichi Handa, 2008/01/08
- Re: 23.0.60; describe-char gives wrong information,
Peter Dyballa <=
- Re: 23.0.60; describe-char gives wrong information, Kenichi Handa, 2008/01/08
- Re: 23.0.60; describe-char gives wrong information, Kenichi Handa, 2008/01/10
- Re: 23.0.60; describe-char gives wrong information, Peter Dyballa, 2008/01/10
- Re: 23.0.60; describe-char gives wrong information, Kenichi Handa, 2008/01/13
- Re: 23.0.60; describe-char gives wrong information, Peter Dyballa, 2008/01/14
- Re: 23.0.60; describe-char gives wrong information, Kenichi Handa, 2008/01/15
- Re: 23.0.60; describe-char gives wrong information, Peter Dyballa, 2008/01/15