Stefan Schimanski wrote:
Am 31.05.2007 um 23:05 schrieb Dov Feldstern:
Stefan, you are aware of
http://permalink.gmane.org/gmane.editors.lyx.devel/80783 and
http://permalink.gmane.org/gmane.editors.lyx.devel/81100, right?
Do they answer your questions? (It's a little hard to tell in your
images what the differences are...)
Thanks for the links. Didn't know the posting. It's exactly what I was
asking. So what was the conclusion? I guess nothing was changed?
No, no conclusions. I actually started writing a longer reply to you
about it, but then figured: let's see how others feel about it. I'm
still not sure what the correct way to deal with it is.
About the bidi-algorithm: it is trivial actually to make the bidi
algorithm dumb enough to handle space like any other character.
Yeah, I figured that would be the case, and that's one of my
considerations when saying that maybe we're better off with our own bidi
algorithm, because then we could force it to act in a non-standard way
like this, if we decide we want it to; though we could also achieve the
same effect using the overrides, I think.
I did
that in one of my pictures in the last posting. Just set the is_space
variable in bidi.cpp to false in the algorithm, that's it. With that my
selection patch works
Did you see what I wrote in bugzilla about selection working now, even
without this? Whatever you did with your latest patches fixed that up...
and we have the behavior of the 1.5svn Latex
output also in the GUI.
That's nice. But we need to decide if that's what we want, and I'd like
to here other Bidi users' opinions about it. Also, if we do adopt the
current latex behavior, that'll break documents from earlier versions,
where the space did not behave this way. So documents which used to be
typeset correctly, won't be anymore. So that would require a lyx2lyx or
something. It becomes a small nightmare...
The reason I was pointing that out was that there is this mismatch
between using bidi.level(...) to detect RTL positions and asking the
font with Text::getFont. The latter does not handle spaces differently,
the former does. The result is that the cursor position (i.e.
Text::cursorX) is currently wrong if the space in front of a RTL word is
part of the RTL segment.
Yes, I see that. Yuck... I hadn't noticed it before. So yeah, there's
still a problem with selection there...
So, what should we do now? I can fix either: I can make the getFont
method to behave like the bidi algorithm, or I can make the bidi
algorithm to handle spaces like normal characters, or I can make the
cursorX method to compute the right position according to the bidi
algorithm (at the moment its logic uses both, hence the bug), hence the
bug would be gone, but we keep the difference between GUI and output.
Opinions?
Well, I'm still not sure, I'd like to hear more opinions from Bidi users...
I think my inclination is this: we "ignore" the language of spaces, and
make them behave according to the bidi algorithm (or even better, first
decide how they should be treated, according to the bidi algorithm, and
then set their language accordingly --- would that be possible? The
advantage is this: that would also make them show up on the screen as
they are treated internally, and more importantly: would make latex
treat them correctly). I bridle at the fact that we are forcing
something on the user, but OTOH I can't think of any situation where the
user would want to force different behavior. And the alternative would
also require the lyx2lyx changes...
But again, I want opinions from other Bidi users (and any other
developers, too).
Stefan
