Now we have two threads in lyx-users and lyx-devels. Miki, are you on lyx-devels as well? Then we can continue there with the discussion.

Stefan

Am 05.06.2007 um 18:11 schrieb Miki Dovrat:

Hi,

I am having trouble following your examples, but my opinion is that no MAGIC
should happen.
Spaces jumping from side to side or characters at the end of a RTL jumping to the beginning and such are so annoying!!! The user can never tell where
he/she is as far as LTR or RTL is concerned.

My opinion is that the spaces should be silently joined by latex or lyx, and that the user doesn't really care if the space itself is RTL or LTR. This will be the most clear to use, and will enable pointing to a place with a mouse or reaching it with the cursor, and knowing exactly "where" you are and what will happen. This will be good even in adding equations in between RTL and LTR (which tended to jump to one side only because of the "magic")

The cursor should go smoothly, i.e. if you are moving to the right across from a LTR to a RTL, the cursor should continue smoothly and not jump to the beginning of the RTL (on the opposite) and start moving left, and then jump back again to the beginning of the RTL and continue to go left on the LTR. As far as RTL is concerned, this would mean moving from end to start, but it is in my opinion the most intuitive. Otherwise you have the cursor going one way when you type the opposite arrow. Some word processors behave like that,
and I don't like to use them :).

I will be willing to compile and test.

I thought Dov knows Hebrew :).

Miki


"Stefan Schimanski" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
Hi!

Myself and Dov Feldstern are working on the support for Right-To-Left
languages in LyX. In the latest RC1 there are many things which are
not the way they should be. As we are not using Right-To-Left ourself
we lack a bit the experience how it should look like and what is most
convenient.

To get it right WE ARE LOOKING FOR:

  PEOPLE USING RTL languages and who are able and WILLING TO TRY OUT
PATCHES
  against the subversion code and to compile it.

You don't have to be a developer, just user of a RTL language who
wants to have LyX 1.5 to behave the right way (tm).

One decision which is open and must be settled:

THE SPACE ISSUE
===============

What we are investigating right now is the handling of spaces on the
boundary of RTL and LTR text. Take a look at the picture. The blue
underline marks the character which have a RTL font. So the picture
shows the four cases possible.




---------------------------------------------------------------------- ----------




There are several possibilities now to interpret the underlined
spaces (short RTL spaces):

* The LyX 1.3 magic way: the RTL spaces behave in fact like LTR
spaces, i.e. they are put where non-underlined spaces would be. See
this example:

  - In "english WERBEH_english" the _ is in fact behind the W
    So in Latex you would write "english\R{HEBREW } english"

The consequence is that the cursor strangely (IMO) jumps from behind
the W to the right in the moment you enter the space. If you have
used LyX 1.3 you might be familiar with this behavior:

  "english |WERBEHenglish" ==> "english WERBEH_|english"

If you continue now typing a character the cursor (and the space)
jumps back:

  "english WERBEH_|" ==> "english |H_WERBEHenglish" ==>
  "english H_WERBEH_|english"

* The non-magic way: the spaces are no special characters. They stay
at the position you type them. See this example:

  "english |WERBEHenglish" ==> "english |_WERBEHenglish" ==>
  "english |H_WERBEHenglish"

If you change back to English and continue typing the cursor will go
to the right, i.e.:

  ==> "english H_WERBEH|english" ==> "english H_WERBEH |english"

In Latex you would type the same:

  "english \R{HEBREW H} english"

Of course two spaces, one inside the RTL, one outside, are merged
silently by Latex,
i.e. "english \R{HEBREW }" will look the same as "english \R {HEBREW}".

If you have an opinion, please tell us.

Thanks
  Stefan Schimanski




Attachment: PGP.sig
Description: Signierter Teil der Nachricht

Reply via email to