Martin Vermeer wrote:
On Fri, 08 Jun 2007 06:51:49 +0200
Andre Poenitz <[EMAIL PROTECTED]> wrote:
On Thu, Jun 07, 2007 at 11:54:55AM +0200, Stefan Schimanski wrote:
Ran Rutenberg wrote:
Hi,
I tried to write a bidi file using the four patches and I didn't see
a big difference in writing with the patches and without them. One
small problem I did find is that when writing a word in a RTL
language (the document should be a RTL document) then switching to a
LTR language and writing a space followed by a word and then
switching back to RTL and making another space and writing a third
word it appears like there is no space between the first two words,
and a double space between the second and third word (it appears that
way in the DVI as well).
On the screen it looks like this (small letters represent Hebrew,
capital represent English, LTR spaces marked by '_' - remember
reading order :
onmlk _FGHIJedcba
Yes, a remaining bug (Dov and Guy found the same problem) in the EPM
code which eliminates spaces. In fact the last entered space should
have been swallowed.
I am not sure this is a bug at all. Note that one can have a arbitrary
number of spaces in a row using similar means (ERT, math etc).
'Fixing' that would mean we need to make a decision whether the RTL or
the LTR space will survive. Any such decision is bound to be wrong in
some circumstances, so it's better avoid it and let the user remove one
of the spaces.
Andre'
I don't quite agree. What dEPM is supposed to do is prevent _visually_ adjacent
spaces. That's what it should do here too, nothing else. And I would suggest
to always remove the "inner" spaces, so, if you have, e.g., an embedded Hebrew
word in English text, the word is surrounded by L2R blanks. Most natural,
but doesn't remove of course the freedom of the user to override dEPM.
- Martin
If we *do* keep the EPM, then I tend to agree with Martin about which
space to remove. Except I would put it this way: we should keep the
space whose direction is the same as the paragraph's direction. I'm
pretty sure it's equivalent to what Martin is saying, but it's easier to
think about / implement, because it's a "syntactic" description.
