Am 03.06.2007 um 23:12 schrieb Dov Feldstern:
Stefan Schimanski wrote:* rtlspaces.patch: There is a inconsistency between the font of spaces at RTL<->LTR boundaries. The whole space problem is discussed in http://permalink.gmane.org/gmane.editors.lyx.devel/ 80783. An illustration of the current situation and the one after this patch are visible at http://article.gmane.org/ gmane.editors.lyx.devel/86342 in the second picture. A discussion of the inconsistency can be found in http:// article.gmane.org/gmane.editors.lyx.devel/86425. (fixes http:// bugzilla.lyx.org/show_bug.cgi?id=3789). Dov had sent a very good in-depth discussion and comparison to LyX 1.3 at http:// permalink.gmane.org/gmane.editors.lyx.devel/80783. If somebody has an opinion about this issue, please speak up. I think the version implemented by this patch is simple on the one hand, but also implements the behavior of Latex. And I think it is not too bad that it does not hide anything from the user or is doing magic he cannot understand.*I* like this, but I foresee a lot of resistance from users. Let's see what other's say, I'll still try to ask about it on the users' list. Meanwhile, the other patches shouldn't wait for this one --- they should be committed ASAP.We also have to allow spaces on both sides of a RTL boundary:No, if I understand your meaning, this is not correct. RTL text is *not* an inset, there should be no fake spaces there. The previous behavior was correct. The boundary only serves exactly for what it is being used for now. But there are no fake spaces.
But the EPM code is now wrong then. If the space is RTL you get this weird situation:
logical: abc[ DEF] ghi visual: abc[FED ] ghiThe have two spaces visually. But you cannot add one between c and F because both are next to a space (logically).
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
