XIM: preedit problems at over-the-spot style

VERIFIED FIXED

Status

()

Core
Internationalization
P3
minor
VERIFIED FIXED
18 years ago
8 years ago

People

(Reporter: Masaki Katakai, Assigned: Hidetoshi Tajima)

Tracking

({inputmethod, intl})

Trunk
x86
Linux
inputmethod, intl
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [r=erik])

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
When over-the-spot style, there are some problems,

 - preedit isn't rendered at correct position at first startup

   At startup, IMESetFocusWidget() is called with x=0,y=0,h=1,w=1.
   We need to update preedit area - height and width of focused
   window when the window is resized.

 - SetXICBaseFontSize() and SetXICSpotLocation() are called
   but not needed

   These functions should be called only when the cursor position is
   updated. However, these are called every time by timer because
   oldy is stored after + compEvent.theReply.mCursorPosition.height,

       spot.y = compEvent.theReply.mCursorPosition.y +
                compEvent.theReply.mCursorPosition.height;

       oldy = spot.y;

  but it will be compared with compEvent.theReply.mCursorPosition.y
  at next time. So the following always true by mistake.

 - It depends on Linux distribution and user's setting of fontpath,
   however, italic fonts are used for preedit and status drawing.

    gPreeditFontset = gdk_fontset_load("-*-*-*-*-*-*-16-*-*-*-*-*-*-*");

   It should be,

    gPreeditFontset = gdk_fontset_load("-*-*-*-r-*-*-16-*-*-*-*-*-*-*");

   to get regular font.

I made a patch already. I'll ask tajima@eng.sun.com to
review the patch, then post the patch.
(Assignee)

Comment 1

18 years ago
I attached the patch proposed by Masaki to bug 53989. r=tajima@eng.sun.com.
Status: NEW → ASSIGNED
(Assignee)

Comment 2

18 years ago
r=somebody@netscape.com has been wanted.
(Assignee)

Comment 3

18 years ago
r=somebody@netscape.com has been wanted.
(Assignee)

Updated

18 years ago
Keywords: review

Comment 4

18 years ago
Please see my comments in bug 53989, and please attach a new patch to this bug
report.
(Reporter)

Comment 5

18 years ago
OK, I'll attach the new patch.
(Reporter)

Comment 6

17 years ago
Created attachment 18857 [details] [diff] [review]
changes for this problem, updated as erik's comments

Comment 7

17 years ago
Masaki, are you sure that you attached the right patch? It does not seem to
have the font-related changes in it.
(Reporter)

Comment 8

17 years ago
Created attachment 18866 [details] [diff] [review]
sorry, here is correct patch

Comment 9

17 years ago
The 2nd patch does not address the comments that I made in bug 53989. Also, it
contains the patch for bug 53989. It should not contain that patch. Please keep
the patches for these bugs separate.

See the following comments in bug 53989:

  2000-10-25 11:49
  2000-10-27 17:19
(Reporter)

Comment 10

17 years ago
Created attachment 18922 [details] [diff] [review]
sorry again, I attached wrong file. Here is correct one.

Comment 11

17 years ago
r=erik
Whiteboard: [r=erik]

Updated

17 years ago
Keywords: intl

Comment 12

17 years ago
Changed QA contact to katakai@japan.sun.com.
QA Contact: teruko → katakai
(Reporter)

Comment 13

17 years ago
patch checked in by Toshi.
(Reporter)

Comment 14

17 years ago
checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
One problem related to this bug still remains.

If you enter "<<aiueo>>abcdef<<kakikukeko>>" in Japanese code,
<<kakikukeko>> is displayed with bold font.

Should I file a new bug?
Yes, file a new bug.

Comment 17

17 years ago
I filed bug 78704.
(Reporter)

Comment 18

17 years ago
Marked as VERIFIED, as Koike-san's comments.
Status: RESOLVED → VERIFIED
Keywords: inputmethod
You need to log in before you can comment on or make changes to this bug.