Open
Bug 979112
Opened 11 years ago
Updated 3 years ago
Support wide caret whose width is one (or more?) grapheme cluster width
Categories
(Core :: DOM: Selection, enhancement)
Core
DOM: Selection
Tracking
()
NEW
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.
Comment 1•11 years ago
|
||
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.
| Reporter | ||
Comment 2•11 years ago
|
||
(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.
Comment 3•11 years ago
|
||
(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?
| Reporter | ||
Comment 4•11 years ago
|
||
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.
Comment 5•5 years ago
|
||
Seems this is not an issue anymore, as I see wide caret now. Can you confirm?
Flags: needinfo?(masayuki)
| Reporter | ||
Comment 6•5 years ago
|
||
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)
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•