[chromium-dev] a JavaScript question: How to convert mouse coordinates into character offset
(I've send this question to webkit-dev mailing list, but have not got any responses yet). I am trying to write a JavaScript in Chrome to find the word user moused over, which needs to convert the mouse coordination (x,y) into character offset. I know FireFox supports event.rangeOffset, which is the *character* offset the cursor is at within the element. Given English word, using this offset, I can find the previous and next spaces and know the word under the cursor. But seems that Webkit (Chrome's layout engine) does not support event.rangeOffset. Then, how to find the word user moused over? or how to convert the event.clientX to the *character* offset within an element? My understanding is that it must involve encoding/font/font size/style, but I do not have clear idea on how it works. Appreciate any input. It does not need to be complicated/completed (such as to support RTL languages as well), I can start with English and/or some other simple script such as Chinese. Thanks for your help! Xiaomei --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Windows CRichEditCtrl] question on parenthesis handling in right-to-Left CRichEditCtrl
For RTL locales, our current layout of omnibox and textfield are left-to-right, which is not right, and there are 5 bugs related to this wrong layout (issue 6101 http://crbug.com/6101, 6106http://crbug.com/6106, 6108 http://crbug.com/6108, 6082 http://crbug.com/6082, and 10931http://crbug.com/10931 ). I am trying to change the layout of omnibox and textfield to be right-to-left using WS_EX_LAYOUTRTL instead of WS_EX_LAYOUTRTL | WS_EX_RTLREADING. But I am stuck on an issue: how to display the English parentheses correctly in RTL CRichEditCtrl. Following is how the parenthesis should be displayed in RTL context (which matches how parenthesis is handled in HTML). In RTL directionality however, unless surrounded by LTR characters on both sides, U+0028 is displayed as ). The closing parenthesis, U+0029, is also mirrored in this way, as are a whole bunch of other characters, including all the brackets. Which means, the English parenthesis need to be correctly mirrored, and it could be changed while typing (depends on the surrounding characters, U+0028 might be ) or (). Looks like CRichEditCtrl handles Hebrew parenthesis correctly (when IME is set as Hebrew), but it does not handle English parenthesis correctly. In English IME, U+0028 is always displayed as (. For example, the following characters (in logical sequence) abc(ABC (where ABC represents Hebrew characters) will be displayed as CBAabc( in RTL CRichEditCtrl, instead of CBA)abc I did not figure out whether CRichEditCtrl has any option to make the RTL CRichEditCtrl to work correctly for parenthesis as that of RTL html page. My questions are: 1. Do you know whether there is any flag in CRichEditCtrl to handle those opening/closing punctuations correctly ? Looks like RTL CRichEditCtrl does not treat punctuation the same way as HTML does, for example, Yahoo! should be displayed as !Yahoo in RTL context, but it is displayed as Yahoo! in RTL CRichEditCtrl. 2. If CRichEditCtrl does not support this out of the box, we can do the dirty and hard work to make it work. It wont be easy since we need to handle all kinds of opening/closing punctuations, and we need back-trace to change the punctuation depending on the surrounding characters (for example, after abc, U+0028 will be displayed as ), but if we type in d, ) need to be changed to (.), and we might need some states-saving as well. I think the performance in textfield and omnibox will be degraded a lot by those. Is there any better way? Would appreciate any input! Thanks, Xiaomei --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: a brave new world for RTL languages (please comment)
Hi Yoav, On Tue, Jun 2, 2009 at 12:42 PM, nakro yoav.zilberb...@gmail.com wrote: *sigh* i wrote such a splendid reply but chrome entered one of his moods and refused to pop out of the taskbar here is the much shorter version : tell your friend at FF that at least on 3.0.10 the Ctrl+right shift do not work (try www.google.com and see in the edit control) also, i failed to see the logic in his reasoning for why visual selection is a bad thing if you are located anywhere in a text, and you press SHIFT + LEFT, when is it ever a bad idea to take the char to your left ? never! really never (even if you imagine numbers or other things) At the very beginning of the email, he mentioned that This question does not have a definite right answer.. I think shift+arrow follows logical order is because it is a selection operation, which often used for cut/copy/paste, in which, it makes sense to copy the text that are logically(not visually) continuous together. There is a chrome bug http://crbug.com/8141related to shift+arrow. There are some native speakers who actively working/commenting on the bug. From the bug (and its related bugs) history, looks like logical order is what they are expecting as well. Again, both Uri and the IBM document mentioned selection could follow visual or logical order. And Chrome could provide a toggle between visual order and logical order, like what Firefox does. But I do not think we are in that stage yet. nvm, as for chrome, just one example : if you download a file (3.0.183.0 (17405)) with hebrew UI you will see the localized version of this file could harm but the buttons are to the right of this message which would seem awkward but maybe you thought it was a good thing, do you have some design doc about how you wanted RTL to look ? I think that is a bug. Could you please kindly file a bug? If you think Chrome does not work correctly in any case, you could file a bug. And it is helpful to file bug with concrete information (you can search the bugs xlyuan filed for reference). Chrome is still improving its quality in RTL languages, and we might overlooked some issues before. If there is doubt on whether the bug you filed is a bug or not, we can discuss it. We do have a UI mirroring infrastructure design dochttp://dev.chromium.org/developers/design-documents/ui-mirroring-infrastructure, which focused mostly on how Chrome implement its UI mirroring in windows. another example, still in that area, in the DL shelf, the pie chart grows CW (good!) and in the download tab (Ctrl+J) it shows it CCW (not to mention that the file is displayed in the middle of the text between the DL speed and size funny!) but which one did you think is the more correct behavior ? CW ? CCW ? anyways it has to be consistent I agree that it should be consistent. But I am not sure which way is more intuitive to native speakers. Could you please kindly file a bug? There are some experienced/knowledgeable native speaker developers, and there are some native speakers actively working with us to improve Chrome's quality. We can discuss the desired behavior in the bug. i would actually like to code all these fixes myself, because i am quite excited about chrome programming but how does one know which way you ppl decided is the right way ? We'd love if you could contribute. As I mentioned before, we have talented and passionate native speakers in chromium community. The best way to start contribute is to file bug with concrete information, and *we* (not only chrome programmer) can discuss the right solution. It is always a good idea to track issues down, and tackle them one by one. Thanks, Xiaomei --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
