Closed
Bug 230235
Opened 21 years ago
Closed 21 years ago
AIX+GTK2: Preedit string is not highlighted properly
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: pkwarren, Assigned: pkwarren)
References
Details
(Keywords: inputmethod, intl)
Attachments
(1 file, 1 obsolete file)
5.20 KB,
patch
|
masaki.katakai
:
review+
blizzard
:
superreview+
|
Details | Diff | Splinter Review |
This is the same problem as was reported in Bug 199683 for GTK1. AIX returns the
feedback style XIMUnderline | XIMReverse to signify that the preedit string
should be both underlined and reversed. Currently, the GTK2 code does the following:
if (PANGO_ATTR_UNDERLINE)
feedback = NS_TEXTRANGE_CONVERTEDTEXT
else if (PANGO_ATTR_FOREGROUND)
feedback = NS_TEXTRANGE_SELECTEDRAWTEXT
I would like to make the GTK2 version work similarly to the GTK1 version, so
that it uses text style NS_TEXTRANGE_SELECTEDCONVERTEDTEXT if both attributes
are present.
Assignee | ||
Comment 1•21 years ago
|
||
- Adds support for preedit style XIMReverse | XIMUnderline.
- Removes duplicate code.
- Uses g_free on strings allocated with g_utf8_to_utf16 (leaking these before).
Assignee | ||
Updated•21 years ago
|
Attachment #138539 -
Flags: superreview?(blizzard)
Attachment #138539 -
Flags: review?(katakai)
Comment 2•21 years ago
|
||
Comment on attachment 138539 [details] [diff] [review]
Patch v1
>+ uniStr = NULL;
>+ if (aPangoAttr->start_index > 0)
>+ uniStr = g_utf8_to_utf16(aPreeditString,
>+ aPangoAttr->start_index,
>+ NULL, &uniStrLen, NULL);
Multiple lines after an if (), please use braces like below:
>+ if (uniStr) {
>+ START_OFFSET(count) = uniStrLen;
>+ g_free(uniStr);
>+ }
>+
>+ uniStr = NULL;
>+ uniStr = g_utf8_to_utf16(aPreeditString + aPangoAttr->start_index,
>+ aPangoAttr->end_index - aPangoAttr->start_index,
>+ NULL, &uniStrLen, NULL);
Whitespace here.
>+ if (uniStr) {
>+ END_OFFSET(count) = START_OFFSET(count) + uniStrLen;
>+ SET_FEEDBACKTYPE(count, feedbackType);
>+ g_free(uniStr);
> }
> } while ((count < aMaxLenOfTextRange - 1) &&
> (pango_attr_iterator_next(aFeedbackIterator)));
That's all I have from a coding standpoint but I didn't really look at it for
technical correctness. I'm hoping katakai can do that for me.
Attachment #138539 -
Flags: superreview?(blizzard) → superreview-
Assignee | ||
Comment 3•21 years ago
|
||
I will add the braces to the final patch, however I don't understand what
whitespace error you want fixed. Can you elaborate?
Comment 4•21 years ago
|
||
Comment on attachment 138539 [details] [diff] [review]
Patch v1
>+ PRUint32 feedbackType;
>+ // XIMReverse | XIMUnderline
>+ if (aPangoAttrUnderline && aPangoAttrReverse) {
>+ feedbackType = NS_TEXTRANGE_SELECTEDCONVERTEDTEXT;
>+ // Use the feedback attribute with the smaller end_index
>+ aPangoAttr = aPangoAttrUnderline;
>+ if (aPangoAttrUnderline->end_index > aPangoAttrReverse->end_index)
>+ aPangoAttr = aPangoAttrReverse;
Could you explain the purpose of this code?
>+ }
Attachment #138539 -
Flags: review?(katakai) → review-
Assignee | ||
Comment 5•21 years ago
|
||
The purpose of the code which chooses the smaller end_index is to address the
issue of when some of the preedit string should be highlighted while some of the
preedit string should be underlined. On AIX, when you hit the 'convert' key to
change to kanji, and then hit the 'non-convert' key, sometimes the preedit
string is shown with certain portions highlighted+underlined and other portions
underlined. For example, look at the following (with a custom GTK build which
outputs XIM debug information):
XIMPreeditDraw
(
caret=0
chg_first=0
chg_length=2
text = {
length=3
feedback[0]=0x3 (XIMReverse | XIMUnderline)
feedback[1]=0x2 (XIMUnderline)
feedback[2]=0x2 (XIMUnderline)
encoding_is_wchar=0
string.multi_byte[0]=164
string.multi_byte[1]=171
string.multi_byte[2]=164
};
)
This is the output of the call_data pointer which is passed to the
PreeditDrawCallback. It says that there should be a preedit string of three
characters, with the first character underlined and highlighted, and the last
two characters only underlined. This gets passed through pango and ends up
looking like this in the IM_set_text_range loop in Mozilla:
1st iteration:
aPangoAttrUnderline: 0x214752c8, start_index: 0, end_index: 9
aPangoAttrReverse: 0x214a3ec8, start_index: 0, end_index: 3
2nd iteration:
aPangoAttrUnderline: 0x214752c8, start_index: 0, end_index: 9
aPangoAttrReverse: NULL
3rd iteration:
aPangoAttrUnderline: NULL
aPangoAttrReverse: NULL
So to get the correct output in the example above, we need to choose the
attribute with the smaller end_index. If we don't, the entire string will be
shown in the style XIMUnderline|XIMReverse.
I hope this makes sense. I am not very familiar with pango, so I'm sure there is
probably a better method than my current one. Maybe pango_attr_iterator_range
would be good to use here instead?
Assignee | ||
Comment 6•21 years ago
|
||
This seems like a better solution. I have switched to using
pango_attr_iterator_range instead of using each attribute's start_index and
end_index.
Attachment #138539 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #138634 -
Flags: superreview?(blizzard)
Attachment #138634 -
Flags: review?(katakai)
Assignee | ||
Comment 7•21 years ago
|
||
Just thought I'd add some additional information. In my example above, this was
the output of the pango attributes in the IM_set_text_range loop:
1st iteration:
aPangoAttrUnderline: 0x214752c8, start_index: 0, end_index: 9
aPangoAttrReverse: 0x214a3ec8, start_index: 0, end_index: 3
2nd iteration:
aPangoAttrUnderline: 0x214752c8, start_index: 0, end_index: 9
aPangoAttrReverse: NULL
3rd iteration:
aPangoAttrUnderline: NULL
aPangoAttrReverse: NULL
So the first patch would do the following:
- Use style NS_TEXTRANGE_SELECTEDCONVERTEDTEXT from index 0-3.
- Use style NS_TEXTRANGE_CONVERTEDTEXT from index 0-9.
Somehow Mozilla did the right thing and used the style
NS_TEXTRANGE_SELECTEDCONVERTEDTEXT for index 0-3, and NS_TEXTRANGE_CONVERTEDTEXT
for index 3-9. With the change to use pango_attr_iterator_range, I get the
following in the IM_set_text_range loop:
1st iteration:
pango_attr_iterator_range returning start: 0, end: 3
2nd iteration:
pango_attr_iterator_range returning start: 3, end: 9
3rd iteration:
pango_attr_iterator_range not called because both attributes are NULL.
So it seems that the second patch is doing the right thing - using style
NS_TEXTRANGE_SELECTEDCONVERTEDTEXT for index 0-3 and NS_TEXTRANGE_CONVERTEDTEXT
for index 3-9.
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Comment 8•21 years ago
|
||
Comment on attachment 138634 [details] [diff] [review]
Patch v2
OK for me.
Also verified working properly with Solaris ATOK, Linux ATOK and kinput2.
Attachment #138634 -
Flags: review?(katakai) → review+
Updated•21 years ago
|
Attachment #138634 -
Flags: superreview?(blizzard) → superreview+
Assignee | ||
Comment 9•21 years ago
|
||
Fixed. Thanks a lot for the reviews and testing!
Checking in nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v <-- nsWindow.cpp
new revision: 1.95; previous revision: 1.94
done
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Keywords: inputmethod
You need to log in
before you can comment on or make changes to this bug.
Description
•