>Yes, that's right. So does the attached make sense? It seems >to solve it for me, but I have no idea what it does to the RTL stuff.
The problems seems to be that we want to draw the cursor, even if it's not visible. To compute the height and place of the cursor, we retrieve what font the text has at the place of the cursor. While retrieving the font, we check whether we are at a RTL boundary and since the problematic revision, the RTL boundary involves whether the line is broken at that position or not. I don't really understand what influence that should have on whether we are on an RTL boundary or not. It seems to be the exact problem I was warning for back then (end november in Berlin). The case Dov tried to solve is degenerate. We use a single boundary boolean to indicate whether the the cursor is at the end of line 1 or at the beginning of line 2, but also to indicate whether we are at the R or at the L side of an RTL boundary. In this case, those principles get mixed up. The change introduced tries to fix this, but now pure text information is mixed with information how it looks like on screen. To avoid the problems, the following case always return false for isRTLboundary: Abc\n | In which | is the cursor and \n is a "soft" line break. As a consequence the answer to the question: is the font at the current position the font before or after the cursor is dependent on the breaking of the paragraph, but well... that's irrelevant if the cursor is out of view. I hope you understand this.. Vincent
