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
