]> asedeno.scripts.mit.edu Git - PuTTY.git/commit
Refactor the font handling code: I've moved all the code that
authorSimon Tatham <anakin@pobox.com>
Sat, 22 Mar 2008 11:40:23 +0000 (11:40 +0000)
committerSimon Tatham <anakin@pobox.com>
Sat, 22 Mar 2008 11:40:23 +0000 (11:40 +0000)
commit71d802bdb6a1885f01210ac18f9d656120f087c5
treea35a79e78426566e0d591514527c71de01b1f462
parent822628246ebf0036c83f0f6eba4233e518433249
Refactor the font handling code: I've moved all the code that
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).

In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)

[originally from svn r7933]
Recipe
unix/gtkfont.c [new file with mode: 0644]
unix/gtkfont.h [new file with mode: 0644]
unix/gtkwin.c