Hi Jonathan and Waleed,

I must disagree with the suggestion that we use RLM/LRM to solve issue
18024, even though it puts me in the unpleasant position of disagreeing
not only with the two of you, but also with [EMAIL PROTECTED] who
brought up the issue originally. Here's why I disagree: RLM/LRM markers
are meant to function just like RTL or LTR strong characters, only they
aren't visible. Change an LRM with any strong LTR character, and it will
have no effect on the display order. We know that

We know that      FUNCTION  f(x) displays incorrectly.  
We also know that FUNCTION qf(x) will display just as incorrectly,
So we can conclude that

FUNCTION <LRM>f(x)  will display just as incorrectly as:
FUNCTION qf(x)

since as far as the bidi algorithm is concerned, there's no difference
between an LRM and a "q" (or any other strong LTR chracter). So inserting
an LRM either manually or automatically will not solve the problem.

It's necessary to use RLE/LRE codes to solve the problem. Here's why:
Non-numeric weak characters like parentheses will take on the direction of
surrounding characters. Example: the comma in "200,000" is LRT. But if
there are no strong characters on both sides (like our example, where the
closing parenthesis has nothing after it), the direction will default to
direction of the embedding level (in our example: RTL). This is why the
parenthesis is jumping to the left of the "f". The way to get around this
is by using RLE/LRE, not RLM/LRM. RLE/LRE codes change the embedding
level. In our example, an LRE before the "f" will change the embedding
level to a LTR level, so the parenthesis will take on the direction LTR,
which is what we want.

Alan

On Tue, 12 Oct 2004, Jonathan Ben Avraham wrote:
> 3. LRM/RLM
> 
> The solution that [EMAIL PROTECTED] proposes really is "original" as
> claimed, and solves the weak character problem that we all know about in a
> very elegant way, and is probably what the user wants, even if it is
> "automatic". All that is needed is a way to make sure that the
> position of the character is indicated and that the cursor "sees" the
> character and the delete key deletes it.
> 
> I think that if we are putting this character in automatically, then we
> should also offer a convenient way to insert it explicitly.
> 
-- 
Alan Yaniger
Tk Open Systems

==============================================================
To unsubscribe, send mail to [EMAIL PROTECTED]
with "unsubscribe hebrew" in the message body.

Reply via email to