Uwe Brauer writes:
> But please don't use Hebrew characters, as you cannot
guess what
> others are going to see.
Hm, I remember some years ago, when I was still using a no mule version,
and Aidan posted chars which I could not display and this made me switch
to mule. So are you saying this, because not everybody is using Mule,
or some other reason.
Some other reason, namely, that there are at least three interesting
versions of XEmacs (trunk 21.5 with X, trunk 21.5 with GTK, and Jeff's
branch with GTK) and one Emacs (not to mention pango-viewer) which
display more or less different things, apparently. Worse, for those
of us reading in Terminal.app, Hebrew is apparently broken (words seem
to disappear -- or maybe I'm just not used to the weirdnesses that
happen with bidi).
Jeff and I sent screenshots, so I thought the point was clear.
I read in a remote TTY (Mac OS X Terminal.app) much of the time. In
any case, somebody who can't read Hebrew is not necessarily going to
be able to tell precisely what is wrong from looking at the images
(this is true of many problems that occur with Han characters, for
example).
>> I am not longer sure that the culprit is really pango.
> The answer is very simple, I suspect. XEmacs's redisplay effectively
> breaks up lines into words (because spaces are ASCII), and displays
> those words as blocks. Inside the blocks it might be R2L (as above),
> or it might not (I forget the exact details of how words are composed
> for display). However, the blocks will be displayed L2R.
The plain fact is: Jeff compiles a xemacs version[1] and hebrew is
displayed correctly (as in GNU emacs 24) and I compile it with the same
options and hebrew is not displayed correctly.
But you still don't say what "not correctly" is.
And Jeff said otherwise, that at least one sample he looked at
displayed differently in his XEmacs and in recent Emacs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta