code, which would have coped badly if ever asked to select the first
font in the list at a size smaller than it supported. Luckily the
first font tended to be one of the X numeric aliases (e.g. 10x20)
which was stored with size zero, so this probably didn't actually come
up for anyone, but better safe than sorry.
[originally from svn r9910]
will not even initialise sbstring[0], so we shouldn't even look at it
let alone depend on it to tell us the desired character was absent.
[originally from svn r9465]
deprecated g_strcasecmp (since all the strings being compared are
parts of XLFDs and won't be in interesting character sets anyway).
[originally from svn r9376]
hadn't previously noticed, but Pango was helpfully re-reversing text
that PuTTY's own bidi module had already reversed, leading to Arabic
text being wrongly displayed and also total chaos when you move the
cursor over it or try to cut and paste it.
[originally from svn r9294]
by introducing a wrapper around an individual unifont which falls back
to Pango (which already has built-in fallback) in the case where the
selected font doesn't support the glyph in question.
The wrapper itself is a (vestigial) subclass of unifont, to minimise
disturbance at the call sites.
[originally from svn r9293]
individual font implementation as wchar_t, rather than having to be
converted by the client into the appropriate MBCS/SBCS.
This also means I can remove 'real_charset' from the public-facing
contents of the unifont structure.
[originally from svn r9292]
font operations are now done directly using Xlib calls, and the only
interaction with GDK within the x11font mechanism is to get the X ids
for drawables, GCs and the X display itself.
This should remove an obstacle to porting to GTK3, and also makes the
XFontStruct for loaded fonts more readily available, which I hope will
come in handy for another plan I have in mind.
[originally from svn r9289]
into a single gdk_draw_layout() where conveniently feasible, after
some work with xtrace revealed this as a major source of pterm's
slow display updates when using client-side fonts.
Ideally we ought to be able to do better. I know exactly what
sequence of X protocol operations I want to see on the wire, but I
don't know how to persuade Pango to generate them.
[originally from svn r8558]
versions >= 2.0 (when the new list boxes came in) but < 2.4 (when
the new combo boxes came in). Since some combo boxes are handled
using the old list-box code, this means that the two lots of code
can both be compiled in at once in some situations!
[originally from svn r8031]
filter checkboxes to filter the currently selected font out of the
family list and then does something in one of the other list boxes
or the size edit box.
[originally from svn r7990]
the font config box and then invoking the unifontsel causes the box
to come up empty rather than populated with that font. Turns out
that I completely forgot to have pangofont_canonify_fontname()
return the flags word, ahem.
[originally from svn r7988]
client- and server-side fonts into a single namespace was mainly to
hope there would naturally be no collisions, and to provide
disambiguating "client:" and "server:" prefixes for manual use in
emergencies.
Jacob points out, however, that his system not only has a namespace
clash but worse still the clash is at the name "fixed", which is our
default font! So, modify my namespace policy to use the
disambiguating prefixes everywhere by default, and use _unprefixed_
names only if the user types one in by hand.
In particular, I've changed the keys used to store font names in
Unix saved session files. Font names read from the new keys will be
passed straight to the new unifont framework; font names read from
the old keys will have "server:" prepended. So any existing
configuration file for GTK1 PuTTY should now work reliably in GTK2
PuTTY and select the same font, even if that font is one on which
your system (rather, your client+server combination) has a font
namespace clash.
[originally from svn r7973]
we can now build and run successfully using both GTK1 and GTK2 by
giving appropriate options to make. (Specifically, to override the
default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".)
[originally from svn r7966]
selector. I had previously been worried that the default of not
showing aliases interacted badly with the default actual font
_being_ specified as an alias. One of those defaults had to change,
and I've decided which: `fixed' is staying as Unix PuTTY's default
font in defiance of GTK2's vigorous encouragement of Pango.
[originally from svn r7960]
string. Without this, Richard B reports that Pango 1.18 will treat
_anything_ as valid, which means PuTTY can never fall back to X
fonts.
[originally from svn r7956]
font selector: I had got the row and column counts in
gtk_table_new() back to front, so the space on the right was the
padding around five empty table columns! (And apparently a GtkTable
silently expands if you try to use rows that don't exist, which is
why I hadn't already noticed.)
Fixed that, and added some padding around the entire table. I think
my font selector is now finished, except for any bug fixes that come
up in testing.
[originally from svn r7954]
during an entire run of unifontsel (because unifontsel_set_name was
either not called at all, or called with a name that didn't
correspond to any known font). In this situation we grey out the OK
button until a valid font is selected, and we have
unifontsel_get_name return NULL rather than failing an assertion if
it should be called in that state. The current client code in
gtkdlg.c should never encounter a NULL return, since it only calls
it after the OK button is clicked, but I've stuck an assertion in
there too on general principles.
[originally from svn r7953]
character at a time centred in its character cell, as we do for
Pango. Gives much better results for those non-monospaced fonts
which are usable as terminal fonts, and shows up the problems with
the others more readily. (In particular, this means the preview pane
in the font selector now warns you there will be trouble if you
select such a font.)
[originally from svn r7949]
selectors, preserve their most recent size selection as faithfully
as possible. We do this by having a secondary size variable
indicating what they _intend_, so we can come back to their intended
size even after going through a font which doesn't include it.
[originally from svn r7947]
we can call it both when the drawing area changes size and when the
selected font changes. As a result, the preview pane doesn't start
off blank any more.
[originally from svn r7945]
them automatically. If the user selects an alias in the font
selector, they get that alias copied literally into the output font
name string; when they return to the font selector, the alias is
still selected. We still _can_ resolve aliases, but we only do it on
demand: double-clicking one in the list box will do the job.
[originally from svn r7944]
instead of alphabetical order. This is more than cosmetic: it's
important because the first one in the list is selected by default.
[originally from svn r7941]
latter require manual input to the Makefile, since the Pango
developers in their unbounded wisdom (that is, unbounded below)
didn't bother to start providing the PANGO_VERSION macros until
release 1.16 - ten releases _after_ everything I'm trying to check!
[originally from svn r7940]
sizable TODO at the top of gtkfont.c - but it's basically functional
enough to select fonts of both types, so I'm checking it in now
before I accidentally break it.
[originally from svn r7938]
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]
Simon Tatham