w32 emacs Arabic

w32 emacs Arabic

[B. T. Raven]

Is anyone here successfully getting Arabic characters into w32 emacs. I
have a font (ttf) that displays the characters but not in emacs. Does
the ability to use Arabic in emacs depend on bidi support? What is the
relation between codepages in cp*.nls files and their definitions in
emacs?

Thanks,

Ed

Re: w32 emacs Arabic

[Eli Zaretskii]

> From: "B. T. Raven" <ecinmn@peoplepc.com>
> Date: Wed, 16 Nov 2005 05:55:13 GMT
> 
> Is anyone here successfully getting Arabic characters into w32 emacs. I
> have a font (ttf) that displays the characters but not in emacs. Does
> the ability to use Arabic in emacs depend on bidi support?

None of the released versions of Emacs supports Arabic at this time.
Sorry.  (And yes, lack of bidi support is one of the reasons, but
there are others.)

> What is the relation between codepages in cp*.nls files and their
> definitions in emacs?

The Emacs definitions should provide full support for text encoded in
the respective codepages.

Re: w32 emacs Arabic

[Jason Rumney]

"B. T. Raven" <ecinmn@peoplepc.com> writes:

> Is anyone here successfully getting Arabic characters into w32 emacs. I
> have a font (ttf) that displays the characters but not in emacs. Does
> the ability to use Arabic in emacs depend on bidi support? What is the
> relation between codepages in cp*.nls files and their definitions in
> emacs?

Proper display and input requires bidi support. Currently, there is
some strange behaviour with Hebrew and presumably Arabic, since
Windows handles the reversing when we try to display many characters
at once, but when moving the cursor through text, Emacs displays it
one character at a time - but without bidi support, Emacs orders the
characters incorrectly.

Internally, Emacs' encoding for Arabic is based on iso-8859-6 plus
some Mule specific encodings to cover characters not covered by
iso-8859-6, while Windows uses its own encoding. There may be a
cp28596.nls file on Arabic windows that allows windows to decode
iso-8859-6, if there is, then it will be possible to display
iso-8859-6 (with problems as described above) from within Emacs
without doing anything.

If there is no such codepage, then you will need to write a ccl
program for the Windows codepage to convert it to Emacs' internal
encoding. Then you will need to define a fontset with the arabic font
defined to use the encoding defined by your ccl program. You'll need
to do this anyway to get support for the characters covered by the
Mule specific encodings.

Re: w32 emacs Arabic

[Jason Rumney]

"B. T. Raven" <ecinmn@peoplepc.com> writes:

> What is the relation between codepages in cp*.nls files and their
> definitions in emacs?

I initially interpreted this only in the context of Arabic, but I see
on re-reading it is an independant question.

The codepage definitions in Emacs allow Emacs to convert to/from its
internal encoding to Windows and DOS codepages.

The cp*.nls files in your SYSTEM directory are what Windows uses to
convert to/from its internal encoding (a Unicode variant) and those
codepages.

Emacs depends on the nls files only for display on Windows, and
really only for historical reasons, since Emacs' Unicode support is
probably good enough now (in CVS) to convert directly to Unicode
without going via the Windows API MultiByteToWideChar() function.

Re: w32 emacs Arabic

[B. T. Raven]

<jasonr (Jason Rumney) @ f2s.com> wrote in message
news:uek5gjijt.fsf@jasonrumney.net...
> "B. T. Raven" <ecinmn@peoplepc.com> writes:
>
> > What is the relation between codepages in cp*.nls files and their
> > definitions in emacs?
>
> I initially interpreted this only in the context of Arabic, but I see
> on re-reading it is an independant question.
>
> The codepage definitions in Emacs allow Emacs to convert to/from its
> internal encoding to Windows and DOS codepages.
>
> The cp*.nls files in your SYSTEM directory are what Windows uses to
> convert to/from its internal encoding (a Unicode variant) and those
> codepages.
>
> Emacs depends on the nls files only for display on Windows, and
> really only for historical reasons, since Emacs' Unicode support is
> probably good enough now (in CVS) to convert directly to Unicode
> without going via the Windows API MultiByteToWideChar() function.

Thanks, Eli and Jason. I guess I'm not surprised that this deucedly
difficult problem hasn't been straightened out yet. For those of you who
haven't seen right-to-left languages imbedded in left-to-right ones, try
running the cursor (via the left and right arrow keys) over the
following lines:
Now is the time for all good men
يَجِبُ عَلَى الإنْسَانِ أن يَكُونَ أمِيْنَاً وَصَادِقَاً مَعَ نَفْسِهِ
وَمَعَ أَهْلِهِ وَجِيْرَانِهِ وَأَنْ يَبْذُلَ
 to come to the aid of the typist.
كُلَّ جُهْدٍ فِي إِعْلاءِ شَأْنِ الوَطَنِ وَأَنْ يَعْمَلَ عَلَى مَا
يَجْلِبُ السَّعَادَةَ لِلنَّاسِ . ولَن
Four score and seven years ago
 يَتِمَّ لَهُ ذلِك إِلا بِأَنْ يُقَدِّمَ المَنْفَعَةَ العَامَّةَ عَلَى
المَنْفَعَةِ الخَاصَّةِ وَهذَا مِثَالٌ لِلتَّضْحِيَةِ .
"sdrowkcab sdrawkcab si sihT"

It works in Outlook Express under MS Windows anyway. But not to worry,
whatever Bill Gates can do Richard Stallman can do better.

Thanks again,

Ed

>