bug#68339: [patch] Set the IME window font to an appropriate size

> From: dANiuu zHaO <[email protected]>
> Date: Sun, 2 Aug 2026 11:50:27 +0800
> 
> I implemented the fix for this issue based on Vim's approach. I tried using the ImmGetCompositionFont API —
> it works. I have a simple example that can be used for testing:
> https://github.com/zHaOdANiuu/emacs-w32-draw-preedit.patch/blob/main/example/ime-get.cpp
> However, it only works in a simple w32 window. It has no effect inside Emacs.

I guess that's because Emacs is built as a console application, or
perhaps because we don't do something we should do when registering
our window classes.

> I don't know why it doesn't work in Emacs. Apparently, Vim's Windows developers must have also encountered
> this problem — they store a font object of type HFONT globally, retrieve the data via the GetObject function,
> and then set it with ImmSetCompositionFont.

I think this is good enough for our purposes, and the fact that the
patch is quite small is encouraging.

> This approach does work in Emacs. I obtained the font object via FRAME_FONT (f) and got the HFONT handle
> using the FONT_HANDLE macro from w32font.h, then set the font size — and it works.

Good!

> However, there is a problem: when zooming the UI in Emacs by holding Ctrl + mouse wheel
> (C-mouse-wheel-text-scale), the font is zoomed, but the IME window font does not zoom along with it.

Does it not work even if you start the composition _after_ changing
the font via the mouse-wheel?  If so, I think it's because FRAME_FONT
gives you the default font, which doesn't take face-remapping (which
is how text-scale works in Emacs) into account.  To get the font after
remapping, you need to do something like:

  . call lookup_basic_face (W, F, DEFAULT_FACE_ID), where W and F and
    the window and the frame; this gives you a face ID
  . use FACE_FROM_ID to get 'struct face' from the above ID
  . obtain the font as face->font
  . if any of that fails, use FRAME_FONT as you do now

> Similarly, I found that the w32_system_caret_x and w32_system_caret_y variables are probably not updated
> during UI scaling either, which causes the IME window to be offset when the UI is zoomed significantly.

This is a separate problem, so should be fixed separately.  Please
submit a separate bug report, and let's discuss it there.

Last, but not least: this patch is small enough to accept it without
copyright assignment, but for us to be able to accept further
contributions from you, you need to sign the copyright-assignment
agreement.  If you agree, I will send you the form to fill and the
instructions to go with it.

Thanks.