emacs-bidi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [emacs-bidi] Points composition - status.


From: Yair Friedman (Jerusalem)
Subject: Re: [emacs-bidi] Points composition - status.
Date: Mon, 24 Dec 2001 18:13:49 +0200
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1

Eli Zaretskii <address@hidden> writes:

> Yair Friedman (Jerusalem) wrote:
> > 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> But the major thing I don't like in the "Unicode is just an additional
>> charset" approach is the oddities it causes. In particular,
>> mule-unicode-0100-24ff is splitting the Hebrew segment into two
>> pages.
>
> If by ``two pages'' you mean the mule-unicode-0100-24ff vs hebrew-iso8859
> characters,

No, I mean this:
  character: $-1¬ÿ (01213177, 333439, 0x5167f)-A
    charset: mule-unicode-0100-24ff
             (Unicode characters of the range U+0100..U+24FF.)
 code point: 44 127
     syntax: word
   category:
buffer code: 0x9C 0xF4 0xAC 0xFF

  character: $-1­  (01213240, 333472, 0x516a0)-A
    charset: mule-unicode-0100-24ff
             (Unicode characters of the range U+0100..U+24FF.)
 code point: 45 32
     syntax: word
   category:
buffer code: 0x9C 0xF4 0xAD 0xA0

(These are examples of C-u C-x = ,I'm not sure if they go well through
the email).

These characters follow each other on all coding systems, but
unicode-0100-24ff puts them far away.  In addition all codes between
0x51680 and 0x5169F are "invalid characters".  This means that if you
want to perform global operations all all Hebrew page characters, you
need to do it in 2 runs (or use char-valid-p).

This is because in mule everything is "pages" of 96x96 characters - not
suitable for Unicode I suppose.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]