I'm not sure what 4.3.0 did, but the correct behaviour should be that shift-9 produces "open brackets" in left to right languages, and "close brackets" on right to left languages. shift-0 should produce the other one.
As far as the engravings go, it is up to the display engine to display open brackets as left brackets in LTR context, and right brackets in RTL context. We can see, then, that we need cooperation of the keyboard layout and the display engine in order to get a consistant and pleasant experience.
The situation thus far was not very good in X, but was tolerable. Shift-0 in RTL context produced the wrong key (i.e. - close bracket instead of open bracket), but this was compensated by the fact that the display engine did not know it was supposed to reverse them. This is called, in Technical jargon "Visual Hebrew". I think I don't need to explain to th goers of this forum why this is bad. This still produces problem when files are swapped with saner environments, such as Windows or a palm pilot.
Now, finally, someone has taken the first step torwards the correct behaviour. This is a necessary step, and cannot be skipped. I understand that this creates a bit of confusion, and some inconsistancies. Please hang on, we are on our way to better BiDi support than we had so far.
If anyone does not understand why the old way is a problem, they are welcome to take a BiDi conforming editor and check it out.
Step by step instructions for showing that the old layout is not done correctly:
1. Open Mozilla composer with a blank document.
2. Switch to source mode, and add "dir=rtl" inside the "<body>" tag.
3. Switch back to visual mode, switch the keyboard to Hebrew, and
type shift-0 (open bracket, remeber, you are on the right),
followed by "�", followed by "�", followed by "�", followed by
"�", followed by a close bracket (by that time I won't have to
tell you which key is intuative for you to press).
You will see that the wrong character is displayed, even though, if you view the resulting file with a non-BiDi aware editor, the symbols engraved on the keys are exactly what appears in the file. The reason being that Mozilla correctly reverses the brackets (according to the BiDi algorithm), while your input did not.
Now, whether that reversal should be done by the keyboard layout or by the edit control upon input is a different question, and one I find myself a little hard put to answer. Leaving things as they are pre-4.3.0, however, is the worst thing we can do.
[EMAIL PROTECTED] wrote:
I'd like to concur with that!
I though that I missed the line of this discussion because some positions
sounded
so wierd (mainly stuff like Shift-9 opening braces all the time). Not until
this
reversing began with KDE have I ever had problems with braces in any
language
I used on computers and now I keep having to press keys and "see what
happens"
when I type hebrew in Linux, this is completly rediculous!
So please stop this instanity while you can.
Thanks.
Please remember that shift9 means open braces, and shift0means close them.
How they are represented on screen is another thing.No! shift-9 contains engraving (on the plastic) of *left parenthesis*
Under your interpretation it would produce a right parenthesis in
hebrew..... This is completely insane!
-- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
