Hi Alan,
Have you actually tried mehlng's solution? It seems to work perfectly.
- yba
On Wed, 13 Oct 2004, Alan Yaniger wrote:
>
> 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.
> >
>
--
EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il -
==============================================================
To unsubscribe, send mail to [EMAIL PROTECTED]
with "unsubscribe hebrew" in the message body.
