Open Bug 979112 Opened 8 years ago Updated 4 months ago

Support wide caret whose width is one (or more?) grapheme cluster width

Categories

(Core :: DOM: Selection, enhancement)

enhancement
Not set
normal

Tracking

()

People

(Reporter: masayuki, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: inputmethod, intl)

Attachments

(2 files)

Gecko should support wide caret. It's width should be one (or more?) graphme cluser's width.

I think that nsTextFrame should paint caret for implementing it. When caret is visible, caret needs to paint the caret with foreground color and the character with background color.

According to Ehsan (bug 38415 comment 43), he thinks this can fix in nsCaret but I still don't imagine the code yet.

This is necessary to support Korean IME on Windows completely.
We're in the process of adding touch caret support.  Do you know how this stuff works in let's say Window 8 metro mode with the touch based UI?

That being said, this should probably be fixed in nsCaret.  We may want to transfer the grapheme cluster geometry from the text frame code to nsCaret.
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailapocalypse) from comment #1)
> We're in the process of adding touch caret support.  Do you know how this
> stuff works in let's say Window 8 metro mode with the touch based UI?

I don't know the "touch caret", though.

Korean IME on Windows typically not select the composing Hangul character (only one character). Instead of that, they may use wide caret for it. For supporting native look and feel, we need to support it for some Korean IMEs.
# I tested on store apps on Win8.1 with MS's Korean IME, Korean IME doesn't show wide caret. I'm not sure this is WPF's bug or Korean IME's expected behavior. Anyway, this bug isn't so high priority.

> That being said, this should probably be fixed in nsCaret.  We may want to
> transfer the grapheme cluster geometry from the text frame code to nsCaret.

Yeah, but how does nsCaret paint the character's glyph with its background color? Currently, nsCaret doesn't paint the character glyph with its background color. This is the cause of using 2px wider caret in CJK text. (If caret rect overlaps character glyph completely, the caret isn't visible for human eyes.)

I.e., if caret draw character with background color even with normal width, we can get rid of the wider caret from CJK environment.
(In reply to comment #2)
> (In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness,
> emailapocalypse) from comment #1)
> > We're in the process of adding touch caret support.  Do you know how this
> > stuff works in let's say Window 8 metro mode with the touch based UI?
> 
> I don't know the "touch caret", though.

It's the kind of caret that you see on Windows 8 Metro, Android and iOS.

> Korean IME on Windows typically not select the composing Hangul character (only
> one character). Instead of that, they may use wide caret for it. For supporting
> native look and feel, we need to support it for some Korean IMEs.
> # I tested on store apps on Win8.1 with MS's Korean IME, Korean IME doesn't
> show wide caret. I'm not sure this is WPF's bug or Korean IME's expected
> behavior. Anyway, this bug isn't so high priority.
> 
> > That being said, this should probably be fixed in nsCaret.  We may want to
> > transfer the grapheme cluster geometry from the text frame code to nsCaret.
> 
> Yeah, but how does nsCaret paint the character's glyph with its background
> color? Currently, nsCaret doesn't paint the character glyph with its background
> color. This is the cause of using 2px wider caret in CJK text. (If caret rect
> overlaps character glyph completely, the caret isn't visible for human eyes.)
> 
> I.e., if caret draw character with background color even with normal width, we
> can get rid of the wider caret from CJK environment.

The rest of your comment makes me suspect that I don't know what this bug is really about.  Can you please attach a video showing the thing you're talking about in a native Windows application please?
This doesn't blink on Win8.1, though. On wordpad (TSF-aware), the character color is "inverted". E.g., red text becomes green text. So, it's not selection, it must be wide caret.

Seems this is not an issue anymore, as I see wide caret now. Can you confirm?

Flags: needinfo?(masayuki)

So, we still use "selected raw clause" selection instead.
https://searchfox.org/mozilla-central/rev/61f224ec08ddc6f9a93ac45c8c3c5f7159be7c2a/widget/windows/TSFTextStore.cpp#3491-3510

This is just the difference of visual style except for people who have some trouble of their eyes.

Flags: needinfo?(masayuki)
You need to log in before you can comment on or make changes to this bug.