On Tue, Mar 12, 2013 at 8:29 AM, Shezan Baig <shezbaig...@gmail.com> wrote:
> On Tue, Mar 12, 2013 at 12:18 AM, Ryosuke Niwa <rn...@webkit.org> wrote: > >> Have you tested your code with bidirectional text? I don't think using > >> block caret will work due to the way offsets at bidi-level boundary > works in > >> WebKit. In particular, suppose we have, in the document/byte order, > ABC123 > >> where ABC are strongly RTL letters in a LTR block. Then this text is > >> rendered as: > >> 123CBA > >> > >> If we were to place logical/DOM offset at where they appear visually, we > >> have: > >> (0)1(1)2(2)3C(5)B(4)A(3)(6) > > > > > > Oh oops, I'm sorry. I messed this up. It should be: > > (0)1(5)2(4)3C(2)B(1)A(3)(6) > > instead. > > > >> i.e. At offset 3, the caret will visually appear on the right of "A". If > >> you were just setting the caret width, the caret will look as if we're > >> inserting a character on the right of "A", which is extremely > misleading to > >> a user. > > > Our application right now doesn't allow for bidi text, so this isn't > currently an issue for us. I haven't looked at the details, but if we > were to support this in the future, I think the caret rendering code > would simply determine whether the next character is RTL or not, and > if so, it would extend its width in the opposite direction. > 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". Also, I don't understand why offset 3 would be rendered after A -- > shouldn't it be rendered before 1 since that is where the next > character would be inserted? (or maybe between 3 and C, I'm not > familiar enough with the bidi rules). If it is rendered after A right now, then I'm guessing that is just a bug, and whether or not the caret is 1px or 20px wide seems equally misleading to the user. There is no rule or specification for this. We followed NSTextView's convention and this is the expected behavior. In particular, it is NOT a bug. If we're supporting the overtype mode with block caret, we need to solve this problem. - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
