Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Hi, Dov, I don't understand why you would need to keep the logical behavior. In my opinion it is just bad, but we have all gotten used to it so it feels familiar. I will join the devel thread as Stefan requested. Miki "Dov Feldstern" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Miki Dovrat wrote: >> Hi, >> >> I already replied Stefan off list, but I will post this again so anyone >> can >> comment. >> >> The brain (at least mine) does not like movement to the opposite side. >> When >> you press the left arrow, you expect the cursor to move to the left. Try >> riding a bike with the hands crossed, wear a helmet!!! >> >> So I think the visual movement is the most convenient and intuitive. >> >> Microsoft Word is an example of how NOT to do it. It does not change the >> RTL >> or LTR mode except by an explicit request by the user (ALT-SHIFT), and >> even >> as you cruise into a RTL part, and you want to add a letter, if you were >> writing English before, the added letter will be English. And the cursor >> movement is to the opposite side (it jumps to the end of the RTL, and >> goes >> backwards in opposite of the arrow key). >> >> As far as getting used to logical movement, you can get used to anything, >> but it is easier to get used to good things. Nobody complains about Word >> since the Israeli market is small and big companies always do us (the >> Hebrew >> users) a "favor" by thinking about us at all, so we accept whatever is >> given >> us. >> >> I would like lyx to be a little smarter, and to change its RTL or LTR >> mode >> by itself as you move across already written text. When you point at a >> word, >> the most COMMON intention is to add letter or fix spelling or continue >> writing, so lyx should already put you in the right language (it doesn't >> do >> so now). If you want the opposite language, I think you should ask for it >> explicitly once you are in place. >> >> Thanks for the interest. >> >> Miki >> >> >> "Stefan Schimanski" <[EMAIL PROTECTED]> wrote >> in >> message >> news:[EMAIL PROTECTED] >> >> >> >> > > Hi all! > > Instead of replying individually to all the messages on this subject, > I'll try to sum up my responses here. > > First of all, just for the record --- as Miki pointed out, I *am* an RTL > user ;) . I also have a lot of experience with Bidi editing in LyX. It's > just that this issue is particularly thorny --- because what I consider > to be the correct solution (the one that does not impose limits on the > user) is 99.9% of the time *not* what the user meant (I'll explain below). > > - > > But first: a side issue which has been raised in this thread is that of > "visual movement". > > A feature request for this already appears in bugzilla > (http://bugzilla.lyx.org/show_bug.cgi?id=3577). Note, however, that this > should *not* replace logical mode, but rather be an option for the user > to choose which she prefers. > > Regarding implementation of visual mode: > > *) I agree 100% with Miki above about how it should work: the current > language should be determined by the current font, *not* by remembering > what the last font was. > > *) The basic idea for implementing visual mode is dead simple: pressing > RIGHT in LTR paragraphs (LEFT in RTL) should move to position > vis2log(log2vis(pos)+1), and the opposite is with -1. (vis2log and > log2vis are in Bidi.cpp. In this case, Stefan, I think you're going to > *have* to use them, I don't see any way around it). > But there are a lot of details to work out: there may still be issues of > boundary, I'm not sure; there also may be some logic needed in order to > make the transitions between paragraphs behave correctly (e.g., I'm in > an LTR paragraph moving RIGHT. When I reach the end of the paragraph, > pressing RIGHT again should move me to the *end* of the first line in > the next paragraph if it's RTL. I'm not sure if this is already covered > by vis2log or not.); math insets would have to be adjusted separately, I > think. But basically that's it. But I think it'll take a little work to > work out the kinks. > > I'm attaching a patch which just demonstrates the feasibility of this > approach. It crashes all over (or shall I say: left and right?) --- I > don't deal with any edge (no pun intended) case whatever. But if you > type in some mixed English--Hebrew text on a single line, with the mouse > move the cursor somewhere that's not at an edge, then you can move > around visually as long as you stay away from the edge. But the problem, > of course, is working out all the details... > > In the meantime, we have tried to make cursor movement in bidi documents > behave a little more predictably: > > In an LTR paragraph, RIGHT moves forward (logically) --- both in RTL and > in LTR texts (so in RTL it's moving opposite to the arrow, yes) --- and > LEFT backwards. And the reverse for RTL paragraphs. Insets (e.g., > footnote) within a paragraph also follow this
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Dov Feldstern wrote: > Back to RTL spaces: > > The problem is this: almost always, the user just wanted a space between > the previous word (which happened to be, say English) and the next one > (which happens to be Hebrew), but by mistake pressed F12 before space > and not first space and only then F12. In fact, I can't think of *any* > case in which it is important to the user for it to be any other way. > > However, I still think that it is more correct for us to pay attention > to the language of spaces. If we don't, then there are things which I > *would* like to be able to typeset, but won't be able to (see example > below). > > After thinking about this a lot, this is the solution I would like to > see (I think it's similar to Georg's views, if I understood him > correctly): Yes, you did. I can't really tell how spaces should behave when inserting, because I don't use RTL, but as long as all magic (if any magic is used at all) only happens during/after inserting the space and not anywhere else (drawing or export) I think the resulting code will be maintainable. If you apply magic at different places then you will get a nightmare that nobody understands in a few months anymore. Georg
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
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
PGP.sig
Description: Signierter Teil der Nachricht
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote: Hi, I already replied Stefan off list, but I will post this again so anyone can comment. The brain (at least mine) does not like movement to the opposite side. When you press the left arrow, you expect the cursor to move to the left. Try riding a bike with the hands crossed, wear a helmet!!! So I think the visual movement is the most convenient and intuitive. Microsoft Word is an example of how NOT to do it. It does not change the RTL or LTR mode except by an explicit request by the user (ALT-SHIFT), and even as you cruise into a RTL part, and you want to add a letter, if you were writing English before, the added letter will be English. And the cursor movement is to the opposite side (it jumps to the end of the RTL, and goes backwards in opposite of the arrow key). As far as getting used to logical movement, you can get used to anything, but it is easier to get used to good things. Nobody complains about Word since the Israeli market is small and big companies always do us (the Hebrew users) a "favor" by thinking about us at all, so we accept whatever is given us. I would like lyx to be a little smarter, and to change its RTL or LTR mode by itself as you move across already written text. When you point at a word, the most COMMON intention is to add letter or fix spelling or continue writing, so lyx should already put you in the right language (it doesn't do so now). If you want the opposite language, I think you should ask for it explicitly once you are in place. Thanks for the interest. Miki "Stefan Schimanski" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi all! Instead of replying individually to all the messages on this subject, I'll try to sum up my responses here. First of all, just for the record --- as Miki pointed out, I *am* an RTL user ;) . I also have a lot of experience with Bidi editing in LyX. It's just that this issue is particularly thorny --- because what I consider to be the correct solution (the one that does not impose limits on the user) is 99.9% of the time *not* what the user meant (I'll explain below). - But first: a side issue which has been raised in this thread is that of "visual movement". A feature request for this already appears in bugzilla (http://bugzilla.lyx.org/show_bug.cgi?id=3577). Note, however, that this should *not* replace logical mode, but rather be an option for the user to choose which she prefers. Regarding implementation of visual mode: *) I agree 100% with Miki above about how it should work: the current language should be determined by the current font, *not* by remembering what the last font was. *) The basic idea for implementing visual mode is dead simple: pressing RIGHT in LTR paragraphs (LEFT in RTL) should move to position vis2log(log2vis(pos)+1), and the opposite is with -1. (vis2log and log2vis are in Bidi.cpp. In this case, Stefan, I think you're going to *have* to use them, I don't see any way around it). But there are a lot of details to work out: there may still be issues of boundary, I'm not sure; there also may be some logic needed in order to make the transitions between paragraphs behave correctly (e.g., I'm in an LTR paragraph moving RIGHT. When I reach the end of the paragraph, pressing RIGHT again should move me to the *end* of the first line in the next paragraph if it's RTL. I'm not sure if this is already covered by vis2log or not.); math insets would have to be adjusted separately, I think. But basically that's it. But I think it'll take a little work to work out the kinks. I'm attaching a patch which just demonstrates the feasibility of this approach. It crashes all over (or shall I say: left and right?) --- I don't deal with any edge (no pun intended) case whatever. But if you type in some mixed English--Hebrew text on a single line, with the mouse move the cursor somewhere that's not at an edge, then you can move around visually as long as you stay away from the edge. But the problem, of course, is working out all the details... In the meantime, we have tried to make cursor movement in bidi documents behave a little more predictably: In an LTR paragraph, RIGHT moves forward (logically) --- both in RTL and in LTR texts (so in RTL it's moving opposite to the arrow, yes) --- and LEFT backwards. And the reverse for RTL paragraphs. Insets (e.g., footnote) within a paragraph also follow this rule: in an RTL inset inside an LTR paragraph, arrow direction will be "backwards". This was implemented in order to avoid the cursor getting "stuck" between RTL and LTR insets, as it used to up until now. Two other differences which provide the user with some visual feedback which make typing bidi a little easier: 1) The language of spaces is now marked; so if something funny is happening with spaces in bidi, it's a little easier to figure out why. 2) As in previous versions of LyX, the cursor will now c
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Am Dienstag, 5. Juni 2007 21:06 schrieb Miki Dovrat: > Lyx has an option of underlining the foreign text. What I meant was that I > always turn that off, so I can't tell which direction the spaces belong to. Now I understand. I did not know that you can turn it off :-) Georg
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Hi, I already replied Stefan off list, but I will post this again so anyone can comment. The brain (at least mine) does not like movement to the opposite side. When you press the left arrow, you expect the cursor to move to the left. Try riding a bike with the hands crossed, wear a helmet!!! So I think the visual movement is the most convenient and intuitive. Microsoft Word is an example of how NOT to do it. It does not change the RTL or LTR mode except by an explicit request by the user (ALT-SHIFT), and even as you cruise into a RTL part, and you want to add a letter, if you were writing English before, the added letter will be English. And the cursor movement is to the opposite side (it jumps to the end of the RTL, and goes backwards in opposite of the arrow key). As far as getting used to logical movement, you can get used to anything, but it is easier to get used to good things. Nobody complains about Word since the Israeli market is small and big companies always do us (the Hebrew users) a "favor" by thinking about us at all, so we accept whatever is given us. I would like lyx to be a little smarter, and to change its RTL or LTR mode by itself as you move across already written text. When you point at a word, the most COMMON intention is to add letter or fix spelling or continue writing, so lyx should already put you in the right language (it doesn't do so now). If you want the opposite language, I think you should ask for it explicitly once you are in place. Thanks for the interest. Miki "Stefan Schimanski" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Lyx has an option of underlining the foreign text. What I meant was that I
always turn that off, so I can't tell which direction the spaces belong to.
I don't mind that each space should have a definitive direction, I think the
best way would be that the border spaces will always have the direction of
the "mother" document, i.e. not of the foreign part. I wasn't thinking of
the problems of the underlying latex code, but strictly about the visual
editing, sorry.
Miki
"Georg Baum" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
> Miki Dovrat wrote:
>
>> The users (at least me) don't know whether the space is RTL or LTR
>> because
>> they don't "mark RTL code" since it is annoying to look at when writing a
>> document in RTL.
>
> I don't understand what you mean here. When you write a mixed
> hebrew/english
> document you have to explicitly set the language of the foreign part
> anyway. The spaces would simply be part of this mechansim, no extra
> "marking" required.
> Whether this explicit language setting should be replaced by some
> automatic
> algorithm is a different issue that has been discussed. But even if such
> an
> algorithm is implemented the result is still that each character has an
> associated language that defines the direction.
>
>> I don't know how difficult it is to code this, but I think the space
>> should be "neutral", and that the direction should be decided according
>> to
>> whether the curser is currently to the right or to the left of this
>> border
>> space.
>
> And how would you output such a neutral space to LaTeX? If you have
> visually
> on screen
>
> RTL LTR
>
> where RTL is in RTL direction and LTR in LTR direction you need to decide
> whether to output
>
> \R{ LTR}LTR
>
> or
>
> \R{LTR} LTR}
>
> to LaTeX. How would you decide which variant to use without an explicit
> LTR
> property of the space? At first glance it might look as if both are
> equivalent, but this is not the case if other font changes (e.g. size)
> come
> into the play, and even if not your LTR font might have a different size
> of
> the space as your RTL font. This is exactly the reason why spaces are not
> handled specially anymore for font changes, and are output exactly as
> entered.
>
>> Lets say we have LTR RTL and the space between them. If the cursor is to
>> the left - continue English (you will be able to type another space there
>> and continue writing), and if you are to the right of the border space,
>> continue writing Hebrew (again, you will be able to enter another RTL
>> space there as well). Extra spaces should then be removed, like lyx does
>> today.
>>
>> The same for RTL LTR.
>
> The non-magic approach could be made to work exactly like that: If the
> cursor is at such a boundary with a space, set the current font that will
> be used for newly typed stuff either to the font at the left or the font
> at
> the right, according to the rules you gave. Strictly speaking this is a
> bit
> of magic, but I believe that in contrast to the neutral space this magic
> could be implemented in a reasonable manner, because it would only affect
> editing. A neutral space would require extra code in may different places.
>
> The result would still be that each space has an associated direction, so
> you could still create the other two cases of the four Stefan mentioned by
> inserting and removing some temporary characters.
>
>
> Georg
>
>
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Another open question (at least to me): how common and convenient is this logical cursor movement? For me it is rather strange and confusing. But maybe one just needs some years of working with it to get used to it intuitively. I ask because I don't think it's very complicated to add visual movement to LyX. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Definitely the non-magic solution: If you enter a space it gets the direction (RTL or LTR) of the current font, and is drawn on screen according to that direction (place and underlining), and cursor navigation follows that direction. It should not be possible to enter two consecutive spaces (one in RTL and the other in LTR) at a direction boundary. That sounds as a good solution: you can enter consecutive space, but the EPM removes them if you move cursor. So the moment you press space and continue with an RTL word additional spaces are allowed. But if you press space and then decide differently it's taken away by EPM. Does it sound reasonable? I will implement that approach, shouldn't be very hard. This is IMO the best approach: Users see on screen exactly whether a space is RTL or LTR. Therefore they know how the cursor will behave when navigating. Removing the direction property from spaces might look more user friendly at first glance, but the problem then is that you have to perform some magic in the code that quickly gets so complicated that no developer understands it anymore and/or it produces strange results in some corner cases. My opinion... this jumping makes me crazy Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Miki Dovrat wrote:
> The users (at least me) don't know whether the space is RTL or LTR because
> they don't "mark RTL code" since it is annoying to look at when writing a
> document in RTL.
I don't understand what you mean here. When you write a mixed hebrew/english
document you have to explicitly set the language of the foreign part
anyway. The spaces would simply be part of this mechansim, no extra
"marking" required.
Whether this explicit language setting should be replaced by some automatic
algorithm is a different issue that has been discussed. But even if such an
algorithm is implemented the result is still that each character has an
associated language that defines the direction.
> I don't know how difficult it is to code this, but I think the space
> should be "neutral", and that the direction should be decided according to
> whether the curser is currently to the right or to the left of this border
> space.
And how would you output such a neutral space to LaTeX? If you have visually
on screen
RTL LTR
where RTL is in RTL direction and LTR in LTR direction you need to decide
whether to output
\R{ LTR}LTR
or
\R{LTR} LTR}
to LaTeX. How would you decide which variant to use without an explicit LTR
property of the space? At first glance it might look as if both are
equivalent, but this is not the case if other font changes (e.g. size) come
into the play, and even if not your LTR font might have a different size of
the space as your RTL font. This is exactly the reason why spaces are not
handled specially anymore for font changes, and are output exactly as
entered.
> Lets say we have LTR RTL and the space between them. If the cursor is to
> the left - continue English (you will be able to type another space there
> and continue writing), and if you are to the right of the border space,
> continue writing Hebrew (again, you will be able to enter another RTL
> space there as well). Extra spaces should then be removed, like lyx does
> today.
>
> The same for RTL LTR.
The non-magic approach could be made to work exactly like that: If the
cursor is at such a boundary with a space, set the current font that will
be used for newly typed stuff either to the font at the left or the font at
the right, according to the rules you gave. Strictly speaking this is a bit
of magic, but I believe that in contrast to the neutral space this magic
could be implemented in a reasonable manner, because it would only affect
editing. A neutral space would require extra code in may different places.
The result would still be that each space has an associated direction, so
you could still create the other two cases of the four Stefan mentioned by
inserting and removing some temporary characters.
Georg
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
> > Definitely the non-magic solution: If you enter a space it gets the > direction (RTL or LTR) of the current font, and is drawn on screen > according to that direction (place and underlining), and cursor navigation > follows that direction. > It should not be possible to enter two consecutive spaces (one in RTL and > the other in LTR) at a direction boundary. > > This is IMO the best approach: Users see on screen exactly whether a space > is RTL or LTR. Therefore they know how the cursor will behave when > navigating. Removing the direction property from spaces might look more > user friendly at first glance, but the problem then is that you have to > perform some magic in the code that quickly gets so complicated that no > developer understands it anymore and/or it produces strange results in > some > corner cases. > The users (at least me) don't know whether the space is RTL or LTR because they don't "mark RTL code" since it is annoying to look at when writing a document in RTL. I don't know how difficult it is to code this, but I think the space should be "neutral", and that the direction should be decided according to whether the curser is currently to the right or to the left of this border space. Lets say we have LTR RTL and the space between them. If the cursor is to the left - continue English (you will be able to type another space there and continue writing), and if you are to the right of the border space, continue writing Hebrew (again, you will be able to enter another RTL space there as well). Extra spaces should then be removed, like lyx does today. The same for RTL LTR. I think this will be the most intuitive and user friendly. Miki
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
Stefan Schimanski wrote:
> 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:
This magic has been removed on purpose for the case of font changes in
general (family, size etc), because the code to support it was complicated
and despite that not even correct.
>- In "english WERBEH_english" the _ is in fact behind the W
> So in Latex you would write "english\R{HEBREW } english"
Rather "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:
This is the solution that has been implemented for general font changes
since format 259.
>"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.
Definitely the non-magic solution: If you enter a space it gets the
direction (RTL or LTR) of the current font, and is drawn on screen
according to that direction (place and underlining), and cursor navigation
follows that direction.
It should not be possible to enter two consecutive spaces (one in RTL and
the other in LTR) at a direction boundary.
This is IMO the best approach: Users see on screen exactly whether a space
is RTL or LTR. Therefore they know how the cursor will behave when
navigating. Removing the direction property from spaces might look more
user friendly at first glance, but the problem then is that you have to
perform some magic in the code that quickly gets so complicated that no
developer understands it anymore and/or it produces strange results in some
corner cases.
DISCLAIMER: I am not an RTL user, the idea behind this opinion is to make
the overall editing experience for all font attributes (size, family,
series, RTL/LTR etc) consistent.
Georg
Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
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
WANTED: users of Right-To-Left languages who want proper support in LyX 1.5
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.
spaces.png
Description: application/applefile
<>
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
PGP.sig
Description: Signierter Teil der Nachricht
