[chromium-dev] a JavaScript question: How to convert mouse coordinates into character offset

[Xiaomei Ji]

(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

[Xiaomei Ji]

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 , 6106,
6108 , 6082 , and
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)

[Xiaomei Ji]

Hi Yoav,

On Tue, Jun 2, 2009 at 12:42 PM, nakro  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 related 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
doc,
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
-~--~~~~--~~--~--~---

[chromium-dev] a brave new world for RTL languages (please comment)

[Xiaomei Ji]

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
bugsfirst)
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 parag