Hi Yoav, Thanks for looking into making Chrome works better in RTL languages.
I agree with Jeremy, if you think Chrome does not work correctly in some of the cases, it would be nice to file bugs (please search the existing bugs<http://code.google.com/p/chromium/issues/list?can=2&q=label:RTL>first) with concrete information, such as in which case chrome does not work correctly, what is the current Chrome behavior, what is the behavior you expected, do other browsers behave the same. Just for your reference, as to the cursor movement, following are 2 emails I got from a developer who involved in Firefox's early development for RTL support. It helped me a lot to understand how (logically or visually) the caret moves and why. Hope it helps you too. ======== Q: caret movement for LTR/RTL text when press arrow key===== =============== Answer =================================== This question is as old as bidi editing support, and does not have a definite "right" answer. The de-facto situation is that most MS products (most notably, Windows) use logical arrow movement, whereas Mac (and Linux, I believe) use visual movement. Mozilla originally attempted to implement a distinct variant of visual movement developed at IBM: http://www-01.ibm.com/software/globalization/topics/bidiui/index.jsp (), but gradually converged toward a simpler visual algorithm, as implemented (with bugs) in Mac OS X. Note that in modern Firefox, one can switch between logical and visual movement using the hidden preference bidi.edit.caret_movement_style: http://kb.mozillazine.org/Bidi.edit.caret_movement_style. AFAIK, OpenOffice also allows the user to chose the preferred style through a preference (which has a UI). Personally, I strongly prefer visual caret movement. This is one reason why that's Mozilla's current default - as I've been unofficially in charge of bidi caret movement issues in mozilla for the last few years. There's an outstanding Mozilla bug asking to match platform convention: https://bugzilla.mozilla.org/show_bug.cgi?id=167288. "Fixing" it now is as trivial as changing the default setting of bidi.edit.caret_movement_style for Windows (this was not the case when the bug was filed), but I avoided doing that due to my strong preference for visual movement, and my belief that people preferring logical movement mostly prefer it because they've been conditioned by MS. Note that implementation-wise, visual movement is considerably more difficult than logical movement. For some more of my own musings on the topic (and related topics), in the context of Mozilla, see: https://wiki.mozilla.org/User:Uri/Bidi_editing . I hope this helps. I'll be happy to be involved in future discussions on the subject, or to answer further questions. ============= Q: shift+arrow selection and Home/End key movement on RTL/LTR mixed text Looks like Home/End key are logical key, for both pure RTL text or for mixed RTL/LTR text, they should always move the cursor to the logical beginning/ending of the line. But I tried the following in Firefox: 1. Open Gmail 2. Switch Gmail UI language to Hebrew 3. Compose a new email 4. Type the following 4 line text 4.1 one pure English line text, 4.2 one Pure RTL text, 4.3 one mixed RTL text by typing Hebrew, then English then Hebrew 4.4 one mixed RTL text by typing English, then Hebrew, Then English Home key alway move cursor to the very right of the line, and End key always move cursor to the very left of the line, which is a visual order (in RTL enviroment) In English Gmail, seems the Home/End key does not always follow logical order either. Also I am not quite clear on the selection part. If the selection is manual by pressing shift+arrow or shift+ctrl+arrow, should (or preferred/by default) the selection be logical or visual? If it is logic, is it confusing that arrow moves cursor visually, but shift+arrow move it logically? =================== Answer ================================= First, let me clarify that while the IBM spec was the basis of the original implementation in Mozilla, I don't think Mozilla (or anyone else, for that matter) ever followed it 100%, and it certainly does not do so today. That said, in this case I think Firefox actually does follow the IBM spec. Let's take the case of pressing "Home" in an all-LTR (Latin) line in RTL context (as in your section 4.1). Following the instructions on http://www-01.ibm.com/software/globalization/topics/bidiui/conversion.jsp: The special case of the Home and End positions can be solved by handling it as if there was a dummy character with a level equal to the paragraph embedding level before the line [...] So we assume the line has a dummy RTL (Hebrew) character, followed by a string of LTR characters. The dummy RTL character has a bidi embeddig level of 1, and the characters of the English text (specifically, the first [leftmost] one), has a bidi embedding level of 2. After Home, End and Newline, the cursor level is set to the paragraph embedding level. The paragraph embedding level in our example is 1 (basic RTL), so that's what the "cursor level" is set to - If the cursor level is equal to the level of the previous character, the cursor must be displayed after this character ("after" is on the right for even levels, on the left for odd levels). So the level of the previous (dummy) character is 1, and the level of the next character is 2. The cursor level, as we said is 1, that is, equal to that of the previous "character", and therefore the cursor should be placed after that dummy character. Now the first dummy RTL character, had it been real, would have appeared on the rightmost edge of the line (if you don't trust me on this I can explain). Therefore, the cursor should be displayed immediately after it, that is, still, at the rightmost edge of the line. An attempt for an intuitive explanation why this is "correct": For example, in the case of an all-LTR line in RTL context, the logical beginning of the line could be mapped to either the left or right of the line. The left of the line "makes sense" as the logical beginning if you're going to type in more LTR - the new LTR char you type should appear to the left of the leftmost current LTR char. However, since the overall context is RTL, it's equally plausible (and perhaps more so) that you're going to type an RTL character. If you do so, the RTL character will appear to the right of the rightmost current LTR character. Therefore placing the cursor at the right edge of the line is a fair representation of the logical beginning if you assume RTL is what's going to be typed next. --- Regarding caret movement when shift is pressed (and selection is performed): I "borrowed" this behavior into Mozilla/Firefox (as the default, you can disable it using the hidden pref I mentioned earlier) from Mac OS. It's a bit confusing at first, but I actually find that it's the most useful, since when you're selecting, you're going to end up with a logically-contiguous selection anyway, so it makes sense to grow or reduce it one character at a time. If you leave caret movement visual when selecting (as was the case until before Firefox 2, I believe), you end up with (sometimes large) chunks of text becoming suddenly selected or unselected as a result of a single shift-arrow operation. I find this confusing and counter-intuitive (although, to be honest, others, like you, find the current behavior confusing). I think that while tthe current behavior seems weird when you're just playing with it, its usefullness becomes more apparent when you actually have to deal with selecting portions of massively-bidirectional text (e.g. markup where the tags are LTR but the text is RTL). I'll be happy to clarify and answer further questions if required. ============================ end =========================== Thanks, Xiaomei On Tue, Jun 2, 2009 at 9:21 AM, nakro <[email protected]> wrote: > > hey jeremy, i hope this text below would come out right > > יואב Zilberberg הוא 123 but!!! אולי > > even if you cut & paste the below to notepad (assuming you have a > hebrew keyb support) > you will see that the caret in windows itself moves in a crazy way > > since i am a programmer for a long time i know the reason for it (also > in my prog career got > a chance to talk to MS ppl and they hate it too ... there is a rumor > that will bill gates > saw what they did with hebrew he nearly killed those programmers) > > but just travel with the cursor on this text and you will see the joke > in windows itself > > i thought it would be very cool if chrome and other google products > would support a Sane hebrew > (cold also be a huge benefit for chrome, making RTL right!) > > regardless, once i get the builds of chrome right, i will move to fix > hebrew bugs in chrome > just thought it would be cool to get it ALL right > and you must have some native hebrew/arab speaking ppl in chrome > ask them what they think of the "native" windows support > > and once again, i encourage you to select with the mouse the text and > see how windows behaves > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
