On Fri, Apr 12, 2013 at 4:40 AM, Sergio Villar Senin <[email protected]>wrote:
> En 12/03/13 18:31, > - R. Niwa > escribiu: > > That doesn't work. At a bidi-level boundary, offset can jump from one > > place to another. Consider a much simpler example; the same sequence of > > letters, in logical order, ABC123 in a RTL block, which will be rendered > as: > > 123CBA > > with logical/DOM offsets placed at: > > (6)1(4)2(5)3(3)C(2)B(1)A(0) > > > > Again, at offset 3, what we're going to replace is "1" so we can't place > > the block caret on top of either "C" or "3". > > The problem is that such kind of "weird" behaviors are happening now > without overtype mode. No. For example consider the strongly LTR letters > "abc" inside a RTL block, which will be rendered as "abc". If we either > place the caret at the beginning (before 'a') or at the end (after 'c') > the next typed character will be placed at the opposite side the user > might expect based on the caret position. > That's expected. The problem here is that caret will be on top of a wrong character. That's much worse than a character being inserted at a remote location. Using my existing example, what user sees is: 123CBA or 123CBA yet what will be replaced is 1. That's insane. This is orders of magnitude worse than caret showing up as a vertical line at this location: 123|CBA And this is why just setting the width of caret will never work. - R. Niwa
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
