Miki Dovrat wrote:
Hi,
Hi, Miki!
I am using lyx svn version 18738 from Monday night.
Good!
I have found a few problems with the Bidi:
1. Cursor movement is not yet visual, i.e. the cursor goes opposite to
the arrow key on foreign parts. I don't know if it was your intention to
include that already.
No, Visual movement may not be done before 1.5.0. I hope that by 1.5.1
we'll have it...
2. I can't tell whether to use backspace or delete, since cursor isn't
visual.
Yes, this is a problem (and will be a problem in Visual mode, too, as
backspace by convention is considered a "logical" action, and thus will
*always* delete the *logically* previous character. That's what it
should be doing now, too, if not --- it's a bug.)
So:
a. it's good that we have undo ;)
b. what I sometimes do is SHIFT+RIGHT/LEFT to select what I want to
delete, that way I see what's about to be deleted, and then delete...
3. If I have a Hebrew paragraph with an English word like
עברית English עברית עברית
and I type continuously, the spaces are Hebrew. Now if I try to continue
the Hebrew to the right of the English word, but after the Hebrew space,
as to continue typing, I can't: If I am in English mode and I press F12
(bound to language hebrew), the cursor jumps to the left of the English
word. If I was already in hebrew (if the cursor was resting on a hebrew
word before and then I moved it to this position with the mouse), then
it's ok.
This is correct. If you move to the right of the english through the
english, then at the end you are still considered to be in English, at
the end of the english; so switching to hebrew should move you to the
left of the english. You can do what you want by moving to the beginning
of the english, and then move back one more, that'll bring you to the
space before the english; then if you move one Left, you'll be after the
space, but still in hebrew. Typing in hebrew will then work as you want
it to.
In general, the idea is that on the borders between LTR and RTL, you
stay in the language that you are coming from. I believe this is the way
most applications deal with this, and now LyX does too. Again, this
problem will probably be solved with visual mode, hopefully not too long
from now...
4. Going backwards, when the cursor finishes the English word, it jumps
to before the hebrew space, and stays in English mode, so that if I
press a letter it comes out English even though I am in Hebrew.
This is a different issue, it's a bug with the keymap, which I have a
patch for waiting to be OKed. (see bug 3811)
5. Going forward, when the cursor moves one position after the hebrew
space, the position jumps to one after the the first English character
(i.e. to between E and n in English) and it is still in Hebrew mode, so
the letter I enter is hebrew.
Same as 4.
6. I cannot enter an inline equation to the right of the English word.
This looks like a bug. If you're coming from the english, then I think
that the equation should also be "in english" (see next comment), and
then what you want to do would work. Can you open a bug for this in
bugzilla (and see next comment)? Meanwhile, if you just select the
entire inset, and switch it's language with F12, you'll get what you want.
It jumps to the left of it. I can trick lyx into doing this by entering
the equation to the right of the boundary space, near the Hebrew part,
and then adding the space between the hebrew word and the equation. The
space between the word "English" and my equation is RTL. My equation is
marked RTL, if that makes any sense.
Yes, the "inset" is marked as RTL, which is separate from what's inside
it (try this with a footnote, where the text inside can also be RTL:
you'll see that the language of the inset and the language of the text
inside it are independent). I don't know if this is intentional or not,
but I think that it does make a certain amount of sense. The problem
above is just the the inset is not keeping the "current" language, but
rather reverting to the paragraph's language...
If I delete the space between the
equation and the English word, I cannot put it back again. If I enter a
LTR space, it gets deleted. I can't enter a RTL space (see paragraph 3).
7. Same for equation to the left of English text, If I enter it to the
left of the word "English", then it's OK (its LTR, but before the word
"English", i.e. to its left). If I enter it to the left of the Hebrew
space (to the left of the word "English"), it is marked RTL, and if I
delete the space between it and the English word, I can't put it back
again. If I try a LTR space, it isn't entered. F12 jumps the cursor to
the right of the English word.
8. I can't insert a cross reference to the right of English text. It
jumps to the left of it. You can enter it to the left of Hebrew text,
and then delete the space, and then add the Hebrew space.
7, 8 seem to be the same issue as in 6...?
9. Why do equations get marked LTR?
What do you mean? Maybe what I explained above helps?
10. References which get added RTL are backward in output, i.e. instead
of 12, 13, 14, etc. I get 21, 31, 41. Even if I try to switch the
language to English, the reference gets marked RTL. I suspect it will be
the same for figure numbers above 10. For equations it comes out fine
for some reason even above 10.
Is the problem here in the display or in latex or both? I haven't
checked this yet...
11. If I try to enter an English word between two already typed Hebrew
words, to the right of the space, and I type "English " with a space,
the space gets deleted and I don't get a space between the word English
and the hebrew word to its right.
The correct way is for spaces around LTR text within RTL paragraphs (or
vice versa) is for the space to be in the paragraph's language.
Otherwise, ambiguities arise. So technically, what you're trying to do
is wrong. You should first enter the space "in hebrew", and only then
switch to english, and type in the english word. We tried to correct
this in the case of regular typing --- i.e., if you type in hebrew, and
then F12, space, and english --- then the space's language will
automatically be switched to hebrew. But that will only happen when you
type the next hebrew character. In the above case you're not doing that,
so this doesn't happen. Again, the correct way is to have the space in
the language of the surrounding paragraph.
12. If I try to enter an English word between two already typed Hebrew
words, to the left of the space, I can't enter an LTR space to start
with, and if I write "English ", I am left with two spaces, one LTR and
to its right, the original RTL space.
Same as 11.
13. Same as 11 and 12 but for Hebrew words between already typed English.
Same answer, I guess... ;)
I am sure there are more :)
sorry to be picky.
No problem. It's just that there are real problems here, and I'm not
sure there are good solutions to all of them. If you have suggestions
for *how* to solve these issues, please send them in. Keep in mind
though that what you want in one situation may not be what you want in
another... One thing you could do is see if you think the situation in
Word (or any other application) is better --- and if it is, we'll see if
we can adopt that behavior. Again, though, note that there are some
problems in LyX which do not arise in word (for example, the fact that
we don't allow adjacent spaces in LyX) --- and we want to keep LyX's
behavior in many of these cases...
In my opinion, these problems are SERIOUS and really handicap lyx as a
Hebrew typesetter at this point. They make serious work with Hebrew
technical document (with lots of English terms in it, references and
equations) in lyx very annoying and cumbersome.
All of these can be fixed by "voodoo" such as starting a fresh
paragraph, and then deleting the carriage return and such solutions, but
I urge you to try and fix it before the release. Please?
If anything isn't clear in my examples, don't hesitate to ask and I will
clarify what I meant.
Miki
A few general comments:
1. I think you'll find it easier to deal with these things if you do
mark the foreign language -- that way it's easier to see what's going
on. I never found this distracting, but I guess that's a matter of
taste. Maybe you can think of a different way of marking foreign
languages, which would be less distracting.
2. For the immediate future, let's try to focus on the regressions
(things that were better in older versions of LyX).
3. I may have sounded a little defensive about some of these issues ---
if I did --- sorry ;) . It's just that for some of the issues, I'm not
suer there's a good solution, at least not without getting into
complicated heuristics for trying to figure out what the user really
means...
Dov
