Re: certain Chinese characters are not displayed correctly

In article <[email protected]>, Stefan Müller <[email protected]> writes:

> I am sorry for beeing imprcise. What I intended with my explanation was
> to say that the encoding seems to be all right, since all programms
> (except emacs) that work with the characters work correctly.

> My problem seems to be a display problem.

I'm sorry to say this, but you don't have to tell me what
you think.  What I need is to know what Emacs does in your
case.

>> what application can't display the character properly?  If the 
>> application is Emacs, what do you get when you type C-u C-x = while
>> putting the cursor on that incorrect "square"?

> The problem is: emacs does not give me the code instead it gives me the
> code of the next character. This is 'men 1' for the plural pronoun and 
> space for the singular pronoun, i.e.

Here again, "does not give me the code" is vague, and that
is what you thought.  What I want to know is (I repeat):
   what do you get when you type C-u C-x = while
   putting the cursor on that incorrect "square"?

>    character: SPC (040, 32, 0x20)
>      charset: ascii (ASCII (ISO646 IRV))
>   code point: 32
>       syntax: whitespace
>     category: a:ASCII   l:Latin
> buffer code: 0x20
>    file code: 0x20 (encoded by coding system utf-8-unix)
>         font: -Adobe-Courier-Bold-R-Normal--14-140-75-75-M-90-ISO8859-1

Is the above the answer to my question?  Then it's very
surprising.  Emacs should never show empty square for just a
space character.

But, in the next mail,

Stefan Müller <[email protected]> writes:

> I marked the line break before the character and this gives:

I don't understand what you mean by "mark the line break
before the character", but...

>    character:  (0254137, 88159, 0x1585f)
>      charset: japanese-jisx0212 (JISX0212 Japanese supplement: ISO-IR-159)
>   code point: 48 95
>       syntax: word
>     category: C:Chinese (Han) characters of 2-byte character sets 
> j:Japanese   |:While filling, we can break a line at this character.
> buffer code: 0x94 0xB0 0xDF
>    file code: 0xE4 0xBD 0xA0 (encoded by coding system utf-8-unix)
>         font: -- none --

If that is the answer to my original question, I think I
found what is going on.  I remember you are using Mule-UCS,
right?  As far as I know, by default, the UTF-8 decoder of
Mule-UCS sets higher priority to Japanese characters sets.
For instance, U+4F60 (ni 1) is included in
japanese-jisx0212.  So you get the above character.  If that
is the case, try this:

(un-define-change-charset-order
 '(ascii latin-iso8859-1 latin-iso8859-2 latin-iso8859-3
 latin-iso8859-4 cyrillic-iso8859-5 greek-iso8859-7
 hebrew-iso8859-8 latin-iso8859-9 latin-iso8859-14
 latin-iso8859-15 ipa  chinese-gb2312 japanese-jisx0208
 japanese-jisx0212 chinese-cns11643-1 chinese-cns11643-2
 chinese-cns11643-3 chinese-cns11643-4 chinese-cns11643-5
 chinese-cns11643-6 chinese-cns11643-7 chinese-big5-1
 chinese-big5-2 korean-ksc5601 latin-jisx0201
 katakana-jisx0201 thai-tis620 ethiopic indian-is13194
 chinese-sisheng lao vietnamese-viscii-lower
 vietnamese-viscii-upper mule-unicode-0100-24ff
 mule-unicode-2500-33ff mule-unicode-e000-ffff
 mule-ucs-unicode-multichar))

It puts chinese-gb2312 the higher priority than Japanese
charsets.

---
Kenichi Handa
[email protected]