GNOME Bugzilla – Bug 314657
gtkimcontextime.c:preedit's font is too large
Last modified: 2006-10-12 20:54:55 UTC
Please describe the problem: If gtk_im_context_set_use_preedit is FALSE, preedit's font is larger than widget's. When lfHeight member of logfont is minus, ImmSetCompositionFont does not function correctly. So if lfHeight is minus, lfHeight has to be converted to plus. And there is one more bug. logfont is not freed. g_free is needed. Steps to reproduce: 1. turn on IME. Actual results: Please see screenshot. Expected results: preedit's font and widget's are the same sizes. Does this happen every time? every time Other information:
Created attachment 51420 [details] screenshot
Created attachment 51421 [details] [review] patch for gtkimcontextime.c
I wonder if this is a problem any longer with current CVS cairo where the lfHeight is set to the negative of what it was previously, meaning fonts got a bit bigger (at least for Latin scripts). (This was done so that the GTK+ font sizes match what other Win32 toolkits/native apps use if you for instance ask for "Arial 12". See https://bugs.freedesktop.org/show_bug.cgi?id=4593) Do you build cairo yourself? Could you check with cairo from CVS (the BRANCH_1_0 branch).
Yes, I build cairo myself. I checked with cairo from CVS, but the result was the same.
Hmm, do I understand correctly, is this just a workaround for a bug in ImmSetCompositionFont? To convert from negative lfHeight (= negative em height) to positive lfHeight (cell height), where both are in "logical units" which for the default mapping used by gdk-win32 means pixels, one would need to know the ratio of the font's em height to cell height, no? What has LOGPIXELSY got to do with it? Or is the bug in ImmSetCompositeFont such that the patch effectively just workarounds it, even if it strictly speaking doesn't correctly convert from em height to cell height?
Ah! I mistook. I had understood that negative lfHeight is physical uints (= negative px height). Therefore I used the formula that is for converting by LOGPIXELSY. My patch is incorrect although the result of operation looks correct.
Created attachment 53073 [details] This is a test program.
updating patch status according to comment 6
I confirmed that this problem occurred equally on latest version (GTK+-2.10.6, Pango-1.14.5, cairo-1.2.4). But This problem is very minor and most people will not be troubled. Takuro Ashie (who is an author of imime) said that he investigated this problem. However, he seems to be busy, so he does not have a time for this problem. Now I cannot suggest new something about this, too. Let's assume this a resolution. If I get new information, I will report it some other time.