Re: [OOo-H] Re: Fwd: Request: Behaviour on weak characters in mixed directional

[meh]

Hi, thanks for your comment. I actually find myself quit agreeing with you in here, even though I am the original proposer of the idea. There isn't much difference which exact sign will we implement the "f(x)" sollution with, and Alan's sollutions seems to fit the standard. Why should it matter (implementation wise, and tachles, for the user experience) whether we put an RLE or an LRM? I'm quoting the Unicode standard from http://www.unicode.org/reports/tr9/ : 2.1 Explicit Directional Embedding The following codes signal that a piece of text is to be treated as embedded. For example, an English quotation in the middle of an Arabic sentence (my emph.) could be marked as being embedded left-to-right text. If there were a Hebrew phrase in the middle of the English quotation, then that phrase could be marked as being embedded right-to-left. These codes allow for nested embeddings. RLE Right-to-Left Embedding   Treat the following text as embedded right-to-left. LRE Left-to-Right Embedding   Treat the following text as embedded left-to-right. The precise meaning of these codes will be made clear in the discussion of the algorithm. The effect of right-left line direction, for example, can be accomplished by simply embedding the text with RLE...PDF. 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.