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]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* Unified font management for GTK.
|
|
|
|
*
|
|
|
|
* PuTTY is willing to use both old-style X server-side bitmap
|
|
|
|
* fonts _and_ GTK2/Pango client-side fonts. This requires us to
|
|
|
|
* do a bit of work to wrap the two wildly different APIs into
|
|
|
|
* forms the rest of the code can switch between seamlessly, and
|
|
|
|
* also requires a custom font selector capable of handling both
|
|
|
|
* types of font.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
2015-08-31 15:05:51 +03:00
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
#include <gtk/gtk.h>
|
2015-08-08 17:06:15 +03:00
|
|
|
#if !GTK_CHECK_VERSION(3,0,0)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
#include <gdk/gdkkeysyms.h>
|
2015-08-08 17:06:15 +03:00
|
|
|
#endif
|
2015-08-31 15:05:51 +03:00
|
|
|
|
2015-08-31 15:57:34 +03:00
|
|
|
#define MAY_REFER_TO_GTK_IN_HEADERS
|
|
|
|
|
2015-08-31 15:05:51 +03:00
|
|
|
#include "putty.h"
|
|
|
|
#include "gtkfont.h"
|
|
|
|
#include "gtkcompat.h"
|
|
|
|
#include "tree234.h"
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
#ifndef NOT_X_WINDOWS
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
#include <gdk/gdkx.h>
|
|
|
|
#include <X11/Xlib.h>
|
|
|
|
#include <X11/Xutil.h>
|
|
|
|
#include <X11/Xatom.h>
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Future work:
|
|
|
|
*
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
* - it would be nice to have a display of the current font name,
|
|
|
|
* and in particular whether it's client- or server-side,
|
|
|
|
* during the progress of the font selector.
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
|
2012-01-03 23:43:19 +04:00
|
|
|
#if !GLIB_CHECK_VERSION(1,3,7)
|
|
|
|
#define g_ascii_strcasecmp g_strcasecmp
|
|
|
|
#define g_ascii_strncasecmp g_strncasecmp
|
|
|
|
#endif
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* Ad-hoc vtable mechanism to allow font structures to be
|
|
|
|
* polymorphic.
|
|
|
|
*
|
|
|
|
* Any instance of `unifont' used in the vtable functions will
|
|
|
|
* actually be the first element of a larger structure containing
|
|
|
|
* data specific to the subtype. This is permitted by the ISO C
|
|
|
|
* provision that one may safely cast between a pointer to a
|
|
|
|
* structure and a pointer to its first element.
|
|
|
|
*/
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
#define FONTFLAG_CLIENTSIDE 0x0001
|
|
|
|
#define FONTFLAG_SERVERSIDE 0x0002
|
|
|
|
#define FONTFLAG_SERVERALIAS 0x0004
|
|
|
|
#define FONTFLAG_NONMONOSPACED 0x0008
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
#define FONTFLAG_SORT_MASK 0x0007 /* used to disambiguate font families */
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
typedef void (*fontsel_add_entry)(void *ctx, const char *realfontname,
|
|
|
|
const char *family, const char *charset,
|
2008-03-26 23:20:25 +03:00
|
|
|
const char *style, const char *stylekey,
|
|
|
|
int size, int flags,
|
2008-03-26 00:49:14 +03:00
|
|
|
const struct unifont_vtable *fontclass);
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
struct unifont_vtable {
|
|
|
|
/*
|
|
|
|
* `Methods' of the `class'.
|
|
|
|
*/
|
2008-03-26 00:49:14 +03:00
|
|
|
unifont *(*create)(GtkWidget *widget, const char *name, int wide, int bold,
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
int shadowoffset, int shadowalways);
|
2011-09-16 23:18:54 +04:00
|
|
|
unifont *(*create_fallback)(GtkWidget *widget, int height, int wide,
|
|
|
|
int bold, int shadowoffset, int shadowalways);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
void (*destroy)(unifont *font);
|
2011-09-16 23:18:54 +04:00
|
|
|
int (*has_glyph)(unifont *font, wchar_t glyph);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
void (*draw_text)(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
|
|
|
int wide, int bold, int cellwidth);
|
2008-03-26 00:49:14 +03:00
|
|
|
void (*enum_fonts)(GtkWidget *widget,
|
|
|
|
fontsel_add_entry callback, void *callback_ctx);
|
2008-03-27 22:41:08 +03:00
|
|
|
char *(*canonify_fontname)(GtkWidget *widget, const char *name, int *size,
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int *flags, int resolve_aliases);
|
2008-03-26 00:49:14 +03:00
|
|
|
char *(*scale_fontname)(GtkWidget *widget, const char *name, int size);
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* `Static data members' of the `class'.
|
|
|
|
*/
|
|
|
|
const char *prefix;
|
|
|
|
};
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
#ifndef NOT_X_WINDOWS
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
2015-08-08 18:35:19 +03:00
|
|
|
* X11 font implementation, directly using Xlib calls. Conditioned out
|
|
|
|
* if X11 fonts aren't available at all (e.g. building with GTK3 for a
|
|
|
|
* back end other than X).
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static int x11font_has_glyph(unifont *font, wchar_t glyph);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
|
|
|
int wide, int bold, int cellwidth);
|
2008-03-26 00:49:14 +03:00
|
|
|
static unifont *x11font_create(GtkWidget *widget, const char *name,
|
2008-03-22 21:11:17 +03:00
|
|
|
int wide, int bold,
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
int shadowoffset, int shadowalways);
|
|
|
|
static void x11font_destroy(unifont *font);
|
2008-03-26 00:49:14 +03:00
|
|
|
static void x11font_enum_fonts(GtkWidget *widget,
|
|
|
|
fontsel_add_entry callback, void *callback_ctx);
|
|
|
|
static char *x11font_canonify_fontname(GtkWidget *widget, const char *name,
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int *size, int *flags,
|
|
|
|
int resolve_aliases);
|
2008-03-26 00:49:14 +03:00
|
|
|
static char *x11font_scale_fontname(GtkWidget *widget, const char *name,
|
|
|
|
int size);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
struct cairo_cached_glyph {
|
|
|
|
cairo_surface_t *surface;
|
|
|
|
unsigned char *bitmap;
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Structure storing a single physical XFontStruct, plus associated
|
|
|
|
* data.
|
|
|
|
*/
|
|
|
|
typedef struct x11font_individual {
|
|
|
|
/* The XFontStruct itself. */
|
|
|
|
XFontStruct *xfs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The `allocated' flag indicates whether we've tried to fetch
|
|
|
|
* this subfont already (thus distinguishing xfs==NULL because we
|
|
|
|
* haven't tried yet from xfs==NULL because we tried and failed,
|
|
|
|
* so that we don't keep trying and failing subsequently).
|
|
|
|
*/
|
|
|
|
int allocated;
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
/*
|
|
|
|
* A cache of glyph bitmaps downloaded from the X server when
|
|
|
|
* we're in Cairo rendering mode. If glyphcache itself is
|
|
|
|
* non-NULL, then entries in [0,nglyphs) are expected to be
|
|
|
|
* initialised to either NULL or a bitmap pointer.
|
|
|
|
*/
|
|
|
|
struct cairo_cached_glyph *glyphcache;
|
|
|
|
int nglyphs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* X server paraphernalia for actually downloading the glyphs.
|
|
|
|
*/
|
|
|
|
Pixmap pixmap;
|
|
|
|
GC gc;
|
|
|
|
int pixwidth, pixheight, pixoriginx, pixoriginy;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Paraphernalia for loading the resulting bitmaps into Cairo.
|
|
|
|
*/
|
|
|
|
int rowsize, allsize, indexflip;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
} x11font_individual;
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
struct x11font {
|
|
|
|
struct unifont u;
|
|
|
|
/*
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
* Individual physical X fonts. We store a number of these, for
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
* automatically guessed bold and wide variants.
|
|
|
|
*/
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
x11font_individual fonts[4];
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* `sixteen_bit' is true iff the font object is indexed by
|
|
|
|
* values larger than a byte. That is, this flag tells us
|
2011-09-16 12:49:08 +04:00
|
|
|
* whether we use XDrawString or XDrawString16, etc.
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
int sixteen_bit;
|
2008-03-29 13:48:16 +03:00
|
|
|
/*
|
|
|
|
* `variable' is true iff the font is non-fixed-pitch. This
|
|
|
|
* enables some code which takes greater care over character
|
|
|
|
* positioning during text drawing.
|
|
|
|
*/
|
|
|
|
int variable;
|
2011-09-16 23:18:53 +04:00
|
|
|
/*
|
|
|
|
* real_charset is the charset used when translating text into the
|
|
|
|
* font's internal encoding inside draw_text(). This need not be
|
|
|
|
* the same as the public_charset provided to the client; for
|
|
|
|
* example, public_charset might be CS_ISO8859_1 while
|
|
|
|
* real_charset is CS_ISO8859_1_X11.
|
|
|
|
*/
|
|
|
|
int real_charset;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
/*
|
|
|
|
* Data passed in to unifont_create().
|
|
|
|
*/
|
|
|
|
int wide, bold, shadowoffset, shadowalways;
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct unifont_vtable x11font_vtable = {
|
|
|
|
x11font_create,
|
2011-09-16 23:18:54 +04:00
|
|
|
NULL, /* no fallback fonts in X11 */
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
x11font_destroy,
|
2011-09-16 23:18:54 +04:00
|
|
|
x11font_has_glyph,
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
x11font_draw_text,
|
2008-03-26 00:49:14 +03:00
|
|
|
x11font_enum_fonts,
|
|
|
|
x11font_canonify_fontname,
|
|
|
|
x11font_scale_fontname,
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
"server",
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
};
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
static char *x11_guess_derived_font_name(XFontStruct *xfs, int bold, int wide)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
Atom fontprop = XInternAtom(disp, "FONT", False);
|
|
|
|
unsigned long ret;
|
|
|
|
if (XGetFontProperty(xfs, fontprop, &ret)) {
|
|
|
|
char *name = XGetAtomName(disp, (Atom)ret);
|
|
|
|
if (name && name[0] == '-') {
|
2015-05-15 13:15:42 +03:00
|
|
|
const char *strings[13];
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
char *dupname, *extrafree = NULL, *ret;
|
|
|
|
char *p, *q;
|
|
|
|
int nstr;
|
|
|
|
|
|
|
|
p = q = dupname = dupstr(name); /* skip initial minus */
|
|
|
|
nstr = 0;
|
|
|
|
|
|
|
|
while (*p && nstr < lenof(strings)) {
|
|
|
|
if (*p == '-') {
|
|
|
|
*p = '\0';
|
|
|
|
strings[nstr++] = p+1;
|
|
|
|
}
|
|
|
|
p++;
|
|
|
|
}
|
|
|
|
|
2013-07-14 14:46:07 +04:00
|
|
|
if (nstr < lenof(strings)) {
|
|
|
|
sfree(dupname);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
return NULL; /* XLFD was malformed */
|
2013-07-14 14:46:07 +04:00
|
|
|
}
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
if (bold)
|
|
|
|
strings[2] = "bold";
|
|
|
|
|
|
|
|
if (wide) {
|
|
|
|
/* 4 is `wideness', which obviously may have changed. */
|
|
|
|
/* 5 is additional style, which may be e.g. `ja' or `ko'. */
|
|
|
|
strings[4] = strings[5] = "*";
|
|
|
|
strings[11] = extrafree = dupprintf("%d", 2*atoi(strings[11]));
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = dupcat("-", strings[ 0], "-", strings[ 1], "-", strings[ 2],
|
|
|
|
"-", strings[ 3], "-", strings[ 4], "-", strings[ 5],
|
|
|
|
"-", strings[ 6], "-", strings[ 7], "-", strings[ 8],
|
|
|
|
"-", strings[ 9], "-", strings[10], "-", strings[11],
|
|
|
|
"-", strings[12], NULL);
|
|
|
|
sfree(extrafree);
|
|
|
|
sfree(dupname);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
static int x11_font_width(XFontStruct *xfs, int sixteen_bit)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
|
|
|
if (sixteen_bit) {
|
|
|
|
XChar2b space;
|
|
|
|
space.byte1 = 0;
|
2008-03-29 13:48:16 +03:00
|
|
|
space.byte2 = '0';
|
2011-09-16 12:49:08 +04:00
|
|
|
return XTextWidth16(xfs, &space, 1);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
} else {
|
2011-09-16 12:49:08 +04:00
|
|
|
return XTextWidth(xfs, "0", 1);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static int x11_font_has_glyph(XFontStruct *xfs, int byte1, int byte2)
|
|
|
|
{
|
|
|
|
int index;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Not to be confused with x11font_has_glyph, which is a method of
|
|
|
|
* the x11font 'class' and hence takes a unifont as argument. This
|
|
|
|
* is the low-level function which grubs about in an actual
|
|
|
|
* XFontStruct to see if a given glyph exists.
|
|
|
|
*
|
|
|
|
* We must do this ourselves rather than letting Xlib's
|
|
|
|
* XTextExtents16 do the job, because XTextExtents will helpfully
|
|
|
|
* substitute the font's default_char for any missing glyph and
|
|
|
|
* not tell us it did so, which precisely won't help us find out
|
|
|
|
* which glyphs _are_ missing.
|
|
|
|
*
|
|
|
|
* The man page for XQueryFont is rather confusing about how the
|
|
|
|
* per_char array in the XFontStruct is laid out, because it gives
|
|
|
|
* formulae for determining the two-byte X character code _from_
|
|
|
|
* an index into the per_char array. Going the other way, it's
|
|
|
|
* rather simpler:
|
|
|
|
*
|
|
|
|
* The valid character codes have byte1 between min_byte1 and
|
|
|
|
* max_byte1 inclusive, and byte2 between min_char_or_byte2 and
|
|
|
|
* max_char_or_byte2 inclusive. This gives a rectangle of size
|
|
|
|
* (max_byte2-min_byte1+1) by
|
|
|
|
* (max_char_or_byte2-min_char_or_byte2+1), which is precisely the
|
|
|
|
* rectangle encoded in the per_char array. Hence, given a
|
|
|
|
* character code which is valid in the sense that it falls
|
|
|
|
* somewhere in that rectangle, its index in per_char is given by
|
|
|
|
* setting
|
|
|
|
*
|
|
|
|
* x = byte2 - min_char_or_byte2
|
|
|
|
* y = byte1 - min_byte1
|
|
|
|
* index = y * (max_char_or_byte2-min_char_or_byte2+1) + x
|
|
|
|
*
|
|
|
|
* If min_byte1 and min_byte2 are both zero, that's a special case
|
|
|
|
* which can be treated as if min_byte2 was 1 instead, i.e. the
|
|
|
|
* per_char array just runs from min_char_or_byte2 to
|
|
|
|
* max_char_or_byte2 inclusive, and byte1 should always be zero.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (byte2 < xfs->min_char_or_byte2 || byte2 > xfs->max_char_or_byte2)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
if (xfs->min_byte1 == 0 && xfs->max_byte1 == 0) {
|
|
|
|
index = byte2 - xfs->min_char_or_byte2;
|
|
|
|
} else {
|
|
|
|
if (byte1 < xfs->min_byte1 || byte1 > xfs->max_byte1)
|
|
|
|
return FALSE;
|
|
|
|
index = ((byte2 - xfs->min_char_or_byte2) +
|
|
|
|
((byte1 - xfs->min_byte1) *
|
|
|
|
(xfs->max_char_or_byte2 - xfs->min_char_or_byte2 + 1)));
|
|
|
|
}
|
|
|
|
|
2011-09-17 18:50:18 +04:00
|
|
|
if (!xfs->per_char) /* per_char NULL => everything in range exists */
|
|
|
|
return TRUE;
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
return (xfs->per_char[index].ascent + xfs->per_char[index].descent > 0 ||
|
|
|
|
xfs->per_char[index].width > 0);
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static unifont *x11font_create(GtkWidget *widget, const char *name,
|
2008-03-22 21:11:17 +03:00
|
|
|
int wide, int bold,
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
int shadowoffset, int shadowalways)
|
|
|
|
{
|
|
|
|
struct x11font *xfont;
|
|
|
|
XFontStruct *xfs;
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
2008-03-29 13:48:16 +03:00
|
|
|
Atom charset_registry, charset_encoding, spacing;
|
|
|
|
unsigned long registry_ret, encoding_ret, spacing_ret;
|
|
|
|
int pubcs, realcs, sixteen_bit, variable;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
int i;
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
xfs = XLoadQueryFont(disp, name);
|
|
|
|
if (!xfs)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
charset_registry = XInternAtom(disp, "CHARSET_REGISTRY", False);
|
|
|
|
charset_encoding = XInternAtom(disp, "CHARSET_ENCODING", False);
|
|
|
|
|
|
|
|
pubcs = realcs = CS_NONE;
|
|
|
|
sixteen_bit = FALSE;
|
2008-03-29 13:48:16 +03:00
|
|
|
variable = TRUE;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
if (XGetFontProperty(xfs, charset_registry, ®istry_ret) &&
|
|
|
|
XGetFontProperty(xfs, charset_encoding, &encoding_ret)) {
|
|
|
|
char *reg, *enc;
|
|
|
|
reg = XGetAtomName(disp, (Atom)registry_ret);
|
|
|
|
enc = XGetAtomName(disp, (Atom)encoding_ret);
|
|
|
|
if (reg && enc) {
|
|
|
|
char *encoding = dupcat(reg, "-", enc, NULL);
|
|
|
|
pubcs = realcs = charset_from_xenc(encoding);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* iso10646-1 is the only wide font encoding we
|
|
|
|
* support. In this case, we expect clients to give us
|
|
|
|
* UTF-8, which this module must internally convert
|
|
|
|
* into 16-bit Unicode.
|
|
|
|
*/
|
|
|
|
if (!strcasecmp(encoding, "iso10646-1")) {
|
|
|
|
sixteen_bit = TRUE;
|
|
|
|
pubcs = realcs = CS_UTF8;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-09-16 23:18:54 +04:00
|
|
|
* Hack for X line-drawing characters: if the primary font
|
|
|
|
* is encoded as ISO-8859-1, and has valid glyphs in the
|
|
|
|
* low character positions, it is assumed that those
|
|
|
|
* glyphs are the VT100 line-drawing character set.
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
if (pubcs == CS_ISO8859_1) {
|
2011-09-16 23:18:54 +04:00
|
|
|
int ch;
|
|
|
|
for (ch = 1; ch < 32; ch++)
|
|
|
|
if (!x11_font_has_glyph(xfs, 0, ch))
|
|
|
|
break;
|
|
|
|
if (ch == 32)
|
|
|
|
realcs = CS_ISO8859_1_X11;
|
|
|
|
}
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
sfree(encoding);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-29 13:48:16 +03:00
|
|
|
spacing = XInternAtom(disp, "SPACING", False);
|
|
|
|
if (XGetFontProperty(xfs, spacing, &spacing_ret)) {
|
|
|
|
char *spc;
|
|
|
|
spc = XGetAtomName(disp, (Atom)spacing_ret);
|
|
|
|
|
|
|
|
if (spc && strchr("CcMm", spc[0]))
|
|
|
|
variable = FALSE;
|
|
|
|
}
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
xfont = snew(struct x11font);
|
|
|
|
xfont->u.vt = &x11font_vtable;
|
2011-09-16 12:49:08 +04:00
|
|
|
xfont->u.width = x11_font_width(xfs, sixteen_bit);
|
|
|
|
xfont->u.ascent = xfs->ascent;
|
|
|
|
xfont->u.descent = xfs->descent;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
xfont->u.height = xfont->u.ascent + xfont->u.descent;
|
|
|
|
xfont->u.public_charset = pubcs;
|
2011-09-16 23:18:54 +04:00
|
|
|
xfont->u.want_fallback = TRUE;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
xfont->u.preferred_drawtype = DRAWTYPE_GDK;
|
|
|
|
#elif defined DRAW_TEXT_CAIRO
|
|
|
|
xfont->u.preferred_drawtype = DRAWTYPE_CAIRO;
|
|
|
|
#else
|
|
|
|
#error No drawtype available at all
|
|
|
|
#endif
|
2011-09-16 23:18:53 +04:00
|
|
|
xfont->real_charset = realcs;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
xfont->sixteen_bit = sixteen_bit;
|
2008-03-29 13:48:16 +03:00
|
|
|
xfont->variable = variable;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
xfont->wide = wide;
|
|
|
|
xfont->bold = bold;
|
|
|
|
xfont->shadowoffset = shadowoffset;
|
|
|
|
xfont->shadowalways = shadowalways;
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
for (i = 0; i < lenof(xfont->fonts); i++) {
|
|
|
|
xfont->fonts[i].xfs = NULL;
|
|
|
|
xfont->fonts[i].allocated = FALSE;
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
xfont->fonts[i].glyphcache = NULL;
|
|
|
|
xfont->fonts[i].nglyphs = 0;
|
|
|
|
xfont->fonts[i].pixmap = None;
|
|
|
|
xfont->fonts[i].gc = None;
|
|
|
|
#endif
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfont->fonts[0].xfs = xfs;
|
|
|
|
xfont->fonts[0].allocated = TRUE;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
return (unifont *)xfont;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void x11font_destroy(unifont *font)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
struct x11font *xfont = (struct x11font *)font;
|
|
|
|
int i;
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
for (i = 0; i < lenof(xfont->fonts); i++) {
|
|
|
|
if (xfont->fonts[i].xfs)
|
|
|
|
XFreeFont(disp, xfont->fonts[i].xfs);
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
if (xfont->fonts[i].gc != None)
|
|
|
|
XFreeGC(disp, xfont->fonts[i].gc);
|
|
|
|
if (xfont->fonts[i].pixmap != None)
|
|
|
|
XFreePixmap(disp, xfont->fonts[i].pixmap);
|
|
|
|
if (xfont->fonts[i].glyphcache) {
|
|
|
|
int j;
|
|
|
|
for (j = 0; j < xfont->fonts[i].nglyphs; j++) {
|
|
|
|
cairo_surface_destroy(xfont->fonts[i].glyphcache[j].surface);
|
|
|
|
sfree(xfont->fonts[i].glyphcache[j].bitmap);
|
|
|
|
}
|
|
|
|
sfree(xfont->fonts[i].glyphcache);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
sfree(font);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void x11_alloc_subfont(struct x11font *xfont, int sfid)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
char *derived_name = x11_guess_derived_font_name
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
(xfont->fonts[0].xfs, sfid & 1, !!(sfid & 2));
|
|
|
|
xfont->fonts[sfid].xfs = XLoadQueryFont(disp, derived_name);
|
|
|
|
xfont->fonts[sfid].allocated = TRUE;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
sfree(derived_name);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
/* Note that xfont->fonts[sfid].xfs may still be NULL, if XLQF failed. */
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static int x11font_has_glyph(unifont *font, wchar_t glyph)
|
|
|
|
{
|
|
|
|
struct x11font *xfont = (struct x11font *)font;
|
|
|
|
|
|
|
|
if (xfont->sixteen_bit) {
|
|
|
|
/*
|
|
|
|
* This X font has 16-bit character indices, which means
|
|
|
|
* we can directly use our Unicode input value.
|
|
|
|
*/
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
return x11_font_has_glyph(xfont->fonts[0].xfs,
|
|
|
|
glyph >> 8, glyph & 0xFF);
|
2011-09-16 23:18:54 +04:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* This X font has 8-bit indices, so we must convert to the
|
|
|
|
* appropriate character set.
|
|
|
|
*/
|
|
|
|
char sbstring[2];
|
|
|
|
int sblen = wc_to_mb(xfont->real_charset, 0, &glyph, 1,
|
|
|
|
sbstring, 2, "", NULL, NULL);
|
2012-04-22 18:22:08 +04:00
|
|
|
if (sblen == 0 || !sbstring[0])
|
2011-09-16 23:18:54 +04:00
|
|
|
return FALSE; /* not even in the charset */
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
return x11_font_has_glyph(xfont->fonts[0].xfs, 0,
|
2011-09-17 12:11:11 +04:00
|
|
|
(unsigned char)sbstring[0]);
|
2011-09-16 23:18:54 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
#if !GTK_CHECK_VERSION(2,0,0)
|
|
|
|
#define GDK_DRAWABLE_XID(d) GDK_WINDOW_XWINDOW(d) /* GTK1's name for this */
|
2015-08-16 16:16:23 +03:00
|
|
|
#elif GTK_CHECK_VERSION(3,0,0)
|
|
|
|
#define GDK_DRAWABLE_XID(d) GDK_WINDOW_XID(d) /* GTK3's name for this */
|
2011-09-16 12:49:08 +04:00
|
|
|
#endif
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static int x11font_width_16(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
const void *vstring, int start, int length)
|
2008-03-29 13:48:16 +03:00
|
|
|
{
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const XChar2b *string = (const XChar2b *)vstring;
|
|
|
|
return XTextWidth16(xfi->xfs, string+start, length);
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static int x11font_width_8(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
|
|
|
const char *string = (const char *)vstring;
|
|
|
|
return XTextWidth(xfi->xfs, string+start, length);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
static void x11font_gdk_setup(unifont_drawctx *ctx, x11font_individual *xfi)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
|
|
|
XSetFont(disp, GDK_GC_XGC(ctx->u.gdk.gc), xfi->xfs->fid);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void x11font_gdk_draw_16(unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, int x, int y,
|
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const XChar2b *string = (const XChar2b *)vstring;
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawString16(disp, GDK_DRAWABLE_XID(ctx->u.gdk.target),
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GDK_GC_XGC(ctx->u.gdk.gc), x, y, string+start, length);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void x11font_gdk_draw_8(unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, int x, int y,
|
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const char *string = (const char *)vstring;
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawString(disp, GDK_DRAWABLE_XID(ctx->u.gdk.target),
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GDK_GC_XGC(ctx->u.gdk.gc), x, y, string+start, length);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
static void x11font_cairo_setup(unifont_drawctx *ctx, x11font_individual *xfi)
|
|
|
|
{
|
|
|
|
if (xfi->pixmap == None) {
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
XGCValues gcvals;
|
|
|
|
GdkWindow *widgetwin = gtk_widget_get_window(ctx->u.cairo.widget);
|
|
|
|
int widgetscr = GDK_SCREEN_XNUMBER(gdk_window_get_screen(widgetwin));
|
|
|
|
|
|
|
|
xfi->pixwidth =
|
|
|
|
xfi->xfs->max_bounds.rbearing - xfi->xfs->min_bounds.lbearing;
|
|
|
|
xfi->pixheight =
|
|
|
|
xfi->xfs->max_bounds.ascent + xfi->xfs->max_bounds.descent;
|
|
|
|
xfi->pixoriginx = -xfi->xfs->min_bounds.lbearing;
|
|
|
|
xfi->pixoriginy = xfi->xfs->max_bounds.ascent;
|
|
|
|
|
|
|
|
xfi->rowsize = cairo_format_stride_for_width(CAIRO_FORMAT_A1,
|
|
|
|
xfi->pixwidth);
|
|
|
|
xfi->allsize = xfi->rowsize * xfi->pixheight;
|
|
|
|
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Test host endianness and use it to set xfi->indexflip,
|
|
|
|
* which is XORed into our left-shift counts in order to
|
|
|
|
* implement the CAIRO_FORMAT_A1 specification, in which
|
|
|
|
* each bitmap byte is oriented LSB-first on little-endian
|
|
|
|
* platforms and MSB-first on big-endian ones.
|
|
|
|
*
|
|
|
|
* This is the same technique Cairo itself uses to test
|
|
|
|
* endianness, so hopefully it'll work in any situation
|
|
|
|
* where Cairo is usable at all.
|
|
|
|
*/
|
|
|
|
static const int endianness_test = 1;
|
|
|
|
xfi->indexflip = (*((char *) &endianness_test) == 1) ? 0 : 7;
|
|
|
|
}
|
|
|
|
|
|
|
|
xfi->pixmap = XCreatePixmap
|
2015-08-16 11:23:32 +03:00
|
|
|
(disp,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GDK_DRAWABLE_XID(gtk_widget_get_window(ctx->u.cairo.widget)),
|
|
|
|
xfi->pixwidth, xfi->pixheight, 1);
|
2015-08-16 11:23:32 +03:00
|
|
|
gcvals.foreground = WhitePixel(disp, widgetscr);
|
|
|
|
gcvals.background = BlackPixel(disp, widgetscr);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
gcvals.font = xfi->xfs->fid;
|
2015-08-16 11:23:32 +03:00
|
|
|
xfi->gc = XCreateGC(disp, xfi->pixmap,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
GCForeground | GCBackground | GCFont, &gcvals);
|
2008-03-29 13:48:16 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_cairo_cache_glyph(x11font_individual *xfi, int glyphindex)
|
|
|
|
{
|
|
|
|
XImage *image;
|
|
|
|
int x, y;
|
|
|
|
unsigned char *bitmap;
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
|
|
|
|
bitmap = snewn(xfi->allsize, unsigned char);
|
|
|
|
memset(bitmap, 0, xfi->allsize);
|
|
|
|
|
2015-08-16 11:23:32 +03:00
|
|
|
image = XGetImage(disp, xfi->pixmap, 0, 0,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->pixwidth, xfi->pixheight, AllPlanes, XYPixmap);
|
|
|
|
for (y = 0; y < xfi->pixheight; y++) {
|
|
|
|
for (x = 0; x < xfi->pixwidth; x++) {
|
|
|
|
unsigned long pixel = XGetPixel(image, x, y);
|
|
|
|
if (pixel) {
|
|
|
|
int byteindex = y * xfi->rowsize + x/8;
|
|
|
|
int bitindex = (x & 7) ^ xfi->indexflip;
|
|
|
|
bitmap[byteindex] |= 1U << bitindex;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
XDestroyImage(image);
|
|
|
|
|
|
|
|
if (xfi->nglyphs <= glyphindex) {
|
|
|
|
/* Round up to the next multiple of 256 on the general
|
|
|
|
* principle that Unicode characters come in contiguous blocks
|
|
|
|
* often used together */
|
|
|
|
int old_nglyphs = xfi->nglyphs;
|
2015-08-23 16:10:59 +03:00
|
|
|
xfi->nglyphs = (glyphindex + 0x100) & ~0xFF;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->glyphcache = sresize(xfi->glyphcache, xfi->nglyphs,
|
|
|
|
struct cairo_cached_glyph);
|
|
|
|
|
|
|
|
while (old_nglyphs < xfi->nglyphs) {
|
|
|
|
xfi->glyphcache[old_nglyphs].surface = NULL;
|
|
|
|
xfi->glyphcache[old_nglyphs].bitmap = NULL;
|
|
|
|
old_nglyphs++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
xfi->glyphcache[glyphindex].bitmap = bitmap;
|
|
|
|
xfi->glyphcache[glyphindex].surface = cairo_image_surface_create_for_data
|
|
|
|
(bitmap, CAIRO_FORMAT_A1, xfi->pixwidth, xfi->pixheight, xfi->rowsize);
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_cairo_draw_glyph(unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, int x, int y,
|
|
|
|
int glyphindex)
|
|
|
|
{
|
|
|
|
if (xfi->glyphcache[glyphindex].surface) {
|
|
|
|
cairo_mask_surface(ctx->u.cairo.cr,
|
|
|
|
xfi->glyphcache[glyphindex].surface,
|
|
|
|
x - xfi->pixoriginx, y - xfi->pixoriginy);
|
|
|
|
}
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_cairo_draw_16(unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, int x, int y,
|
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const XChar2b *string = (const XChar2b *)vstring + start;
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < length; i++) {
|
|
|
|
if (x11_font_has_glyph(xfi->xfs, string[i].byte1, string[i].byte2)) {
|
|
|
|
int glyphindex = (256 * (unsigned char)string[i].byte1 +
|
|
|
|
(unsigned char)string[i].byte2);
|
|
|
|
if (glyphindex >= xfi->nglyphs ||
|
|
|
|
!xfi->glyphcache[glyphindex].surface) {
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawImageString16(disp, xfi->pixmap, xfi->gc,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->pixoriginx, xfi->pixoriginy,
|
|
|
|
string+i, 1);
|
|
|
|
x11font_cairo_cache_glyph(xfi, glyphindex);
|
|
|
|
}
|
|
|
|
x11font_cairo_draw_glyph(ctx, xfi, x, y, glyphindex);
|
|
|
|
x += XTextWidth16(xfi->xfs, string+i, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void x11font_cairo_draw_8(unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, int x, int y,
|
|
|
|
const void *vstring, int start, int length)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
const char *string = (const char *)vstring + start;
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < length; i++) {
|
|
|
|
if (x11_font_has_glyph(xfi->xfs, 0, string[i])) {
|
|
|
|
int glyphindex = (unsigned char)string[i];
|
|
|
|
if (glyphindex >= xfi->nglyphs ||
|
|
|
|
!xfi->glyphcache[glyphindex].surface) {
|
2015-08-16 11:23:32 +03:00
|
|
|
XDrawImageString(disp, xfi->pixmap, xfi->gc,
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
xfi->pixoriginx, xfi->pixoriginy,
|
|
|
|
string+i, 1);
|
|
|
|
x11font_cairo_cache_glyph(xfi, glyphindex);
|
|
|
|
}
|
|
|
|
x11font_cairo_draw_glyph(ctx, xfi, x, y, glyphindex);
|
|
|
|
x += XTextWidth(xfi->xfs, string+i, 1);
|
|
|
|
}
|
2008-03-29 13:48:16 +03:00
|
|
|
}
|
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif /* DRAW_TEXT_CAIRO */
|
|
|
|
|
|
|
|
struct x11font_drawfuncs {
|
|
|
|
int (*width)(unifont_drawctx *ctx, x11font_individual *xfi,
|
|
|
|
const void *vstring, int start, int length);
|
|
|
|
void (*setup)(unifont_drawctx *ctx, x11font_individual *xfi);
|
|
|
|
void (*draw)(unifont_drawctx *ctx, x11font_individual *xfi, int x, int y,
|
|
|
|
const void *vstring, int start, int length);
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This array has two entries per compiled-in drawtype; of each pair,
|
|
|
|
* the first is for an 8-bit font and the second for 16-bit.
|
|
|
|
*/
|
|
|
|
static const struct x11font_drawfuncs x11font_drawfuncs[2*DRAWTYPE_NTYPES] = {
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
/* gdk, 8-bit */
|
|
|
|
{
|
|
|
|
x11font_width_8,
|
|
|
|
x11font_gdk_setup,
|
|
|
|
x11font_gdk_draw_8,
|
|
|
|
},
|
|
|
|
/* gdk, 16-bit */
|
|
|
|
{
|
|
|
|
x11font_width_16,
|
|
|
|
x11font_gdk_setup,
|
|
|
|
x11font_gdk_draw_16,
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
/* cairo, 8-bit */
|
|
|
|
{
|
|
|
|
x11font_width_8,
|
|
|
|
x11font_cairo_setup,
|
|
|
|
x11font_cairo_draw_8,
|
|
|
|
},
|
|
|
|
/* [3] cairo, 16-bit */
|
|
|
|
{
|
|
|
|
x11font_width_16,
|
|
|
|
x11font_cairo_setup,
|
|
|
|
x11font_cairo_draw_16,
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
};
|
2008-03-29 13:48:16 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_really_draw_text(const struct x11font_drawfuncs *dfns,
|
|
|
|
unifont_drawctx *ctx,
|
|
|
|
x11font_individual *xfi, int x, int y,
|
|
|
|
const void *string, int nchars,
|
2011-09-16 12:49:08 +04:00
|
|
|
int shadowoffset,
|
|
|
|
int fontvariable, int cellwidth)
|
|
|
|
{
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
int start = 0, step, nsteps, centre;
|
2011-09-16 12:49:08 +04:00
|
|
|
|
|
|
|
if (fontvariable) {
|
|
|
|
/*
|
|
|
|
* In a variable-pitch font, we draw one character at a
|
|
|
|
* time, and centre it in the character cell.
|
|
|
|
*/
|
|
|
|
step = 1;
|
|
|
|
nsteps = nchars;
|
|
|
|
centre = TRUE;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* In a fixed-pitch font, we can draw the whole lot in one go.
|
|
|
|
*/
|
|
|
|
step = nchars;
|
|
|
|
nsteps = 1;
|
|
|
|
centre = FALSE;
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
dfns->setup(ctx, xfi);
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
while (nsteps-- > 0) {
|
|
|
|
int X = x;
|
|
|
|
if (centre)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
X += (cellwidth - dfns->width(ctx, xfi, string, start, step)) / 2;
|
2011-09-16 12:49:08 +04:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
dfns->draw(ctx, xfi, X, y, string, start, step);
|
2011-09-16 12:49:08 +04:00
|
|
|
if (shadowoffset)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
dfns->draw(ctx, xfi, X + shadowoffset, y, string, start, step);
|
2011-09-16 12:49:08 +04:00
|
|
|
|
|
|
|
x += cellwidth;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
start += step;
|
2011-09-16 12:49:08 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void x11font_draw_text(unifont_drawctx *ctx, unifont *font,
|
2011-09-16 23:18:53 +04:00
|
|
|
int x, int y, const wchar_t *string, int len,
|
2008-03-22 21:11:17 +03:00
|
|
|
int wide, int bold, int cellwidth)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
|
|
|
struct x11font *xfont = (struct x11font *)font;
|
|
|
|
int sfid;
|
2011-09-16 12:49:08 +04:00
|
|
|
int shadowoffset = 0;
|
2008-03-29 13:48:16 +03:00
|
|
|
int mult = (wide ? 2 : 1);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
int index = 2 * (int)ctx->type;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
|
|
|
wide -= xfont->wide;
|
|
|
|
bold -= xfont->bold;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Decide which subfont we're using, and whether we have to
|
|
|
|
* use shadow bold.
|
|
|
|
*/
|
|
|
|
if (xfont->shadowalways && bold) {
|
2011-09-16 12:49:08 +04:00
|
|
|
shadowoffset = xfont->shadowoffset;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
bold = 0;
|
|
|
|
}
|
|
|
|
sfid = 2 * wide + bold;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
if (!xfont->fonts[sfid].allocated)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
x11_alloc_subfont(xfont, sfid);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
if (bold && !xfont->fonts[sfid].xfs) {
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
bold = 0;
|
2011-09-16 12:49:08 +04:00
|
|
|
shadowoffset = xfont->shadowoffset;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
sfid = 2 * wide + bold;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
if (!xfont->fonts[sfid].allocated)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
x11_alloc_subfont(xfont, sfid);
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
if (!xfont->fonts[sfid].xfs)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
return; /* we've tried our best, but no luck */
|
|
|
|
|
|
|
|
if (xfont->sixteen_bit) {
|
|
|
|
/*
|
|
|
|
* This X font has 16-bit character indices, which means
|
2011-09-16 23:18:53 +04:00
|
|
|
* we can directly use our Unicode input string.
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
XChar2b *xcs;
|
2011-09-16 23:18:53 +04:00
|
|
|
int i;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
|
2011-09-16 23:18:53 +04:00
|
|
|
xcs = snewn(len, XChar2b);
|
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
xcs[i].byte1 = string[i] >> 8;
|
|
|
|
xcs[i].byte2 = string[i];
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
x11font_really_draw_text(x11font_drawfuncs + index + 1, ctx,
|
|
|
|
&xfont->fonts[sfid], x, y,
|
|
|
|
xcs, len, shadowoffset,
|
|
|
|
xfont->variable, cellwidth * mult);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
sfree(xcs);
|
|
|
|
} else {
|
2011-09-16 23:18:53 +04:00
|
|
|
/*
|
|
|
|
* This X font has 8-bit indices, so we must convert to the
|
|
|
|
* appropriate character set.
|
|
|
|
*/
|
|
|
|
char *sbstring = snewn(len+1, char);
|
|
|
|
int sblen = wc_to_mb(xfont->real_charset, 0, string, len,
|
|
|
|
sbstring, len+1, ".", NULL, NULL);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
x11font_really_draw_text(x11font_drawfuncs + index + 0, ctx,
|
|
|
|
&xfont->fonts[sfid], x, y,
|
2011-09-16 23:18:53 +04:00
|
|
|
sbstring, sblen, shadowoffset,
|
2008-03-29 13:48:16 +03:00
|
|
|
xfont->variable, cellwidth * mult);
|
2011-09-16 23:18:53 +04:00
|
|
|
sfree(sbstring);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void x11font_enum_fonts(GtkWidget *widget,
|
|
|
|
fontsel_add_entry callback, void *callback_ctx)
|
|
|
|
{
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
2008-03-26 00:49:14 +03:00
|
|
|
char **fontnames;
|
|
|
|
char *tmp = NULL;
|
|
|
|
int nnames, i, max, tmpsize;
|
|
|
|
|
|
|
|
max = 32768;
|
|
|
|
while (1) {
|
2015-08-16 11:23:32 +03:00
|
|
|
fontnames = XListFonts(disp, "*", max, &nnames);
|
2008-03-26 00:49:14 +03:00
|
|
|
if (nnames >= max) {
|
|
|
|
XFreeFontNames(fontnames);
|
|
|
|
max *= 2;
|
|
|
|
} else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
tmpsize = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < nnames; i++) {
|
|
|
|
if (fontnames[i][0] == '-') {
|
|
|
|
/*
|
|
|
|
* Dismember an XLFD and convert it into the format
|
|
|
|
* we'll be using in the font selector.
|
|
|
|
*/
|
|
|
|
char *components[14];
|
2008-03-27 00:33:10 +03:00
|
|
|
char *p, *font, *style, *stylekey, *charset;
|
|
|
|
int j, weightkey, slantkey, setwidthkey;
|
|
|
|
int thistmpsize, fontsize, flags;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2008-03-27 00:33:10 +03:00
|
|
|
thistmpsize = 4 * strlen(fontnames[i]) + 256;
|
2008-03-26 00:49:14 +03:00
|
|
|
if (tmpsize < thistmpsize) {
|
|
|
|
tmpsize = thistmpsize;
|
|
|
|
tmp = sresize(tmp, tmpsize, char);
|
|
|
|
}
|
|
|
|
strcpy(tmp, fontnames[i]);
|
|
|
|
|
|
|
|
p = tmp;
|
|
|
|
for (j = 0; j < 14; j++) {
|
|
|
|
if (*p)
|
|
|
|
*p++ = '\0';
|
|
|
|
components[j] = p;
|
|
|
|
while (*p && *p != '-')
|
|
|
|
p++;
|
|
|
|
}
|
|
|
|
*p++ = '\0';
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Font name is made up of fields 0 and 1, in reverse
|
|
|
|
* order with parentheses. (This is what the GTK 1.2 X
|
|
|
|
* font selector does, and it seems to come out
|
|
|
|
* looking reasonably sensible.)
|
|
|
|
*/
|
|
|
|
font = p;
|
|
|
|
p += 1 + sprintf(p, "%s (%s)", components[1], components[0]);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Charset is made up of fields 12 and 13.
|
|
|
|
*/
|
|
|
|
charset = p;
|
|
|
|
p += 1 + sprintf(p, "%s-%s", components[12], components[13]);
|
|
|
|
|
|
|
|
/*
|
2008-03-27 00:33:10 +03:00
|
|
|
* Style is a mixture of quite a lot of the fields,
|
|
|
|
* with some strange formatting.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
|
|
|
style = p;
|
|
|
|
p += sprintf(p, "%s", components[2][0] ? components[2] :
|
|
|
|
"regular");
|
2012-01-03 23:43:19 +04:00
|
|
|
if (!g_ascii_strcasecmp(components[3], "i"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " italic");
|
2012-01-03 23:43:19 +04:00
|
|
|
else if (!g_ascii_strcasecmp(components[3], "o"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " oblique");
|
2012-01-03 23:43:19 +04:00
|
|
|
else if (!g_ascii_strcasecmp(components[3], "ri"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " reverse italic");
|
2012-01-03 23:43:19 +04:00
|
|
|
else if (!g_ascii_strcasecmp(components[3], "ro"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " reverse oblique");
|
2012-01-03 23:43:19 +04:00
|
|
|
else if (!g_ascii_strcasecmp(components[3], "ot"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " other-slant");
|
2012-01-03 23:43:19 +04:00
|
|
|
if (components[4][0] && g_ascii_strcasecmp(components[4], "normal"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " %s", components[4]);
|
2012-01-03 23:43:19 +04:00
|
|
|
if (!g_ascii_strcasecmp(components[10], "m"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " [M]");
|
2012-01-03 23:43:19 +04:00
|
|
|
if (!g_ascii_strcasecmp(components[10], "c"))
|
2008-03-26 00:49:14 +03:00
|
|
|
p += sprintf(p, " [C]");
|
2008-03-27 00:33:10 +03:00
|
|
|
if (components[5][0])
|
|
|
|
p += sprintf(p, " %s", components[5]);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Style key is the same stuff as above, but with a
|
|
|
|
* couple of transformations done on it to make it
|
|
|
|
* sort more sensibly.
|
|
|
|
*/
|
|
|
|
p++;
|
|
|
|
stylekey = p;
|
2012-01-03 23:43:19 +04:00
|
|
|
if (!g_ascii_strcasecmp(components[2], "medium") ||
|
|
|
|
!g_ascii_strcasecmp(components[2], "regular") ||
|
|
|
|
!g_ascii_strcasecmp(components[2], "normal") ||
|
|
|
|
!g_ascii_strcasecmp(components[2], "book"))
|
2008-03-27 00:33:10 +03:00
|
|
|
weightkey = 0;
|
2012-01-03 23:43:19 +04:00
|
|
|
else if (!g_ascii_strncasecmp(components[2], "demi", 4) ||
|
|
|
|
!g_ascii_strncasecmp(components[2], "semi", 4))
|
2008-03-27 00:33:10 +03:00
|
|
|
weightkey = 1;
|
|
|
|
else
|
|
|
|
weightkey = 2;
|
2012-01-03 23:43:19 +04:00
|
|
|
if (!g_ascii_strcasecmp(components[3], "r"))
|
2008-03-27 00:33:10 +03:00
|
|
|
slantkey = 0;
|
2012-01-03 23:43:19 +04:00
|
|
|
else if (!g_ascii_strncasecmp(components[3], "r", 1))
|
2008-03-27 00:33:10 +03:00
|
|
|
slantkey = 2;
|
|
|
|
else
|
|
|
|
slantkey = 1;
|
2012-01-03 23:43:19 +04:00
|
|
|
if (!g_ascii_strcasecmp(components[4], "normal"))
|
2008-03-27 00:33:10 +03:00
|
|
|
setwidthkey = 0;
|
|
|
|
else
|
|
|
|
setwidthkey = 1;
|
|
|
|
|
|
|
|
p += sprintf(p, "%04d%04d%s%04d%04d%s%04d%04d%s%04d%s%04d%s",
|
|
|
|
weightkey,
|
2008-03-31 14:47:48 +04:00
|
|
|
(int)strlen(components[2]), components[2],
|
2008-03-27 00:33:10 +03:00
|
|
|
slantkey,
|
2008-03-31 14:47:48 +04:00
|
|
|
(int)strlen(components[3]), components[3],
|
2008-03-27 00:33:10 +03:00
|
|
|
setwidthkey,
|
2008-03-31 14:47:48 +04:00
|
|
|
(int)strlen(components[4]), components[4],
|
|
|
|
(int)strlen(components[10]), components[10],
|
|
|
|
(int)strlen(components[5]), components[5]);
|
2008-03-27 00:33:10 +03:00
|
|
|
|
|
|
|
assert(p - tmp < thistmpsize);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Size is in pixels, for our application, so we
|
|
|
|
* derive it directly from the pixel size field,
|
|
|
|
* number 6.
|
|
|
|
*/
|
|
|
|
fontsize = atoi(components[6]);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flags: we need to know whether this is a monospaced
|
|
|
|
* font, which we do by examining the spacing field
|
|
|
|
* again.
|
|
|
|
*/
|
|
|
|
flags = FONTFLAG_SERVERSIDE;
|
|
|
|
if (!strchr("CcMm", components[10][0]))
|
|
|
|
flags |= FONTFLAG_NONMONOSPACED;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Not sure why, but sometimes the X server will
|
|
|
|
* deliver dummy font types in which fontsize comes
|
|
|
|
* out as zero. Filter those out.
|
|
|
|
*/
|
|
|
|
if (fontsize)
|
|
|
|
callback(callback_ctx, fontnames[i], font, charset,
|
2008-03-27 00:33:10 +03:00
|
|
|
style, stylekey, fontsize, flags, &x11font_vtable);
|
2008-03-26 00:49:14 +03:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* This isn't an XLFD, so it must be an alias.
|
|
|
|
* Transmit it with mostly null data.
|
|
|
|
*
|
|
|
|
* It would be nice to work out if it's monospaced
|
|
|
|
* here, but at the moment I can't see that being
|
|
|
|
* anything but computationally hideous. Ah well.
|
|
|
|
*/
|
|
|
|
callback(callback_ctx, fontnames[i], fontnames[i], NULL,
|
2008-03-26 23:20:25 +03:00
|
|
|
NULL, NULL, 0, FONTFLAG_SERVERALIAS, &x11font_vtable);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
XFreeFontNames(fontnames);
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *x11font_canonify_fontname(GtkWidget *widget, const char *name,
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int *size, int *flags,
|
|
|
|
int resolve_aliases)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* When given an X11 font name to try to make sense of for a
|
|
|
|
* font selector, we must attempt to load it (to see if it
|
|
|
|
* exists), and then canonify it by extracting its FONT
|
|
|
|
* property, which should give its full XLFD even if what we
|
2008-03-27 22:41:08 +03:00
|
|
|
* originally had was a wildcard.
|
|
|
|
*
|
|
|
|
* However, we must carefully avoid canonifying font
|
|
|
|
* _aliases_, unless specifically asked to, because the font
|
|
|
|
* selector treats them as worthwhile in their own right.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
|
|
|
XFontStruct *xfs;
|
2015-08-16 11:23:32 +03:00
|
|
|
Display *disp = GDK_DISPLAY_XDISPLAY(gdk_display_get_default());
|
2008-03-26 00:49:14 +03:00
|
|
|
Atom fontprop, fontprop2;
|
|
|
|
unsigned long ret;
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
xfs = XLoadQueryFont(disp, name);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
if (!xfs)
|
|
|
|
return NULL; /* didn't make sense to us, sorry */
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
fontprop = XInternAtom(disp, "FONT", False);
|
|
|
|
|
|
|
|
if (XGetFontProperty(xfs, fontprop, &ret)) {
|
2008-03-27 22:41:08 +03:00
|
|
|
char *newname = XGetAtomName(disp, (Atom)ret);
|
|
|
|
if (newname) {
|
2008-03-26 00:49:14 +03:00
|
|
|
unsigned long fsize = 12;
|
|
|
|
|
|
|
|
fontprop2 = XInternAtom(disp, "PIXEL_SIZE", False);
|
2008-03-27 22:41:08 +03:00
|
|
|
if (XGetFontProperty(xfs, fontprop2, &fsize) && fsize > 0) {
|
2008-03-26 00:49:14 +03:00
|
|
|
*size = fsize;
|
2011-09-16 12:49:08 +04:00
|
|
|
XFreeFont(disp, xfs);
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
if (flags) {
|
|
|
|
if (name[0] == '-' || resolve_aliases)
|
|
|
|
*flags = FONTFLAG_SERVERSIDE;
|
|
|
|
else
|
|
|
|
*flags = FONTFLAG_SERVERALIAS;
|
|
|
|
}
|
2008-03-27 22:41:08 +03:00
|
|
|
return dupstr(name[0] == '-' || resolve_aliases ?
|
|
|
|
newname : name);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-16 12:49:08 +04:00
|
|
|
XFreeFont(disp, xfs);
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
return NULL; /* something went wrong */
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *x11font_scale_fontname(GtkWidget *widget, const char *name,
|
|
|
|
int size)
|
|
|
|
{
|
|
|
|
return NULL; /* shan't */
|
|
|
|
}
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif /* NOT_X_WINDOWS */
|
|
|
|
|
2008-04-04 14:56:26 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,0,0)
|
|
|
|
|
2008-03-22 21:11:17 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
2008-04-04 14:56:26 +04:00
|
|
|
* Pango font implementation (for GTK 2 only).
|
2008-03-22 21:11:17 +03:00
|
|
|
*/
|
|
|
|
|
2008-05-31 23:23:45 +04:00
|
|
|
#if defined PANGO_PRE_1POINT4 && !defined PANGO_PRE_1POINT6
|
|
|
|
#define PANGO_PRE_1POINT6 /* make life easier for pre-1.4 folk */
|
|
|
|
#endif
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static int pangofont_has_glyph(unifont *font, wchar_t glyph);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void pangofont_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
|
|
|
int wide, int bold, int cellwidth);
|
2008-03-26 00:49:14 +03:00
|
|
|
static unifont *pangofont_create(GtkWidget *widget, const char *name,
|
2008-03-22 21:11:17 +03:00
|
|
|
int wide, int bold,
|
|
|
|
int shadowoffset, int shadowalways);
|
2011-09-16 23:18:54 +04:00
|
|
|
static unifont *pangofont_create_fallback(GtkWidget *widget, int height,
|
|
|
|
int wide, int bold,
|
|
|
|
int shadowoffset, int shadowalways);
|
2008-03-22 21:11:17 +03:00
|
|
|
static void pangofont_destroy(unifont *font);
|
2008-03-26 00:49:14 +03:00
|
|
|
static void pangofont_enum_fonts(GtkWidget *widget, fontsel_add_entry callback,
|
|
|
|
void *callback_ctx);
|
|
|
|
static char *pangofont_canonify_fontname(GtkWidget *widget, const char *name,
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int *size, int *flags,
|
|
|
|
int resolve_aliases);
|
2008-03-26 00:49:14 +03:00
|
|
|
static char *pangofont_scale_fontname(GtkWidget *widget, const char *name,
|
|
|
|
int size);
|
2008-03-22 21:11:17 +03:00
|
|
|
|
|
|
|
struct pangofont {
|
|
|
|
struct unifont u;
|
|
|
|
/*
|
|
|
|
* Pango objects.
|
|
|
|
*/
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
PangoFontset *fset;
|
|
|
|
/*
|
|
|
|
* The containing widget.
|
|
|
|
*/
|
|
|
|
GtkWidget *widget;
|
|
|
|
/*
|
|
|
|
* Data passed in to unifont_create().
|
|
|
|
*/
|
|
|
|
int bold, shadowoffset, shadowalways;
|
2015-08-23 16:13:30 +03:00
|
|
|
/*
|
|
|
|
* Cache of character widths, indexed by Unicode code point. In
|
|
|
|
* pixels; -1 means we haven't asked Pango about this character
|
|
|
|
* before.
|
|
|
|
*/
|
|
|
|
int *widthcache;
|
|
|
|
unsigned nwidthcache;
|
2008-03-22 21:11:17 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct unifont_vtable pangofont_vtable = {
|
|
|
|
pangofont_create,
|
2011-09-16 23:18:54 +04:00
|
|
|
pangofont_create_fallback,
|
2008-03-22 21:11:17 +03:00
|
|
|
pangofont_destroy,
|
2011-09-16 23:18:54 +04:00
|
|
|
pangofont_has_glyph,
|
2008-03-22 21:11:17 +03:00
|
|
|
pangofont_draw_text,
|
2008-03-26 00:49:14 +03:00
|
|
|
pangofont_enum_fonts,
|
|
|
|
pangofont_canonify_fontname,
|
|
|
|
pangofont_scale_fontname,
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
"client",
|
2008-03-22 21:11:17 +03:00
|
|
|
};
|
|
|
|
|
2008-03-29 18:44:32 +03:00
|
|
|
/*
|
|
|
|
* This function is used to rigorously validate a
|
|
|
|
* PangoFontDescription. Later versions of Pango have a nasty
|
|
|
|
* habit of accepting _any_ old string as input to
|
|
|
|
* pango_font_description_from_string and returning a font
|
|
|
|
* description which can actually be used to display text, even if
|
|
|
|
* they have to do it by falling back to their most default font.
|
|
|
|
* This is doubtless helpful in some situations, but not here,
|
|
|
|
* because we need to know if a Pango font string actually _makes
|
|
|
|
* sense_ in order to fall back to treating it as an X font name
|
|
|
|
* if it doesn't. So we check that the font family is actually one
|
|
|
|
* supported by Pango.
|
|
|
|
*/
|
|
|
|
static int pangofont_check_desc_makes_sense(PangoContext *ctx,
|
|
|
|
PangoFontDescription *desc)
|
|
|
|
{
|
|
|
|
#ifndef PANGO_PRE_1POINT6
|
|
|
|
PangoFontMap *map;
|
|
|
|
#endif
|
|
|
|
PangoFontFamily **families;
|
|
|
|
int i, nfamilies, matched;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ask Pango for a list of font families, and iterate through
|
|
|
|
* them to see if one of them matches the family in the
|
|
|
|
* PangoFontDescription.
|
|
|
|
*/
|
|
|
|
#ifndef PANGO_PRE_1POINT6
|
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map)
|
|
|
|
return FALSE;
|
|
|
|
pango_font_map_list_families(map, &families, &nfamilies);
|
|
|
|
#else
|
|
|
|
pango_context_list_families(ctx, &families, &nfamilies);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
matched = FALSE;
|
|
|
|
for (i = 0; i < nfamilies; i++) {
|
2012-01-03 23:43:19 +04:00
|
|
|
if (!g_ascii_strcasecmp(pango_font_family_get_name(families[i]),
|
|
|
|
pango_font_description_get_family(desc))) {
|
2008-03-29 18:44:32 +03:00
|
|
|
matched = TRUE;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
g_free(families);
|
|
|
|
|
|
|
|
return matched;
|
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static unifont *pangofont_create_internal(GtkWidget *widget,
|
|
|
|
PangoContext *ctx,
|
|
|
|
PangoFontDescription *desc,
|
|
|
|
int wide, int bold,
|
|
|
|
int shadowoffset, int shadowalways)
|
2008-03-22 21:11:17 +03:00
|
|
|
{
|
|
|
|
struct pangofont *pfont;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-22 21:11:17 +03:00
|
|
|
PangoFontMap *map;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2008-03-22 21:11:17 +03:00
|
|
|
PangoFontset *fset;
|
|
|
|
PangoFontMetrics *metrics;
|
|
|
|
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-22 21:11:17 +03:00
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
fset = pango_font_map_load_fontset(map, ctx, desc,
|
|
|
|
pango_context_get_language(ctx));
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
fset = pango_context_load_fontset(ctx, desc,
|
|
|
|
pango_context_get_language(ctx));
|
|
|
|
#endif
|
2008-03-22 21:11:17 +03:00
|
|
|
if (!fset) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
metrics = pango_fontset_get_metrics(fset);
|
|
|
|
if (!metrics ||
|
|
|
|
pango_font_metrics_get_approximate_digit_width(metrics) == 0) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
g_object_unref(fset);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
pfont = snew(struct pangofont);
|
|
|
|
pfont->u.vt = &pangofont_vtable;
|
|
|
|
pfont->u.width =
|
|
|
|
PANGO_PIXELS(pango_font_metrics_get_approximate_digit_width(metrics));
|
|
|
|
pfont->u.ascent = PANGO_PIXELS(pango_font_metrics_get_ascent(metrics));
|
|
|
|
pfont->u.descent = PANGO_PIXELS(pango_font_metrics_get_descent(metrics));
|
|
|
|
pfont->u.height = pfont->u.ascent + pfont->u.descent;
|
2011-09-16 23:18:54 +04:00
|
|
|
pfont->u.want_fallback = FALSE;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
pfont->u.preferred_drawtype = DRAWTYPE_CAIRO;
|
|
|
|
#elif defined DRAW_TEXT_GDK
|
|
|
|
pfont->u.preferred_drawtype = DRAWTYPE_GDK;
|
|
|
|
#else
|
|
|
|
#error No drawtype available at all
|
|
|
|
#endif
|
2008-03-22 21:11:17 +03:00
|
|
|
/* The Pango API is hardwired to UTF-8 */
|
|
|
|
pfont->u.public_charset = CS_UTF8;
|
|
|
|
pfont->desc = desc;
|
|
|
|
pfont->fset = fset;
|
|
|
|
pfont->widget = widget;
|
|
|
|
pfont->bold = bold;
|
|
|
|
pfont->shadowoffset = shadowoffset;
|
|
|
|
pfont->shadowalways = shadowalways;
|
2015-08-23 16:13:30 +03:00
|
|
|
pfont->widthcache = NULL;
|
|
|
|
pfont->nwidthcache = 0;
|
2008-03-22 21:11:17 +03:00
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_metrics_unref(metrics);
|
|
|
|
|
2008-03-22 21:11:17 +03:00
|
|
|
return (unifont *)pfont;
|
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static unifont *pangofont_create(GtkWidget *widget, const char *name,
|
|
|
|
int wide, int bold,
|
|
|
|
int shadowoffset, int shadowalways)
|
|
|
|
{
|
|
|
|
PangoContext *ctx;
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string(name);
|
|
|
|
if (!desc)
|
|
|
|
return NULL;
|
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (!pangofont_check_desc_makes_sense(ctx, desc)) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
return pangofont_create_internal(widget, ctx, desc, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unifont *pangofont_create_fallback(GtkWidget *widget, int height,
|
|
|
|
int wide, int bold,
|
|
|
|
int shadowoffset, int shadowalways)
|
|
|
|
{
|
|
|
|
PangoContext *ctx;
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string("Monospace");
|
|
|
|
if (!desc)
|
|
|
|
return NULL;
|
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
pango_font_description_set_absolute_size(desc, height * PANGO_SCALE);
|
|
|
|
return pangofont_create_internal(widget, ctx, desc, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
}
|
|
|
|
|
2008-03-22 21:11:17 +03:00
|
|
|
static void pangofont_destroy(unifont *font)
|
|
|
|
{
|
|
|
|
struct pangofont *pfont = (struct pangofont *)font;
|
|
|
|
pango_font_description_free(pfont->desc);
|
2015-08-23 16:13:30 +03:00
|
|
|
sfree(pfont->widthcache);
|
2008-03-22 21:11:17 +03:00
|
|
|
g_object_unref(pfont->fset);
|
|
|
|
sfree(font);
|
|
|
|
}
|
|
|
|
|
2015-08-23 16:13:30 +03:00
|
|
|
static int pangofont_char_width(PangoLayout *layout, struct pangofont *pfont,
|
|
|
|
wchar_t uchr, const char *utfchr, int utflen)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Here we check whether a character has the same width as the
|
|
|
|
* character cell it'll be drawn in. Because profiling showed that
|
|
|
|
* pango_layout_get_pixel_extents() was a huge bottleneck when we
|
|
|
|
* were calling it every time we needed to know this, we instead
|
|
|
|
* call it only on characters we don't already know about, and
|
|
|
|
* cache the results.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if ((unsigned)uchr >= pfont->nwidthcache) {
|
|
|
|
unsigned newsize = ((int)uchr + 0x100) & ~0xFF;
|
|
|
|
pfont->widthcache = sresize(pfont->widthcache, newsize, int);
|
|
|
|
while (pfont->nwidthcache < newsize)
|
|
|
|
pfont->widthcache[pfont->nwidthcache++] = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pfont->widthcache[uchr] < 0) {
|
|
|
|
PangoRectangle rect;
|
|
|
|
pango_layout_set_text(layout, utfchr, utflen);
|
|
|
|
pango_layout_get_pixel_extents(layout, NULL, &rect);
|
|
|
|
pfont->widthcache[uchr] = rect.width;
|
|
|
|
}
|
|
|
|
|
|
|
|
return pfont->widthcache[uchr];
|
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
static int pangofont_has_glyph(unifont *font, wchar_t glyph)
|
|
|
|
{
|
|
|
|
/* Pango implements font fallback, so assume it has everything */
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
static void pango_gdk_draw_layout(unifont_drawctx *ctx,
|
|
|
|
gint x, gint y, PangoLayout *layout)
|
|
|
|
{
|
|
|
|
gdk_draw_layout(ctx->u.gdk.target, ctx->u.gdk.gc, x, y, layout);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
static void pango_cairo_draw_layout(unifont_drawctx *ctx,
|
|
|
|
gint x, gint y, PangoLayout *layout)
|
|
|
|
{
|
|
|
|
cairo_move_to(ctx->u.cairo.cr, x, y);
|
|
|
|
pango_cairo_show_layout(ctx->u.cairo.cr, layout);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static void pangofont_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
|
|
|
int wide, int bold, int cellwidth)
|
2008-03-22 21:11:17 +03:00
|
|
|
{
|
|
|
|
struct pangofont *pfont = (struct pangofont *)font;
|
|
|
|
PangoLayout *layout;
|
|
|
|
PangoRectangle rect;
|
2011-09-16 23:18:53 +04:00
|
|
|
char *utfstring, *utfptr;
|
|
|
|
int utflen;
|
2008-03-22 21:11:17 +03:00
|
|
|
int shadowbold = FALSE;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
void (*draw_layout)(unifont_drawctx *ctx,
|
|
|
|
gint x, gint y, PangoLayout *layout) = NULL;
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
if (ctx->type == DRAWTYPE_GDK) {
|
|
|
|
draw_layout = pango_gdk_draw_layout;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
if (ctx->type == DRAWTYPE_CAIRO) {
|
|
|
|
draw_layout = pango_cairo_draw_layout;
|
|
|
|
}
|
|
|
|
#endif
|
2008-03-22 21:11:17 +03:00
|
|
|
|
|
|
|
if (wide)
|
|
|
|
cellwidth *= 2;
|
|
|
|
|
|
|
|
y -= pfont->u.ascent;
|
|
|
|
|
|
|
|
layout = pango_layout_new(gtk_widget_get_pango_context(pfont->widget));
|
|
|
|
pango_layout_set_font_description(layout, pfont->desc);
|
|
|
|
if (bold > pfont->bold) {
|
|
|
|
if (pfont->shadowalways)
|
|
|
|
shadowbold = TRUE;
|
|
|
|
else {
|
|
|
|
PangoFontDescription *desc2 =
|
|
|
|
pango_font_description_copy_static(pfont->desc);
|
|
|
|
pango_font_description_set_weight(desc2, PANGO_WEIGHT_BOLD);
|
|
|
|
pango_layout_set_font_description(layout, desc2);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:53 +04:00
|
|
|
/*
|
|
|
|
* Pango always expects UTF-8, so convert the input wide character
|
|
|
|
* string to UTF-8.
|
|
|
|
*/
|
|
|
|
utfstring = snewn(len*6+1, char); /* UTF-8 has max 6 bytes/char */
|
|
|
|
utflen = wc_to_mb(CS_UTF8, 0, string, len,
|
|
|
|
utfstring, len*6+1, ".", NULL, NULL);
|
|
|
|
|
|
|
|
utfptr = utfstring;
|
|
|
|
while (utflen > 0) {
|
2009-05-11 12:46:17 +04:00
|
|
|
int clen, n;
|
2008-03-22 21:11:17 +03:00
|
|
|
|
|
|
|
/*
|
2009-05-11 12:46:17 +04:00
|
|
|
* We want to display every character from this string in
|
|
|
|
* the centre of its own character cell. In the worst case,
|
|
|
|
* this requires a separate text-drawing call for each
|
|
|
|
* character; but in the common case where the font is
|
|
|
|
* properly fixed-width, we can draw many characters in one
|
|
|
|
* go which is much faster.
|
|
|
|
*
|
|
|
|
* This still isn't really ideal. If you look at what
|
|
|
|
* happens in the X protocol as a result of all of this, you
|
|
|
|
* find - naturally enough - that each call to
|
|
|
|
* gdk_draw_layout() generates a separate set of X RENDER
|
|
|
|
* operations involving creating a picture, setting a clip
|
|
|
|
* rectangle, doing some drawing and undoing the whole lot.
|
|
|
|
* In an ideal world, we should _always_ be able to turn the
|
|
|
|
* contents of this loop into a single RenderCompositeGlyphs
|
|
|
|
* operation which internally specifies inter-character
|
|
|
|
* deltas to get the spacing right, which would give us full
|
|
|
|
* speed _even_ in the worst case of a non-fixed-width font.
|
|
|
|
* However, Pango's architecture and documentation are so
|
|
|
|
* unhelpful that I have no idea how if at all to persuade
|
|
|
|
* them to do that.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Start by extracting a single UTF-8 character from the
|
|
|
|
* string.
|
2008-03-22 21:11:17 +03:00
|
|
|
*/
|
|
|
|
clen = 1;
|
2011-09-16 23:18:53 +04:00
|
|
|
while (clen < utflen &&
|
|
|
|
(unsigned char)utfptr[clen] >= 0x80 &&
|
|
|
|
(unsigned char)utfptr[clen] < 0xC0)
|
2008-03-22 21:11:17 +03:00
|
|
|
clen++;
|
2009-05-11 12:46:17 +04:00
|
|
|
n = 1;
|
2008-03-22 21:11:17 +03:00
|
|
|
|
2015-08-23 16:13:30 +03:00
|
|
|
if (is_rtl(string[0]) ||
|
|
|
|
pangofont_char_width(layout, pfont, string[n-1],
|
|
|
|
utfptr, clen) != cellwidth) {
|
2011-09-16 23:18:58 +04:00
|
|
|
/*
|
2015-08-23 16:13:30 +03:00
|
|
|
* If this character is a right-to-left one, or has an
|
|
|
|
* unusual width, then we must display it on its own.
|
2011-09-16 23:18:58 +04:00
|
|
|
*/
|
2015-08-23 16:13:30 +03:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Try to amalgamate a contiguous string of characters
|
|
|
|
* with the expected sensible width, for the common case
|
|
|
|
* in which we're using a monospaced font and everything
|
|
|
|
* works as expected.
|
|
|
|
*/
|
|
|
|
while (clen < utflen) {
|
|
|
|
int oldclen = clen;
|
|
|
|
clen++; /* skip UTF-8 introducer byte */
|
|
|
|
while (clen < utflen &&
|
|
|
|
(unsigned char)utfptr[clen] >= 0x80 &&
|
|
|
|
(unsigned char)utfptr[clen] < 0xC0)
|
|
|
|
clen++;
|
|
|
|
n++;
|
|
|
|
if (pangofont_char_width(layout, pfont,
|
|
|
|
string[n-1], utfptr + oldclen,
|
|
|
|
clen - oldclen) != cellwidth) {
|
|
|
|
clen = oldclen;
|
|
|
|
n--;
|
|
|
|
break;
|
2011-09-16 23:18:58 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-05-11 12:46:17 +04:00
|
|
|
|
2011-09-16 23:18:53 +04:00
|
|
|
pango_layout_set_text(layout, utfptr, clen);
|
2009-05-11 12:46:17 +04:00
|
|
|
pango_layout_get_pixel_extents(layout, NULL, &rect);
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
|
|
|
|
draw_layout(ctx,
|
|
|
|
x + (n*cellwidth - rect.width)/2,
|
|
|
|
y + (pfont->u.height - rect.height)/2, layout);
|
2008-03-22 21:11:17 +03:00
|
|
|
if (shadowbold)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
draw_layout(ctx,
|
|
|
|
x + (n*cellwidth - rect.width)/2 + pfont->shadowoffset,
|
|
|
|
y + (pfont->u.height - rect.height)/2, layout);
|
2008-03-22 21:11:17 +03:00
|
|
|
|
2011-09-16 23:18:53 +04:00
|
|
|
utflen -= clen;
|
|
|
|
utfptr += clen;
|
2011-09-16 23:18:58 +04:00
|
|
|
string += n;
|
2009-05-11 12:46:17 +04:00
|
|
|
x += n * cellwidth;
|
2008-03-22 21:11:17 +03:00
|
|
|
}
|
|
|
|
|
2011-09-16 23:18:53 +04:00
|
|
|
sfree(utfstring);
|
|
|
|
|
2008-03-22 21:11:17 +03:00
|
|
|
g_object_unref(layout);
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
|
|
|
* Dummy size value to be used when converting a
|
|
|
|
* PangoFontDescription of a scalable font to a string for
|
|
|
|
* internal use.
|
|
|
|
*/
|
|
|
|
#define PANGO_DUMMY_SIZE 12
|
|
|
|
|
|
|
|
static void pangofont_enum_fonts(GtkWidget *widget, fontsel_add_entry callback,
|
|
|
|
void *callback_ctx)
|
|
|
|
{
|
|
|
|
PangoContext *ctx;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontMap *map;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontFamily **families;
|
|
|
|
int i, nfamilies;
|
|
|
|
|
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2008-03-26 21:30:20 +03:00
|
|
|
* Ask Pango for a list of font families, and iterate through
|
|
|
|
* them.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map)
|
|
|
|
return;
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_map_list_families(map, &families, &nfamilies);
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
pango_context_list_families(ctx, &families, &nfamilies);
|
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
for (i = 0; i < nfamilies; i++) {
|
|
|
|
PangoFontFamily *family = families[i];
|
|
|
|
const char *familyname;
|
|
|
|
int flags;
|
|
|
|
PangoFontFace **faces;
|
|
|
|
int j, nfaces;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set up our flags for this font family, and get the name
|
|
|
|
* string.
|
|
|
|
*/
|
|
|
|
flags = FONTFLAG_CLIENTSIDE;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT4
|
|
|
|
/*
|
|
|
|
* In very early versions of Pango, we can't tell
|
|
|
|
* monospaced fonts from non-monospaced.
|
|
|
|
*/
|
2008-03-26 00:49:14 +03:00
|
|
|
if (!pango_font_family_is_monospace(family))
|
|
|
|
flags |= FONTFLAG_NONMONOSPACED;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
familyname = pango_font_family_get_name(family);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Go through the available font faces in this family.
|
|
|
|
*/
|
|
|
|
pango_font_family_list_faces(family, &faces, &nfaces);
|
|
|
|
for (j = 0; j < nfaces; j++) {
|
|
|
|
PangoFontFace *face = faces[j];
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
const char *facename;
|
|
|
|
int *sizes;
|
|
|
|
int k, nsizes, dummysize;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the face name string.
|
|
|
|
*/
|
|
|
|
facename = pango_font_face_get_face_name(face);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set up a font description with what we've got so
|
|
|
|
* far. We'll fill in the size field manually and then
|
|
|
|
* call pango_font_description_to_string() to give the
|
|
|
|
* full real name of the specific font.
|
|
|
|
*/
|
|
|
|
desc = pango_font_face_describe(face);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See if this font has a list of specific sizes.
|
|
|
|
*/
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT4
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_face_list_sizes(face, &sizes, &nsizes);
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* In early versions of Pango, that call wasn't
|
|
|
|
* supported; we just have to assume everything is
|
|
|
|
* scalable.
|
|
|
|
*/
|
|
|
|
sizes = NULL;
|
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
if (!sizes) {
|
|
|
|
/*
|
|
|
|
* Write a single entry with a dummy size.
|
|
|
|
*/
|
|
|
|
dummysize = PANGO_DUMMY_SIZE * PANGO_SCALE;
|
|
|
|
sizes = &dummysize;
|
|
|
|
nsizes = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If so, go through them one by one.
|
|
|
|
*/
|
|
|
|
for (k = 0; k < nsizes; k++) {
|
|
|
|
char *fullname;
|
2008-03-26 23:20:25 +03:00
|
|
|
char stylekey[128];
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
pango_font_description_set_size(desc, sizes[k]);
|
|
|
|
|
|
|
|
fullname = pango_font_description_to_string(desc);
|
|
|
|
|
2008-03-26 23:20:25 +03:00
|
|
|
/*
|
|
|
|
* Construct the sorting key for font styles.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
char *p = stylekey;
|
|
|
|
int n;
|
|
|
|
|
|
|
|
n = pango_font_description_get_weight(desc);
|
|
|
|
/* Weight: normal, then lighter, then bolder */
|
|
|
|
if (n <= PANGO_WEIGHT_NORMAL)
|
|
|
|
n = PANGO_WEIGHT_NORMAL - n;
|
|
|
|
p += sprintf(p, "%4d", n);
|
|
|
|
|
|
|
|
n = pango_font_description_get_style(desc);
|
|
|
|
p += sprintf(p, " %2d", n);
|
|
|
|
|
|
|
|
n = pango_font_description_get_stretch(desc);
|
|
|
|
/* Stretch: closer to normal sorts earlier */
|
|
|
|
n = 2 * abs(PANGO_STRETCH_NORMAL - n) +
|
|
|
|
(n < PANGO_STRETCH_NORMAL);
|
|
|
|
p += sprintf(p, " %2d", n);
|
|
|
|
|
|
|
|
n = pango_font_description_get_variant(desc);
|
|
|
|
p += sprintf(p, " %2d", n);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
|
|
|
* Got everything. Hand off to the callback.
|
|
|
|
* (The charset string is NULL, because only
|
|
|
|
* server-side X fonts use it.)
|
|
|
|
*/
|
|
|
|
callback(callback_ctx, fullname, familyname, NULL, facename,
|
2008-03-26 23:20:25 +03:00
|
|
|
stylekey,
|
2008-03-26 00:49:14 +03:00
|
|
|
(sizes == &dummysize ? 0 : PANGO_PIXELS(sizes[k])),
|
|
|
|
flags, &pangofont_vtable);
|
|
|
|
|
|
|
|
g_free(fullname);
|
|
|
|
}
|
|
|
|
if (sizes != &dummysize)
|
|
|
|
g_free(sizes);
|
|
|
|
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
}
|
|
|
|
g_free(faces);
|
|
|
|
}
|
|
|
|
g_free(families);
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *pangofont_canonify_fontname(GtkWidget *widget, const char *name,
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int *size, int *flags,
|
|
|
|
int resolve_aliases)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* When given a Pango font name to try to make sense of for a
|
|
|
|
* font selector, we must normalise it to PANGO_DUMMY_SIZE and
|
|
|
|
* extract its original size (in pixels) into the `size' field.
|
|
|
|
*/
|
|
|
|
PangoContext *ctx;
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontMap *map;
|
2008-03-26 21:30:20 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
PangoFontDescription *desc;
|
|
|
|
PangoFontset *fset;
|
|
|
|
PangoFontMetrics *metrics;
|
|
|
|
char *newname, *retname;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string(name);
|
|
|
|
if (!desc)
|
|
|
|
return NULL;
|
|
|
|
ctx = gtk_widget_get_pango_context(widget);
|
|
|
|
if (!ctx) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
2008-03-29 18:44:32 +03:00
|
|
|
if (!pangofont_check_desc_makes_sense(ctx, desc)) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
2008-03-26 21:30:20 +03:00
|
|
|
#ifndef PANGO_PRE_1POINT6
|
2008-03-26 00:49:14 +03:00
|
|
|
map = pango_context_get_font_map(ctx);
|
|
|
|
if (!map) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
fset = pango_font_map_load_fontset(map, ctx, desc,
|
|
|
|
pango_context_get_language(ctx));
|
2008-03-26 21:30:20 +03:00
|
|
|
#else
|
|
|
|
fset = pango_context_load_fontset(ctx, desc,
|
|
|
|
pango_context_get_language(ctx));
|
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
if (!fset) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
metrics = pango_fontset_get_metrics(fset);
|
|
|
|
if (!metrics ||
|
|
|
|
pango_font_metrics_get_approximate_digit_width(metrics) == 0) {
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
g_object_unref(fset);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
*size = PANGO_PIXELS(pango_font_description_get_size(desc));
|
2008-04-13 11:48:10 +04:00
|
|
|
*flags = FONTFLAG_CLIENTSIDE;
|
2008-03-26 00:49:14 +03:00
|
|
|
pango_font_description_set_size(desc, PANGO_DUMMY_SIZE * PANGO_SCALE);
|
|
|
|
newname = pango_font_description_to_string(desc);
|
|
|
|
retname = dupstr(newname);
|
|
|
|
g_free(newname);
|
|
|
|
|
|
|
|
pango_font_metrics_unref(metrics);
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
g_object_unref(fset);
|
|
|
|
|
|
|
|
return retname;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *pangofont_scale_fontname(GtkWidget *widget, const char *name,
|
|
|
|
int size)
|
|
|
|
{
|
|
|
|
PangoFontDescription *desc;
|
|
|
|
char *newname, *retname;
|
|
|
|
|
|
|
|
desc = pango_font_description_from_string(name);
|
|
|
|
if (!desc)
|
|
|
|
return NULL;
|
|
|
|
pango_font_description_set_size(desc, size * PANGO_SCALE);
|
|
|
|
newname = pango_font_description_to_string(desc);
|
|
|
|
retname = dupstr(newname);
|
|
|
|
g_free(newname);
|
|
|
|
pango_font_description_free(desc);
|
|
|
|
|
|
|
|
return retname;
|
|
|
|
}
|
|
|
|
|
2008-04-04 14:56:26 +04:00
|
|
|
#endif /* GTK_CHECK_VERSION(2,0,0) */
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
|
|
|
* Outermost functions which do the vtable dispatch.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2008-03-26 00:49:14 +03:00
|
|
|
* Complete list of font-type subclasses. Listed in preference
|
|
|
|
* order for unifont_create(). (That is, in the extremely unlikely
|
|
|
|
* event that the same font name is valid as both a Pango and an
|
|
|
|
* X11 font, it will be interpreted as the former in the absence
|
|
|
|
* of an explicit type-disambiguating prefix.)
|
2011-09-16 23:18:54 +04:00
|
|
|
*
|
|
|
|
* The 'multifont' subclass is omitted here, as discussed above.
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
static const struct unifont_vtable *unifont_types[] = {
|
2008-04-04 14:56:26 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,0,0)
|
2008-03-22 21:11:17 +03:00
|
|
|
&pangofont_vtable,
|
2008-04-04 14:56:26 +04:00
|
|
|
#endif
|
2015-08-08 18:35:19 +03:00
|
|
|
#ifndef NOT_X_WINDOWS
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
&x11font_vtable,
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
};
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Function which takes a font name and processes the optional
|
|
|
|
* scheme prefix. Returns the tail of the font name suitable for
|
|
|
|
* passing to individual font scheme functions, and also provides
|
|
|
|
* a subrange of the unifont_types[] array above.
|
|
|
|
*
|
|
|
|
* The return values `start' and `end' denote a half-open interval
|
|
|
|
* in unifont_types[]; that is, the correct way to iterate over
|
|
|
|
* them is
|
|
|
|
*
|
|
|
|
* for (i = start; i < end; i++) {...}
|
|
|
|
*/
|
|
|
|
static const char *unifont_do_prefix(const char *name, int *start, int *end)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
|
|
|
int colonpos = strcspn(name, ":");
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (name[colonpos]) {
|
|
|
|
/*
|
|
|
|
* There's a colon prefix on the font name. Use it to work
|
2008-03-26 00:49:14 +03:00
|
|
|
* out which subclass to use.
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
|
|
|
for (i = 0; i < lenof(unifont_types); i++) {
|
|
|
|
if (strlen(unifont_types[i]->prefix) == colonpos &&
|
2008-03-26 00:49:14 +03:00
|
|
|
!strncmp(unifont_types[i]->prefix, name, colonpos)) {
|
|
|
|
*start = i;
|
|
|
|
*end = i+1;
|
|
|
|
return name + colonpos + 1;
|
|
|
|
}
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
|
|
|
* None matched, so return an empty scheme list to prevent
|
|
|
|
* any scheme from being called at all.
|
|
|
|
*/
|
|
|
|
*start = *end = 0;
|
|
|
|
return name + colonpos + 1;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
} else {
|
|
|
|
/*
|
2008-03-26 00:49:14 +03:00
|
|
|
* No colon prefix, so just use all the subclasses.
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
*/
|
2008-03-26 00:49:14 +03:00
|
|
|
*start = 0;
|
|
|
|
*end = lenof(unifont_types);
|
|
|
|
return name;
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
unifont *unifont_create(GtkWidget *widget, const char *name, int wide,
|
|
|
|
int bold, int shadowoffset, int shadowalways)
|
|
|
|
{
|
|
|
|
int i, start, end;
|
|
|
|
|
|
|
|
name = unifont_do_prefix(name, &start, &end);
|
|
|
|
|
|
|
|
for (i = start; i < end; i++) {
|
|
|
|
unifont *ret = unifont_types[i]->create(widget, name, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
return NULL; /* font not found in any scheme */
|
|
|
|
}
|
|
|
|
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
void unifont_destroy(unifont *font)
|
|
|
|
{
|
|
|
|
font->vt->destroy(font);
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
void unifont_draw_text(unifont_drawctx *ctx, unifont *font,
|
2011-09-16 23:18:53 +04:00
|
|
|
int x, int y, const wchar_t *string, int len,
|
2008-03-22 21:11:17 +03:00
|
|
|
int wide, int bold, int cellwidth)
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
{
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
font->vt->draw_text(ctx, font, x, y, string, len, wide, bold, cellwidth);
|
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]
2008-03-22 14:40:23 +03:00
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2011-09-16 23:18:54 +04:00
|
|
|
/* ----------------------------------------------------------------------
|
|
|
|
* Multiple-font wrapper. This is a type of unifont which encapsulates
|
|
|
|
* up to two other unifonts, permitting missing glyphs in the main
|
|
|
|
* font to be filled in by a fallback font.
|
|
|
|
*
|
|
|
|
* This is a type of unifont just like the previous two, but it has a
|
|
|
|
* separate constructor which is manually called by the client, so it
|
|
|
|
* doesn't appear in the list of available font types enumerated by
|
|
|
|
* unifont_create. This means it's not used by unifontsel either, so
|
|
|
|
* it doesn't need to support any methods except draw_text and
|
|
|
|
* destroy.
|
|
|
|
*/
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void multifont_draw_text(unifont_drawctx *ctx, unifont *font,
|
|
|
|
int x, int y, const wchar_t *string, int len,
|
|
|
|
int wide, int bold, int cellwidth);
|
2011-09-16 23:18:54 +04:00
|
|
|
static void multifont_destroy(unifont *font);
|
|
|
|
|
|
|
|
struct multifont {
|
|
|
|
struct unifont u;
|
|
|
|
unifont *main;
|
|
|
|
unifont *fallback;
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct unifont_vtable multifont_vtable = {
|
|
|
|
NULL, /* creation is done specially */
|
|
|
|
NULL,
|
|
|
|
multifont_destroy,
|
|
|
|
NULL,
|
|
|
|
multifont_draw_text,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
"client",
|
|
|
|
};
|
|
|
|
|
|
|
|
unifont *multifont_create(GtkWidget *widget, const char *name,
|
|
|
|
int wide, int bold,
|
|
|
|
int shadowoffset, int shadowalways)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unifont *font, *fallback;
|
|
|
|
struct multifont *mfont;
|
|
|
|
|
|
|
|
font = unifont_create(widget, name, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
if (!font)
|
|
|
|
return NULL;
|
|
|
|
|
2011-09-19 20:21:25 +04:00
|
|
|
fallback = NULL;
|
2011-09-16 23:18:54 +04:00
|
|
|
if (font->want_fallback) {
|
|
|
|
for (i = 0; i < lenof(unifont_types); i++) {
|
|
|
|
if (unifont_types[i]->create_fallback) {
|
|
|
|
fallback = unifont_types[i]->create_fallback
|
|
|
|
(widget, font->height, wide, bold,
|
|
|
|
shadowoffset, shadowalways);
|
|
|
|
if (fallback)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct our multifont. Public members are all copied from the
|
|
|
|
* primary font we're wrapping.
|
|
|
|
*/
|
|
|
|
mfont = snew(struct multifont);
|
|
|
|
mfont->u.vt = &multifont_vtable;
|
|
|
|
mfont->u.width = font->width;
|
|
|
|
mfont->u.ascent = font->ascent;
|
|
|
|
mfont->u.descent = font->descent;
|
|
|
|
mfont->u.height = font->height;
|
|
|
|
mfont->u.public_charset = font->public_charset;
|
|
|
|
mfont->u.want_fallback = FALSE; /* shouldn't be needed, but just in case */
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
mfont->u.preferred_drawtype = font->preferred_drawtype;
|
2011-09-16 23:18:54 +04:00
|
|
|
mfont->main = font;
|
|
|
|
mfont->fallback = fallback;
|
|
|
|
|
|
|
|
return (unifont *)mfont;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void multifont_destroy(unifont *font)
|
|
|
|
{
|
|
|
|
struct multifont *mfont = (struct multifont *)font;
|
|
|
|
unifont_destroy(mfont->main);
|
|
|
|
if (mfont->fallback)
|
|
|
|
unifont_destroy(mfont->fallback);
|
|
|
|
sfree(font);
|
|
|
|
}
|
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
static void multifont_draw_text(unifont_drawctx *ctx, unifont *font, int x,
|
|
|
|
int y, const wchar_t *string, int len,
|
|
|
|
int wide, int bold, int cellwidth)
|
2011-09-16 23:18:54 +04:00
|
|
|
{
|
|
|
|
struct multifont *mfont = (struct multifont *)font;
|
2015-08-15 22:26:07 +03:00
|
|
|
unifont *f;
|
2011-09-16 23:18:54 +04:00
|
|
|
int ok, i;
|
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
/*
|
|
|
|
* Find a maximal sequence of characters which are, or are
|
|
|
|
* not, supported by our main font.
|
|
|
|
*/
|
|
|
|
ok = mfont->main->vt->has_glyph(mfont->main, string[0]);
|
|
|
|
for (i = 1;
|
|
|
|
i < len &&
|
|
|
|
!mfont->main->vt->has_glyph(mfont->main, string[i]) == !ok;
|
|
|
|
i++);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now display it.
|
|
|
|
*/
|
2015-08-15 22:26:07 +03:00
|
|
|
f = ok ? mfont->main : mfont->fallback;
|
|
|
|
if (f)
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
unifont_draw_text(ctx, f, x, y, string, i, wide, bold, cellwidth);
|
2011-09-16 23:18:54 +04:00
|
|
|
string += i;
|
|
|
|
len -= i;
|
|
|
|
x += i * cellwidth;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-25 21:50:23 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
|
|
|
* Utility routine used by the code below, and also gtkdlg.c.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void get_label_text_dimensions(const char *text, int *width, int *height)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Determine the dimensions of a piece of text in the standard
|
|
|
|
* font used in GTK interface elements like labels. We do this by
|
|
|
|
* instantiating an actual GtkLabel, and then querying its size.
|
|
|
|
*
|
|
|
|
* But GTK2 and GTK3 require us to query the size completely
|
|
|
|
* differently. I'm sure there ought to be an easier approach than
|
|
|
|
* the way I'm doing this in GTK3, too!
|
|
|
|
*/
|
|
|
|
GtkWidget *label = gtk_label_new(text);
|
|
|
|
|
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
PangoLayout *layout = gtk_label_get_layout(GTK_LABEL(label));
|
|
|
|
PangoRectangle logrect;
|
|
|
|
pango_layout_get_extents(layout, NULL, &logrect);
|
|
|
|
if (width)
|
|
|
|
*width = logrect.width / PANGO_SCALE;
|
|
|
|
if (height)
|
|
|
|
*height = logrect.height / PANGO_SCALE;
|
|
|
|
#else
|
|
|
|
GtkRequisition req;
|
|
|
|
gtk_widget_size_request(label, &req);
|
|
|
|
if (width)
|
|
|
|
*width = req.width;
|
|
|
|
if (height)
|
|
|
|
*height = req.height;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
g_object_ref_sink(G_OBJECT(label));
|
|
|
|
#if GTK_CHECK_VERSION(2,10,0)
|
|
|
|
g_object_unref(label);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2008-04-04 14:56:26 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,0,0)
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/* ----------------------------------------------------------------------
|
2008-04-04 14:56:26 +04:00
|
|
|
* Implementation of a unified font selector. Used on GTK 2 only;
|
|
|
|
* for GTK 1 we still use the standard font selector.
|
2008-03-26 00:49:14 +03:00
|
|
|
*/
|
|
|
|
|
|
|
|
typedef struct fontinfo fontinfo;
|
|
|
|
|
|
|
|
typedef struct unifontsel_internal {
|
|
|
|
/* This must be the structure's first element, for cross-casting */
|
|
|
|
unifontsel u;
|
|
|
|
GtkListStore *family_model, *style_model, *size_model;
|
|
|
|
GtkWidget *family_list, *style_list, *size_entry, *size_list;
|
|
|
|
GtkWidget *filter_buttons[4];
|
2015-08-08 18:35:19 +03:00
|
|
|
int n_filter_buttons;
|
2008-03-27 22:41:08 +03:00
|
|
|
GtkWidget *preview_area;
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
GdkPixmap *preview_pixmap;
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
int preview_width, preview_height;
|
|
|
|
GdkColor preview_fg, preview_bg;
|
2008-03-26 00:49:14 +03:00
|
|
|
int filter_flags;
|
|
|
|
tree234 *fonts_by_realname, *fonts_by_selorder;
|
|
|
|
fontinfo *selected;
|
2008-03-29 13:16:48 +03:00
|
|
|
int selsize, intendedsize;
|
2008-03-26 00:49:14 +03:00
|
|
|
int inhibit_response; /* inhibit callbacks when we change GUI controls */
|
|
|
|
} unifontsel_internal;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The structure held in the tree234s. All the string members are
|
|
|
|
* part of the same allocated area, so don't need freeing
|
|
|
|
* separately.
|
|
|
|
*/
|
|
|
|
struct fontinfo {
|
|
|
|
char *realname;
|
2008-03-26 23:20:25 +03:00
|
|
|
char *family, *charset, *style, *stylekey;
|
2008-03-26 00:49:14 +03:00
|
|
|
int size, flags;
|
|
|
|
/*
|
|
|
|
* Fallback sorting key, to permit multiple identical entries
|
|
|
|
* to exist in the selorder tree.
|
|
|
|
*/
|
|
|
|
int index;
|
|
|
|
/*
|
|
|
|
* Indices mapping fontinfo structures to indices in the list
|
|
|
|
* boxes. sizeindex is irrelevant if the font is scalable
|
|
|
|
* (size==0).
|
|
|
|
*/
|
|
|
|
int familyindex, styleindex, sizeindex;
|
|
|
|
/*
|
|
|
|
* The class of font.
|
|
|
|
*/
|
|
|
|
const struct unifont_vtable *fontclass;
|
|
|
|
};
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
struct fontinfo_realname_find {
|
|
|
|
const char *realname;
|
|
|
|
int flags;
|
|
|
|
};
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
static int strnullcasecmp(const char *a, const char *b)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If exactly one of the inputs is NULL, it compares before
|
|
|
|
* the other one.
|
|
|
|
*/
|
|
|
|
if ((i = (!b) - (!a)) != 0)
|
|
|
|
return i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NULL compares equal.
|
|
|
|
*/
|
|
|
|
if (!a)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, ordinary strcasecmp.
|
|
|
|
*/
|
2012-01-03 23:43:19 +04:00
|
|
|
return g_ascii_strcasecmp(a, b);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
static int fontinfo_realname_compare(void *av, void *bv)
|
|
|
|
{
|
|
|
|
fontinfo *a = (fontinfo *)av;
|
|
|
|
fontinfo *b = (fontinfo *)bv;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if ((i = strnullcasecmp(a->realname, b->realname)) != 0)
|
|
|
|
return i;
|
|
|
|
if ((a->flags & FONTFLAG_SORT_MASK) != (b->flags & FONTFLAG_SORT_MASK))
|
|
|
|
return ((a->flags & FONTFLAG_SORT_MASK) <
|
|
|
|
(b->flags & FONTFLAG_SORT_MASK) ? -1 : +1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int fontinfo_realname_find(void *av, void *bv)
|
|
|
|
{
|
|
|
|
struct fontinfo_realname_find *a = (struct fontinfo_realname_find *)av;
|
|
|
|
fontinfo *b = (fontinfo *)bv;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if ((i = strnullcasecmp(a->realname, b->realname)) != 0)
|
|
|
|
return i;
|
|
|
|
if ((a->flags & FONTFLAG_SORT_MASK) != (b->flags & FONTFLAG_SORT_MASK))
|
|
|
|
return ((a->flags & FONTFLAG_SORT_MASK) <
|
|
|
|
(b->flags & FONTFLAG_SORT_MASK) ? -1 : +1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static int fontinfo_selorder_compare(void *av, void *bv)
|
|
|
|
{
|
|
|
|
fontinfo *a = (fontinfo *)av;
|
|
|
|
fontinfo *b = (fontinfo *)bv;
|
|
|
|
int i;
|
|
|
|
if ((i = strnullcasecmp(a->family, b->family)) != 0)
|
|
|
|
return i;
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
/*
|
|
|
|
* Font class comes immediately after family, so that fonts
|
|
|
|
* from different classes with the same family
|
|
|
|
*/
|
|
|
|
if ((a->flags & FONTFLAG_SORT_MASK) != (b->flags & FONTFLAG_SORT_MASK))
|
|
|
|
return ((a->flags & FONTFLAG_SORT_MASK) <
|
|
|
|
(b->flags & FONTFLAG_SORT_MASK) ? -1 : +1);
|
2008-03-26 00:49:14 +03:00
|
|
|
if ((i = strnullcasecmp(a->charset, b->charset)) != 0)
|
|
|
|
return i;
|
2008-03-26 23:20:25 +03:00
|
|
|
if ((i = strnullcasecmp(a->stylekey, b->stylekey)) != 0)
|
|
|
|
return i;
|
2008-03-26 00:49:14 +03:00
|
|
|
if ((i = strnullcasecmp(a->style, b->style)) != 0)
|
|
|
|
return i;
|
|
|
|
if (a->size != b->size)
|
|
|
|
return (a->size < b->size ? -1 : +1);
|
|
|
|
if (a->index != b->index)
|
|
|
|
return (a->index < b->index ? -1 : +1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-08-22 15:41:15 +03:00
|
|
|
static void unifontsel_draw_preview_text(unifontsel_internal *fs);
|
|
|
|
|
2008-04-14 21:57:45 +04:00
|
|
|
static void unifontsel_deselect(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
fs->selected = NULL;
|
|
|
|
gtk_list_store_clear(fs->style_model);
|
|
|
|
gtk_list_store_clear(fs->size_model);
|
|
|
|
gtk_widget_set_sensitive(fs->u.ok_button, FALSE);
|
|
|
|
gtk_widget_set_sensitive(fs->size_entry, FALSE);
|
2015-08-22 15:41:15 +03:00
|
|
|
unifontsel_draw_preview_text(fs);
|
2008-04-14 21:57:45 +04:00
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void unifontsel_setup_familylist(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
GtkTreeIter iter;
|
|
|
|
int i, listindex, minpos = -1, maxpos = -1;
|
|
|
|
char *currfamily = NULL;
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int currflags = -1;
|
2008-03-26 00:49:14 +03:00
|
|
|
fontinfo *info;
|
|
|
|
|
2015-08-22 15:41:11 +03:00
|
|
|
fs->inhibit_response = TRUE;
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_list_store_clear(fs->family_model);
|
|
|
|
listindex = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search through the font tree for anything matching our
|
|
|
|
* current filter criteria. When we find one, add its font
|
|
|
|
* name to the list box.
|
|
|
|
*/
|
|
|
|
for (i = 0 ;; i++) {
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, i);
|
|
|
|
/*
|
|
|
|
* info may be NULL if we've just run off the end of the
|
|
|
|
* tree. We must still do a processing pass in that
|
|
|
|
* situation, in case we had an unfinished font record in
|
|
|
|
* progress.
|
|
|
|
*/
|
|
|
|
if (info && (info->flags &~ fs->filter_flags)) {
|
|
|
|
info->familyindex = -1;
|
|
|
|
continue; /* we're filtering out this font */
|
|
|
|
}
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
if (!info || strnullcasecmp(currfamily, info->family) ||
|
|
|
|
currflags != (info->flags & FONTFLAG_SORT_MASK)) {
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
|
|
|
* We've either finished a family, or started a new
|
|
|
|
* one, or both.
|
|
|
|
*/
|
|
|
|
if (currfamily) {
|
|
|
|
gtk_list_store_append(fs->family_model, &iter);
|
|
|
|
gtk_list_store_set(fs->family_model, &iter,
|
|
|
|
0, currfamily, 1, minpos, 2, maxpos+1, -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
if (info) {
|
|
|
|
minpos = i;
|
|
|
|
currfamily = info->family;
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
currflags = info->flags & FONTFLAG_SORT_MASK;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!info)
|
|
|
|
break; /* now we're done */
|
|
|
|
info->familyindex = listindex;
|
|
|
|
maxpos = i;
|
|
|
|
}
|
2008-04-14 21:57:45 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we've just filtered out the previously selected font,
|
|
|
|
* deselect it thoroughly.
|
|
|
|
*/
|
|
|
|
if (fs->selected && fs->selected->familyindex < 0)
|
|
|
|
unifontsel_deselect(fs);
|
2015-08-22 15:41:11 +03:00
|
|
|
|
|
|
|
fs->inhibit_response = FALSE;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_setup_stylelist(unifontsel_internal *fs,
|
|
|
|
int start, int end)
|
|
|
|
{
|
|
|
|
GtkTreeIter iter;
|
|
|
|
int i, listindex, minpos = -1, maxpos = -1, started = FALSE;
|
|
|
|
char *currcs = NULL, *currstyle = NULL;
|
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
gtk_list_store_clear(fs->style_model);
|
|
|
|
listindex = 0;
|
|
|
|
started = FALSE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search through the font tree for anything matching our
|
|
|
|
* current filter criteria. When we find one, add its charset
|
|
|
|
* and/or style name to the list box.
|
|
|
|
*/
|
|
|
|
for (i = start; i <= end; i++) {
|
|
|
|
if (i == end)
|
|
|
|
info = NULL;
|
|
|
|
else
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, i);
|
|
|
|
/*
|
|
|
|
* info may be NULL if we've just run off the end of the
|
|
|
|
* relevant data. We must still do a processing pass in
|
|
|
|
* that situation, in case we had an unfinished font
|
|
|
|
* record in progress.
|
|
|
|
*/
|
|
|
|
if (info && (info->flags &~ fs->filter_flags)) {
|
|
|
|
info->styleindex = -1;
|
|
|
|
continue; /* we're filtering out this font */
|
|
|
|
}
|
|
|
|
if (!info || !started || strnullcasecmp(currcs, info->charset) ||
|
|
|
|
strnullcasecmp(currstyle, info->style)) {
|
|
|
|
/*
|
|
|
|
* We've either finished a style/charset, or started a
|
|
|
|
* new one, or both.
|
|
|
|
*/
|
|
|
|
started = TRUE;
|
|
|
|
if (currstyle) {
|
|
|
|
gtk_list_store_append(fs->style_model, &iter);
|
|
|
|
gtk_list_store_set(fs->style_model, &iter,
|
|
|
|
0, currstyle, 1, minpos, 2, maxpos+1,
|
|
|
|
3, TRUE, -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
if (info) {
|
|
|
|
minpos = i;
|
|
|
|
if (info->charset && strnullcasecmp(currcs, info->charset)) {
|
|
|
|
gtk_list_store_append(fs->style_model, &iter);
|
|
|
|
gtk_list_store_set(fs->style_model, &iter,
|
|
|
|
0, info->charset, 1, -1, 2, -1,
|
|
|
|
3, FALSE, -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
currcs = info->charset;
|
|
|
|
currstyle = info->style;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!info)
|
|
|
|
break; /* now we're done */
|
|
|
|
info->styleindex = listindex;
|
|
|
|
maxpos = i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static const int unifontsel_default_sizes[] = { 10, 12, 14, 16, 20, 24, 32 };
|
|
|
|
|
|
|
|
static void unifontsel_setup_sizelist(unifontsel_internal *fs,
|
|
|
|
int start, int end)
|
|
|
|
{
|
|
|
|
GtkTreeIter iter;
|
|
|
|
int i, listindex;
|
|
|
|
char sizetext[40];
|
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
gtk_list_store_clear(fs->size_model);
|
|
|
|
listindex = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search through the font tree for anything matching our
|
|
|
|
* current filter criteria. When we find one, add its font
|
|
|
|
* name to the list box.
|
|
|
|
*/
|
|
|
|
for (i = start; i < end; i++) {
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, i);
|
|
|
|
if (info->flags &~ fs->filter_flags) {
|
|
|
|
info->sizeindex = -1;
|
|
|
|
continue; /* we're filtering out this font */
|
|
|
|
}
|
|
|
|
if (info->size) {
|
|
|
|
sprintf(sizetext, "%d", info->size);
|
|
|
|
info->sizeindex = listindex;
|
|
|
|
gtk_list_store_append(fs->size_model, &iter);
|
|
|
|
gtk_list_store_set(fs->size_model, &iter,
|
|
|
|
0, sizetext, 1, i, 2, info->size, -1);
|
|
|
|
listindex++;
|
|
|
|
} else {
|
|
|
|
int j;
|
|
|
|
|
|
|
|
assert(i == start);
|
|
|
|
assert(i+1 == end);
|
|
|
|
|
|
|
|
for (j = 0; j < lenof(unifontsel_default_sizes); j++) {
|
|
|
|
sprintf(sizetext, "%d", unifontsel_default_sizes[j]);
|
|
|
|
gtk_list_store_append(fs->size_model, &iter);
|
|
|
|
gtk_list_store_set(fs->size_model, &iter, 0, sizetext, 1, i,
|
|
|
|
2, unifontsel_default_sizes[j], -1);
|
|
|
|
listindex++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_set_filter_buttons(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
for (i = 0; i < fs->n_filter_buttons; i++) {
|
2015-08-08 19:29:02 +03:00
|
|
|
int flagbit = GPOINTER_TO_INT(g_object_get_data
|
|
|
|
(G_OBJECT(fs->filter_buttons[i]),
|
2008-03-26 00:49:14 +03:00
|
|
|
"user-data"));
|
|
|
|
gtk_toggle_button_set_active(GTK_TOGGLE_BUTTON(fs->filter_buttons[i]),
|
|
|
|
!!(fs->filter_flags & flagbit));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-16 12:32:24 +03:00
|
|
|
static void unifontsel_draw_preview_text_inner(unifont_drawctx *dctx,
|
|
|
|
unifontsel_internal *fs)
|
2008-03-27 22:53:28 +03:00
|
|
|
{
|
|
|
|
unifont *font;
|
2008-03-29 16:59:31 +03:00
|
|
|
char *sizename = NULL;
|
2008-03-27 22:53:28 +03:00
|
|
|
fontinfo *info = fs->selected;
|
|
|
|
|
2008-03-29 16:59:31 +03:00
|
|
|
if (info) {
|
|
|
|
sizename = info->fontclass->scale_fontname
|
|
|
|
(GTK_WIDGET(fs->u.window), info->realname, fs->selsize);
|
|
|
|
font = info->fontclass->create(GTK_WIDGET(fs->u.window),
|
|
|
|
sizename ? sizename : info->realname,
|
|
|
|
FALSE, FALSE, 0, 0);
|
|
|
|
} else
|
|
|
|
font = NULL;
|
2008-03-27 22:53:28 +03:00
|
|
|
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
2015-08-22 15:41:15 +03:00
|
|
|
if (dctx->type == DRAWTYPE_GDK) {
|
|
|
|
gdk_gc_set_foreground(dctx->u.gdk.gc, &fs->preview_bg);
|
|
|
|
gdk_draw_rectangle(dctx->u.gdk.target, dctx->u.gdk.gc, 1, 0, 0,
|
|
|
|
fs->preview_width, fs->preview_height);
|
|
|
|
gdk_gc_set_foreground(dctx->u.gdk.gc, &fs->preview_fg);
|
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
2015-08-22 15:41:15 +03:00
|
|
|
if (dctx->type == DRAWTYPE_CAIRO) {
|
|
|
|
cairo_set_source_rgb(dctx->u.cairo.cr,
|
|
|
|
fs->preview_bg.red / 65535.0,
|
|
|
|
fs->preview_bg.green / 65535.0,
|
|
|
|
fs->preview_bg.blue / 65535.0);
|
|
|
|
cairo_paint(dctx->u.cairo.cr);
|
|
|
|
cairo_set_source_rgb(dctx->u.cairo.cr,
|
|
|
|
fs->preview_fg.red / 65535.0,
|
|
|
|
fs->preview_fg.green / 65535.0,
|
|
|
|
fs->preview_fg.blue / 65535.0);
|
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
|
2015-08-22 15:41:15 +03:00
|
|
|
if (font) {
|
2015-08-16 12:32:24 +03:00
|
|
|
/*
|
|
|
|
* The pangram used here is rather carefully
|
|
|
|
* constructed: it contains a sequence of very narrow
|
|
|
|
* letters (`jil') and a pair of adjacent very wide
|
|
|
|
* letters (`wm').
|
|
|
|
*
|
|
|
|
* If the user selects a proportional font, it will be
|
|
|
|
* coerced into fixed-width character cells when used
|
|
|
|
* in the actual terminal window. We therefore display
|
|
|
|
* it the same way in the preview pane, so as to show
|
|
|
|
* it the way it will actually be displayed - and we
|
|
|
|
* deliberately pick a pangram which will show the
|
|
|
|
* resulting miskerning at its worst.
|
|
|
|
*
|
|
|
|
* We aren't trying to sell people these fonts; we're
|
|
|
|
* trying to let them make an informed choice. Better
|
|
|
|
* that they find out the problems with using
|
|
|
|
* proportional fonts in terminal windows here than
|
|
|
|
* that they go to the effort of selecting their font
|
|
|
|
* and _then_ realise it was a mistake.
|
|
|
|
*/
|
|
|
|
info->fontclass->draw_text(dctx, font,
|
|
|
|
0, font->ascent,
|
|
|
|
L"bankrupt jilted showmen quiz convex fogey",
|
|
|
|
41, FALSE, FALSE, font->width);
|
|
|
|
info->fontclass->draw_text(dctx, font,
|
|
|
|
0, font->ascent + font->height,
|
|
|
|
L"BANKRUPT JILTED SHOWMEN QUIZ CONVEX FOGEY",
|
|
|
|
41, FALSE, FALSE, font->width);
|
|
|
|
/*
|
|
|
|
* The ordering of punctuation here is also selected
|
|
|
|
* with some specific aims in mind. I put ` and '
|
|
|
|
* together because some software (and people) still
|
|
|
|
* use them as matched quotes no matter what Unicode
|
|
|
|
* might say on the matter, so people can quickly
|
|
|
|
* check whether they look silly in a candidate font.
|
|
|
|
* The sequence #_@ is there to let people judge the
|
|
|
|
* suitability of the underscore as an effectively
|
|
|
|
* alphabetic character (since that's how it's often
|
|
|
|
* used in practice, at least by programmers).
|
|
|
|
*/
|
|
|
|
info->fontclass->draw_text(dctx, font,
|
|
|
|
0, font->ascent + font->height * 2,
|
|
|
|
L"0123456789!?,.:;<>()[]{}\\/`'\"+*-=~#_@|%&^$",
|
|
|
|
42, FALSE, FALSE, font->width);
|
|
|
|
|
|
|
|
info->fontclass->destroy(font);
|
|
|
|
}
|
|
|
|
|
|
|
|
sfree(sizename);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_draw_preview_text(unifontsel_internal *fs)
|
|
|
|
{
|
|
|
|
unifont_drawctx dctx;
|
2015-08-16 11:02:31 +03:00
|
|
|
GdkWindow *target;
|
2015-08-16 12:32:24 +03:00
|
|
|
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
|
|
|
target = fs->preview_pixmap;
|
|
|
|
#else
|
|
|
|
target = gtk_widget_get_window(fs->preview_area);
|
|
|
|
#endif
|
|
|
|
if (!target) /* we may be called when we haven't created everything yet */
|
2015-08-16 12:32:24 +03:00
|
|
|
return;
|
|
|
|
|
|
|
|
dctx.type = DRAWTYPE_DEFAULT;
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#ifdef DRAW_TEXT_GDK
|
2015-08-16 12:32:24 +03:00
|
|
|
if (dctx.type == DRAWTYPE_GDK) {
|
2015-08-16 11:02:31 +03:00
|
|
|
dctx.u.gdk.target = target;
|
|
|
|
dctx.u.gdk.gc = gdk_gc_new(target);
|
2015-08-16 12:32:24 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
2015-08-16 12:32:24 +03:00
|
|
|
if (dctx.type == DRAWTYPE_CAIRO) {
|
|
|
|
dctx.u.cairo.widget = GTK_WIDGET(fs->preview_area);
|
2015-08-16 11:02:31 +03:00
|
|
|
dctx.u.cairo.cr = gdk_cairo_create(target);
|
2015-08-16 12:32:24 +03:00
|
|
|
}
|
Refactor the GTK drawing system to do both GDK and Cairo.
We're going to have to use Cairo in the GTK3 port, because that's all
GTK3 supports; but we still need old-style GDK for GTK1 support, and
also for performance reasons in GTK2 (see below). Hence, this change
completely restructures GTK PuTTY's drawing code so that there's a
central 'drawing context' structure which contains a type code
indicating GDK or Cairo, and then either some GDK gubbins or some
Cairo gubbins as appropriate; all actual drawing is abstracted through
a set of routines which test the type code in that structure and do
one thing or another. And because the type code is tested at run time,
both sets of drawing primitives can be compiled in at once, and where
possible, they will be.
X server-side bitmap fonts are still supported in the Cairo world, but
because Cairo drawing is entirely client-side, they have to work by
cheekily downloading each glyph bitmap from the server when it's first
needed, and building up a client-side cache of 'cairo_surface_t's
containing the bitmaps with which we then draw on the window. This
technique works, but it's rather slow; hence, even in GTK2, we keep
the GDK drawing back end compiled in, and switch over to it when the
main selected font is a bitmap one.
One visible effect of the new Cairo routines is in the double-width
and double-height text you can get by sending ESC # 3, ESC # 4 and
ESC # 6 escape sequences. In GDK, that's always been done by a really
horrible process of manually scaling the bitmap, server-side, column
by column and row by row, causing each pixel to be exactly doubled or
quadrupled. But in Cairo, we can just set a transformation matrix, and
then that takes effect _before_ the scalable fonts are rendered - so
the results are visibly nicer, and use all the available resolution.
(Sadly, if you're using a server-side bitmap font as your primary one,
then the GDK backend will be selected for all drawing in the terminal
as a whole - so in that situation, even fallback characters absent
from the primary font and rendered by Pango will get the old GDK
scaling treatment. It's only if your main font is scalable, so that
the Cairo backend is selected, that DW/DH characters will come out
looking nice.)
2015-08-15 23:05:56 +03:00
|
|
|
#endif
|
|
|
|
|
2015-08-16 12:32:24 +03:00
|
|
|
unifontsel_draw_preview_text_inner(&dctx, fs);
|
|
|
|
|
|
|
|
#ifdef DRAW_TEXT_GDK
|
|
|
|
if (dctx.type == DRAWTYPE_GDK) {
|
|
|
|
gdk_gc_unref(dctx.u.gdk.gc);
|
2008-03-27 22:53:28 +03:00
|
|
|
}
|
2015-08-16 12:32:24 +03:00
|
|
|
#endif
|
|
|
|
#ifdef DRAW_TEXT_CAIRO
|
|
|
|
if (dctx.type == DRAWTYPE_CAIRO) {
|
|
|
|
cairo_destroy(dctx.u.cairo.cr);
|
|
|
|
}
|
|
|
|
#endif
|
2008-03-27 22:53:28 +03:00
|
|
|
|
2015-08-16 12:32:24 +03:00
|
|
|
gdk_window_invalidate_rect(gtk_widget_get_window(fs->preview_area),
|
|
|
|
NULL, FALSE);
|
2008-03-27 22:53:28 +03:00
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void unifontsel_select_font(unifontsel_internal *fs,
|
2008-03-29 13:16:48 +03:00
|
|
|
fontinfo *info, int size, int leftlist,
|
|
|
|
int size_is_explicit)
|
2008-03-26 00:49:14 +03:00
|
|
|
{
|
|
|
|
int index;
|
|
|
|
int minval, maxval;
|
2015-08-22 15:41:11 +03:00
|
|
|
gboolean success;
|
2008-03-26 00:49:14 +03:00
|
|
|
GtkTreePath *treepath;
|
|
|
|
GtkTreeIter iter;
|
|
|
|
|
|
|
|
fs->inhibit_response = TRUE;
|
|
|
|
|
|
|
|
fs->selected = info;
|
|
|
|
fs->selsize = size;
|
2008-03-29 13:16:48 +03:00
|
|
|
if (size_is_explicit)
|
|
|
|
fs->intendedsize = size;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2008-03-29 17:21:25 +03:00
|
|
|
gtk_widget_set_sensitive(fs->u.ok_button, TRUE);
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
|
|
|
* Find the index of this fontinfo in the selorder list.
|
|
|
|
*/
|
|
|
|
index = -1;
|
|
|
|
findpos234(fs->fonts_by_selorder, info, NULL, &index);
|
|
|
|
assert(index >= 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adjust the font selector flags and redo the font family
|
|
|
|
* list box, if necessary.
|
|
|
|
*/
|
|
|
|
if (leftlist <= 0 &&
|
|
|
|
(fs->filter_flags | info->flags) != fs->filter_flags) {
|
|
|
|
fs->filter_flags |= info->flags;
|
|
|
|
unifontsel_set_filter_buttons(fs);
|
|
|
|
unifontsel_setup_familylist(fs);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the appropriate family name and select it in the list.
|
|
|
|
*/
|
|
|
|
assert(info->familyindex >= 0);
|
|
|
|
treepath = gtk_tree_path_new_from_indices(info->familyindex, -1);
|
|
|
|
gtk_tree_selection_select_path
|
|
|
|
(gtk_tree_view_get_selection(GTK_TREE_VIEW(fs->family_list)),
|
|
|
|
treepath);
|
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->family_list),
|
|
|
|
treepath, NULL, FALSE, 0.0, 0.0);
|
2015-08-22 15:41:11 +03:00
|
|
|
success = gtk_tree_model_get_iter(GTK_TREE_MODEL(fs->family_model),
|
|
|
|
&iter, treepath);
|
|
|
|
assert(success);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now set up the font style list.
|
|
|
|
*/
|
|
|
|
gtk_tree_model_get(GTK_TREE_MODEL(fs->family_model), &iter,
|
|
|
|
1, &minval, 2, &maxval, -1);
|
|
|
|
if (leftlist <= 1)
|
|
|
|
unifontsel_setup_stylelist(fs, minval, maxval);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the appropriate style name and select it in the list.
|
|
|
|
*/
|
|
|
|
if (info->style) {
|
|
|
|
assert(info->styleindex >= 0);
|
|
|
|
treepath = gtk_tree_path_new_from_indices(info->styleindex, -1);
|
|
|
|
gtk_tree_selection_select_path
|
|
|
|
(gtk_tree_view_get_selection(GTK_TREE_VIEW(fs->style_list)),
|
|
|
|
treepath);
|
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->style_list),
|
|
|
|
treepath, NULL, FALSE, 0.0, 0.0);
|
|
|
|
gtk_tree_model_get_iter(GTK_TREE_MODEL(fs->style_model),
|
|
|
|
&iter, treepath);
|
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And set up the size list.
|
|
|
|
*/
|
|
|
|
gtk_tree_model_get(GTK_TREE_MODEL(fs->style_model), &iter,
|
|
|
|
1, &minval, 2, &maxval, -1);
|
|
|
|
if (leftlist <= 2)
|
|
|
|
unifontsel_setup_sizelist(fs, minval, maxval);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the appropriate size, and select it in the list.
|
|
|
|
*/
|
|
|
|
if (info->size) {
|
|
|
|
assert(info->sizeindex >= 0);
|
|
|
|
treepath = gtk_tree_path_new_from_indices(info->sizeindex, -1);
|
|
|
|
gtk_tree_selection_select_path
|
|
|
|
(gtk_tree_view_get_selection(GTK_TREE_VIEW(fs->size_list)),
|
|
|
|
treepath);
|
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->size_list),
|
|
|
|
treepath, NULL, FALSE, 0.0, 0.0);
|
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
size = info->size;
|
|
|
|
} else {
|
|
|
|
int j;
|
|
|
|
for (j = 0; j < lenof(unifontsel_default_sizes); j++)
|
|
|
|
if (unifontsel_default_sizes[j] == size) {
|
|
|
|
treepath = gtk_tree_path_new_from_indices(j, -1);
|
|
|
|
gtk_tree_view_set_cursor(GTK_TREE_VIEW(fs->size_list),
|
|
|
|
treepath, NULL, FALSE);
|
|
|
|
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW(fs->size_list),
|
|
|
|
treepath, NULL, FALSE, 0.0,
|
|
|
|
0.0);
|
|
|
|
gtk_tree_path_free(treepath);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And set up the font size text entry box.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
char sizetext[40];
|
|
|
|
sprintf(sizetext, "%d", size);
|
|
|
|
gtk_entry_set_text(GTK_ENTRY(fs->size_entry), sizetext);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (leftlist <= 2)
|
|
|
|
unifontsel_setup_sizelist(fs, 0, 0);
|
|
|
|
gtk_entry_set_text(GTK_ENTRY(fs->size_entry), "");
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Grey out the font size edit box if we're not using a
|
|
|
|
* scalable font.
|
|
|
|
*/
|
2015-08-08 20:02:01 +03:00
|
|
|
gtk_editable_set_editable(GTK_EDITABLE(fs->size_entry),
|
|
|
|
fs->selected->size == 0);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_set_sensitive(fs->size_entry, fs->selected->size == 0);
|
|
|
|
|
2008-03-27 22:53:28 +03:00
|
|
|
unifontsel_draw_preview_text(fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->inhibit_response = FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_button_toggled(GtkToggleButton *tb, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
int newstate = gtk_toggle_button_get_active(tb);
|
|
|
|
int newflags;
|
2015-08-08 19:29:02 +03:00
|
|
|
int flagbit = GPOINTER_TO_INT(g_object_get_data(G_OBJECT(tb),
|
|
|
|
"user-data"));
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (newstate)
|
|
|
|
newflags = fs->filter_flags | flagbit;
|
|
|
|
else
|
|
|
|
newflags = fs->filter_flags & ~flagbit;
|
|
|
|
|
|
|
|
if (fs->filter_flags != newflags) {
|
|
|
|
fs->filter_flags = newflags;
|
|
|
|
unifontsel_setup_familylist(fs);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unifontsel_add_entry(void *ctx, const char *realfontname,
|
|
|
|
const char *family, const char *charset,
|
2008-03-26 23:20:25 +03:00
|
|
|
const char *style, const char *stylekey,
|
|
|
|
int size, int flags,
|
2008-03-26 00:49:14 +03:00
|
|
|
const struct unifont_vtable *fontclass)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)ctx;
|
|
|
|
fontinfo *info;
|
|
|
|
int totalsize;
|
|
|
|
char *p;
|
|
|
|
|
|
|
|
totalsize = sizeof(fontinfo) + strlen(realfontname) +
|
|
|
|
(family ? strlen(family) : 0) + (charset ? strlen(charset) : 0) +
|
2008-03-26 23:20:25 +03:00
|
|
|
(style ? strlen(style) : 0) + (stylekey ? strlen(stylekey) : 0) + 10;
|
2008-03-26 00:49:14 +03:00
|
|
|
info = (fontinfo *)smalloc(totalsize);
|
|
|
|
info->fontclass = fontclass;
|
|
|
|
p = (char *)info + sizeof(fontinfo);
|
|
|
|
info->realname = p;
|
|
|
|
strcpy(p, realfontname);
|
|
|
|
p += 1+strlen(p);
|
|
|
|
if (family) {
|
|
|
|
info->family = p;
|
|
|
|
strcpy(p, family);
|
|
|
|
p += 1+strlen(p);
|
|
|
|
} else
|
|
|
|
info->family = NULL;
|
|
|
|
if (charset) {
|
|
|
|
info->charset = p;
|
|
|
|
strcpy(p, charset);
|
|
|
|
p += 1+strlen(p);
|
|
|
|
} else
|
|
|
|
info->charset = NULL;
|
|
|
|
if (style) {
|
|
|
|
info->style = p;
|
|
|
|
strcpy(p, style);
|
|
|
|
p += 1+strlen(p);
|
|
|
|
} else
|
|
|
|
info->style = NULL;
|
2008-03-26 23:20:25 +03:00
|
|
|
if (stylekey) {
|
|
|
|
info->stylekey = p;
|
|
|
|
strcpy(p, stylekey);
|
|
|
|
p += 1+strlen(p);
|
|
|
|
} else
|
|
|
|
info->stylekey = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
assert(p - (char *)info <= totalsize);
|
|
|
|
info->size = size;
|
|
|
|
info->flags = flags;
|
|
|
|
info->index = count234(fs->fonts_by_selorder);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It's just conceivable that a misbehaving font enumerator
|
|
|
|
* might tell us about the same font real name more than once,
|
|
|
|
* in which case we should silently drop the new one.
|
|
|
|
*/
|
|
|
|
if (add234(fs->fonts_by_realname, info) != info) {
|
|
|
|
sfree(info);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* However, we should never get a duplicate key in the
|
|
|
|
* selorder tree, because the index field carefully
|
|
|
|
* disambiguates otherwise identical records.
|
|
|
|
*/
|
|
|
|
add234(fs->fonts_by_selorder, info);
|
|
|
|
}
|
|
|
|
|
2008-03-29 13:16:48 +03:00
|
|
|
static fontinfo *update_for_intended_size(unifontsel_internal *fs,
|
|
|
|
fontinfo *info)
|
|
|
|
{
|
|
|
|
fontinfo info2, *below, *above;
|
|
|
|
int pos;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copy the info structure. This doesn't copy its dynamic
|
|
|
|
* string fields, but that's unimportant because all we're
|
|
|
|
* going to do is to adjust the size field and use it in one
|
|
|
|
* tree search.
|
|
|
|
*/
|
|
|
|
info2 = *info;
|
|
|
|
info2.size = fs->intendedsize;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search in the tree to find the fontinfo structure which
|
|
|
|
* best approximates the size the user last requested.
|
|
|
|
*/
|
|
|
|
below = findrelpos234(fs->fonts_by_selorder, &info2, NULL,
|
|
|
|
REL234_LE, &pos);
|
2013-07-11 21:24:28 +04:00
|
|
|
if (!below)
|
|
|
|
pos = -1;
|
2008-03-29 13:16:48 +03:00
|
|
|
above = index234(fs->fonts_by_selorder, pos+1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See if we've found it exactly, which is an easy special
|
|
|
|
* case. If we have, it'll be in `below' and not `above',
|
|
|
|
* because we did a REL234_LE rather than REL234_LT search.
|
|
|
|
*/
|
2013-07-11 21:24:28 +04:00
|
|
|
if (below && !fontinfo_selorder_compare(&info2, below))
|
2008-03-29 13:16:48 +03:00
|
|
|
return below;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we've either found two suitable fonts, one smaller and
|
|
|
|
* one larger, or we're at one or other extreme end of the
|
|
|
|
* scale. Find out which, by NULLing out either of below and
|
|
|
|
* above if it differs from this one in any respect but size
|
|
|
|
* (and the disambiguating index field). Bear in mind, also,
|
|
|
|
* that either one might _already_ be NULL if we're at the
|
|
|
|
* extreme ends of the font list.
|
|
|
|
*/
|
|
|
|
if (below) {
|
|
|
|
info2.size = below->size;
|
|
|
|
info2.index = below->index;
|
|
|
|
if (fontinfo_selorder_compare(&info2, below))
|
|
|
|
below = NULL;
|
|
|
|
}
|
|
|
|
if (above) {
|
|
|
|
info2.size = above->size;
|
|
|
|
info2.index = above->index;
|
|
|
|
if (fontinfo_selorder_compare(&info2, above))
|
|
|
|
above = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now return whichever of above and below is non-NULL, if
|
|
|
|
* that's unambiguous.
|
|
|
|
*/
|
|
|
|
if (!above)
|
|
|
|
return below;
|
|
|
|
if (!below)
|
|
|
|
return above;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And now we really do have to make a choice about whether to
|
|
|
|
* round up or down. We'll do it by rounding to nearest,
|
|
|
|
* breaking ties by rounding up.
|
|
|
|
*/
|
|
|
|
if (above->size - fs->intendedsize <= fs->intendedsize - below->size)
|
|
|
|
return above;
|
|
|
|
else
|
|
|
|
return below;
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
static void family_changed(GtkTreeSelection *treeselection, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeModel *treemodel;
|
|
|
|
GtkTreeIter treeiter;
|
|
|
|
int minval;
|
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!gtk_tree_selection_get_selected(treeselection, &treemodel, &treeiter))
|
|
|
|
return;
|
|
|
|
|
|
|
|
gtk_tree_model_get(treemodel, &treeiter, 1, &minval, -1);
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
2008-03-29 13:16:48 +03:00
|
|
|
info = update_for_intended_size(fs, info);
|
|
|
|
if (!info)
|
|
|
|
return; /* _shouldn't_ happen unless font list is completely funted */
|
|
|
|
if (!info->size)
|
|
|
|
fs->selsize = fs->intendedsize; /* font is scalable */
|
|
|
|
unifontsel_select_font(fs, info, info->size ? info->size : fs->selsize,
|
|
|
|
1, FALSE);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void style_changed(GtkTreeSelection *treeselection, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeModel *treemodel;
|
|
|
|
GtkTreeIter treeiter;
|
|
|
|
int minval;
|
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!gtk_tree_selection_get_selected(treeselection, &treemodel, &treeiter))
|
|
|
|
return;
|
|
|
|
|
|
|
|
gtk_tree_model_get(treemodel, &treeiter, 1, &minval, -1);
|
2008-03-26 21:30:20 +03:00
|
|
|
if (minval < 0)
|
|
|
|
return; /* somehow a charset heading got clicked */
|
2008-03-26 00:49:14 +03:00
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
2008-03-29 13:16:48 +03:00
|
|
|
info = update_for_intended_size(fs, info);
|
|
|
|
if (!info)
|
|
|
|
return; /* _shouldn't_ happen unless font list is completely funted */
|
|
|
|
if (!info->size)
|
|
|
|
fs->selsize = fs->intendedsize; /* font is scalable */
|
|
|
|
unifontsel_select_font(fs, info, info->size ? info->size : fs->selsize,
|
|
|
|
2, FALSE);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void size_changed(GtkTreeSelection *treeselection, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeModel *treemodel;
|
|
|
|
GtkTreeIter treeiter;
|
|
|
|
int minval, size;
|
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!gtk_tree_selection_get_selected(treeselection, &treemodel, &treeiter))
|
|
|
|
return;
|
|
|
|
|
|
|
|
gtk_tree_model_get(treemodel, &treeiter, 1, &minval, 2, &size, -1);
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
2008-03-29 13:16:48 +03:00
|
|
|
unifontsel_select_font(fs, info, info->size ? info->size : size, 3, TRUE);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static void size_entry_changed(GtkEditable *ed, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
const char *text;
|
|
|
|
int size;
|
|
|
|
|
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
|
|
|
|
|
|
|
text = gtk_entry_get_text(GTK_ENTRY(ed));
|
|
|
|
size = atoi(text);
|
|
|
|
|
|
|
|
if (size > 0) {
|
|
|
|
assert(fs->selected->size == 0);
|
2008-03-29 13:16:48 +03:00
|
|
|
unifontsel_select_font(fs, fs->selected, size, 3, TRUE);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-27 22:41:08 +03:00
|
|
|
static void alias_resolve(GtkTreeView *treeview, GtkTreePath *path,
|
|
|
|
GtkTreeViewColumn *column, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
GtkTreeIter iter;
|
|
|
|
int minval, newsize;
|
|
|
|
fontinfo *info, *newinfo;
|
|
|
|
char *newname;
|
|
|
|
|
|
|
|
if (fs->inhibit_response) /* we made this change ourselves */
|
|
|
|
return;
|
|
|
|
|
|
|
|
gtk_tree_model_get_iter(GTK_TREE_MODEL(fs->family_model), &iter, path);
|
|
|
|
gtk_tree_model_get(GTK_TREE_MODEL(fs->family_model), &iter, 1,&minval, -1);
|
|
|
|
info = (fontinfo *)index234(fs->fonts_by_selorder, minval);
|
|
|
|
if (info) {
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int flags;
|
|
|
|
struct fontinfo_realname_find f;
|
|
|
|
|
2008-03-27 22:41:08 +03:00
|
|
|
newname = info->fontclass->canonify_fontname
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
(GTK_WIDGET(fs->u.window), info->realname, &newsize, &flags, TRUE);
|
|
|
|
|
|
|
|
f.realname = newname;
|
|
|
|
f.flags = flags;
|
|
|
|
newinfo = find234(fs->fonts_by_realname, &f, fontinfo_realname_find);
|
|
|
|
|
2008-03-27 22:41:08 +03:00
|
|
|
sfree(newname);
|
|
|
|
if (!newinfo)
|
|
|
|
return; /* font name not in our index */
|
|
|
|
if (newinfo == info)
|
|
|
|
return; /* didn't change under canonification => not an alias */
|
|
|
|
unifontsel_select_font(fs, newinfo,
|
2008-03-29 13:16:48 +03:00
|
|
|
newinfo->size ? newinfo->size : newsize,
|
|
|
|
1, TRUE);
|
2008-03-27 22:41:08 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-16 16:34:19 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
static gint unifontsel_draw_area(GtkWidget *widget, cairo_t *cr, gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
unifont_drawctx dctx;
|
|
|
|
|
|
|
|
dctx.type = DRAWTYPE_CAIRO;
|
|
|
|
dctx.u.cairo.widget = widget;
|
|
|
|
dctx.u.cairo.cr = cr;
|
|
|
|
unifontsel_draw_preview_text_inner(&dctx, fs);
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
#else
|
2008-03-27 22:41:08 +03:00
|
|
|
static gint unifontsel_expose_area(GtkWidget *widget, GdkEventExpose *event,
|
|
|
|
gpointer data)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
if (fs->preview_pixmap) {
|
2015-08-08 17:53:43 +03:00
|
|
|
gdk_draw_pixmap(gtk_widget_get_window(widget),
|
|
|
|
(gtk_widget_get_style(widget)->fg_gc
|
|
|
|
[gtk_widget_get_state(widget)]),
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_pixmap,
|
|
|
|
event->area.x, event->area.y,
|
|
|
|
event->area.x, event->area.y,
|
|
|
|
event->area.width, event->area.height);
|
|
|
|
}
|
2015-08-16 11:02:31 +03:00
|
|
|
#else
|
|
|
|
unifontsel_draw_preview_text(fs);
|
|
|
|
#endif
|
|
|
|
|
2008-03-27 22:41:08 +03:00
|
|
|
return TRUE;
|
|
|
|
}
|
2015-08-16 16:34:19 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
|
|
|
static gint unifontsel_configure_area(GtkWidget *widget,
|
|
|
|
GdkEventConfigure *event, gpointer data)
|
|
|
|
{
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)data;
|
|
|
|
int ox, oy, nx, ny, x, y;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Enlarge the pixmap, but never shrink it.
|
|
|
|
*/
|
|
|
|
ox = fs->preview_width;
|
|
|
|
oy = fs->preview_height;
|
|
|
|
x = event->width;
|
|
|
|
y = event->height;
|
|
|
|
if (x > ox || y > oy) {
|
2008-03-27 22:53:28 +03:00
|
|
|
if (fs->preview_pixmap)
|
|
|
|
gdk_pixmap_unref(fs->preview_pixmap);
|
|
|
|
|
2008-03-27 22:41:08 +03:00
|
|
|
nx = (x > ox ? x : ox);
|
|
|
|
ny = (y > oy ? y : oy);
|
2015-08-08 17:53:43 +03:00
|
|
|
fs->preview_pixmap = gdk_pixmap_new(gtk_widget_get_window(widget),
|
|
|
|
nx, ny, -1);
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_width = nx;
|
|
|
|
fs->preview_height = ny;
|
2008-03-27 22:53:28 +03:00
|
|
|
|
|
|
|
unifontsel_draw_preview_text(fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
}
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2015-08-08 17:53:43 +03:00
|
|
|
gdk_window_invalidate_rect(gtk_widget_get_window(widget), NULL, FALSE);
|
2008-03-27 22:41:08 +03:00
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
unifontsel *unifontsel_new(const char *wintitle)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = snew(unifontsel_internal);
|
2008-03-29 16:55:40 +03:00
|
|
|
GtkWidget *table, *label, *w, *ww, *scroll;
|
2008-03-26 00:49:14 +03:00
|
|
|
GtkListStore *model;
|
|
|
|
GtkTreeViewColumn *column;
|
2008-03-27 22:41:08 +03:00
|
|
|
int lists_height, preview_height, font_width, style_width, size_width;
|
2008-03-26 00:49:14 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
fs->inhibit_response = FALSE;
|
2008-04-14 22:00:57 +04:00
|
|
|
fs->selected = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
{
|
2015-08-22 13:46:05 +03:00
|
|
|
int width, height;
|
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
/*
|
|
|
|
* Invent some magic size constants.
|
|
|
|
*/
|
2015-08-22 13:46:05 +03:00
|
|
|
get_label_text_dimensions("Quite Long Font Name (Foundry)",
|
|
|
|
&width, &height);
|
|
|
|
font_width = width;
|
|
|
|
lists_height = 14 * height;
|
|
|
|
preview_height = 5 * height;
|
|
|
|
|
|
|
|
get_label_text_dimensions("Italic Extra Condensed", &width, &height);
|
|
|
|
style_width = width;
|
|
|
|
|
|
|
|
get_label_text_dimensions("48000", &width, &height);
|
|
|
|
size_width = width;
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create the dialog box and initialise the user-visible
|
|
|
|
* fields in the returned structure.
|
|
|
|
*/
|
|
|
|
fs->u.user_data = NULL;
|
|
|
|
fs->u.window = GTK_WINDOW(gtk_dialog_new());
|
|
|
|
gtk_window_set_title(fs->u.window, wintitle);
|
|
|
|
fs->u.cancel_button = gtk_dialog_add_button
|
2015-08-22 15:50:56 +03:00
|
|
|
(GTK_DIALOG(fs->u.window), STANDARD_CANCEL_LABEL, GTK_RESPONSE_CANCEL);
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->u.ok_button = gtk_dialog_add_button
|
2015-08-22 15:50:56 +03:00
|
|
|
(GTK_DIALOG(fs->u.window), STANDARD_OK_LABEL, GTK_RESPONSE_OK);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_grab_default(fs->u.ok_button);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now set up the internal fields, including in particular all
|
|
|
|
* the controls that actually allow the user to select fonts.
|
|
|
|
*/
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
table = gtk_grid_new();
|
|
|
|
gtk_grid_set_column_spacing(GTK_GRID(table), 8);
|
|
|
|
#else
|
2008-03-29 17:54:55 +03:00
|
|
|
table = gtk_table_new(8, 3, FALSE);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_set_col_spacings(GTK_TABLE(table), 8);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
|
|
|
gtk_widget_show(table);
|
2008-05-31 23:23:45 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,4,0)
|
2008-03-29 17:54:55 +03:00
|
|
|
/* GtkAlignment seems to be the simplest way to put padding round things */
|
|
|
|
w = gtk_alignment_new(0, 0, 1, 1);
|
|
|
|
gtk_alignment_set_padding(GTK_ALIGNMENT(w), 8, 8, 8, 8);
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), table);
|
|
|
|
gtk_widget_show(w);
|
2008-05-31 23:23:45 +04:00
|
|
|
#else
|
|
|
|
w = table;
|
|
|
|
#endif
|
2015-08-08 17:53:43 +03:00
|
|
|
gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area
|
|
|
|
(GTK_DIALOG(fs->u.window))),
|
2008-03-29 17:54:55 +03:00
|
|
|
w, TRUE, TRUE, 0);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
label = gtk_label_new_with_mnemonic("_Font:");
|
|
|
|
gtk_widget_show(label);
|
2015-08-31 15:57:34 +03:00
|
|
|
align_label_left(GTK_LABEL(label));
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), label, 0, 0, 1, 1);
|
|
|
|
g_object_set(G_OBJECT(label), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), label, 0, 1, 0, 1, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The Font list box displays only a string, but additionally
|
|
|
|
* stores two integers which give the limits within the
|
|
|
|
* tree234 of the font entries covered by this list entry.
|
|
|
|
*/
|
|
|
|
model = gtk_list_store_new(3, G_TYPE_STRING, G_TYPE_INT, G_TYPE_INT);
|
|
|
|
w = gtk_tree_view_new_with_model(GTK_TREE_MODEL(model));
|
|
|
|
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(w), FALSE);
|
|
|
|
gtk_label_set_mnemonic_widget(GTK_LABEL(label), w);
|
|
|
|
gtk_widget_show(w);
|
|
|
|
column = gtk_tree_view_column_new_with_attributes
|
|
|
|
("Font", gtk_cell_renderer_text_new(),
|
|
|
|
"text", 0, (char *)NULL);
|
|
|
|
gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_AUTOSIZE);
|
|
|
|
gtk_tree_view_append_column(GTK_TREE_VIEW(w), column);
|
|
|
|
g_signal_connect(G_OBJECT(gtk_tree_view_get_selection(GTK_TREE_VIEW(w))),
|
|
|
|
"changed", G_CALLBACK(family_changed), fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
g_signal_connect(G_OBJECT(w), "row-activated",
|
|
|
|
G_CALLBACK(alias_resolve), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
scroll = gtk_scrolled_window_new(NULL, NULL);
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_scrolled_window_set_shadow_type(GTK_SCROLLED_WINDOW(scroll),
|
|
|
|
GTK_SHADOW_IN);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_container_add(GTK_CONTAINER(scroll), w);
|
|
|
|
gtk_widget_show(scroll);
|
|
|
|
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scroll),
|
|
|
|
GTK_POLICY_AUTOMATIC, GTK_POLICY_ALWAYS);
|
|
|
|
gtk_widget_set_size_request(scroll, font_width, lists_height);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), scroll, 0, 1, 1, 2);
|
|
|
|
g_object_set(G_OBJECT(scroll), "expand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), scroll, 0, 1, 1, 3, GTK_FILL,
|
|
|
|
GTK_EXPAND | GTK_FILL, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->family_model = model;
|
|
|
|
fs->family_list = w;
|
|
|
|
|
|
|
|
label = gtk_label_new_with_mnemonic("_Style:");
|
|
|
|
gtk_widget_show(label);
|
2015-08-31 15:57:34 +03:00
|
|
|
align_label_left(GTK_LABEL(label));
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), label, 1, 0, 1, 1);
|
|
|
|
g_object_set(G_OBJECT(label), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), label, 1, 2, 0, 1, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The Style list box can contain insensitive elements
|
|
|
|
* (character set headings for server-side fonts), so we add
|
|
|
|
* an extra column to the list store to hold that information.
|
|
|
|
*/
|
|
|
|
model = gtk_list_store_new(4, G_TYPE_STRING, G_TYPE_INT, G_TYPE_INT,
|
|
|
|
G_TYPE_BOOLEAN);
|
|
|
|
w = gtk_tree_view_new_with_model(GTK_TREE_MODEL(model));
|
|
|
|
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(w), FALSE);
|
|
|
|
gtk_label_set_mnemonic_widget(GTK_LABEL(label), w);
|
|
|
|
gtk_widget_show(w);
|
|
|
|
column = gtk_tree_view_column_new_with_attributes
|
|
|
|
("Style", gtk_cell_renderer_text_new(),
|
|
|
|
"text", 0, "sensitive", 3, (char *)NULL);
|
|
|
|
gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_AUTOSIZE);
|
|
|
|
gtk_tree_view_append_column(GTK_TREE_VIEW(w), column);
|
|
|
|
g_signal_connect(G_OBJECT(gtk_tree_view_get_selection(GTK_TREE_VIEW(w))),
|
|
|
|
"changed", G_CALLBACK(style_changed), fs);
|
|
|
|
|
|
|
|
scroll = gtk_scrolled_window_new(NULL, NULL);
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_scrolled_window_set_shadow_type(GTK_SCROLLED_WINDOW(scroll),
|
|
|
|
GTK_SHADOW_IN);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_container_add(GTK_CONTAINER(scroll), w);
|
|
|
|
gtk_widget_show(scroll);
|
|
|
|
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scroll),
|
|
|
|
GTK_POLICY_AUTOMATIC, GTK_POLICY_ALWAYS);
|
|
|
|
gtk_widget_set_size_request(scroll, style_width, lists_height);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), scroll, 1, 1, 1, 2);
|
|
|
|
g_object_set(G_OBJECT(scroll), "expand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), scroll, 1, 2, 1, 3, GTK_FILL,
|
|
|
|
GTK_EXPAND | GTK_FILL, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->style_model = model;
|
|
|
|
fs->style_list = w;
|
|
|
|
|
|
|
|
label = gtk_label_new_with_mnemonic("Si_ze:");
|
|
|
|
gtk_widget_show(label);
|
2015-08-31 15:57:34 +03:00
|
|
|
align_label_left(GTK_LABEL(label));
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), label, 2, 0, 1, 1);
|
|
|
|
g_object_set(G_OBJECT(label), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), label, 2, 3, 0, 1, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The Size label attaches primarily to a text input box so
|
|
|
|
* that the user can select a size of their choice. The list
|
|
|
|
* of available sizes is secondary.
|
|
|
|
*/
|
|
|
|
fs->size_entry = w = gtk_entry_new();
|
|
|
|
gtk_label_set_mnemonic_widget(GTK_LABEL(label), w);
|
|
|
|
gtk_widget_set_size_request(w, size_width, -1);
|
|
|
|
gtk_widget_show(w);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 2, 1, 1, 1);
|
|
|
|
g_object_set(G_OBJECT(w), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 2, 3, 1, 2, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
g_signal_connect(G_OBJECT(w), "changed", G_CALLBACK(size_entry_changed),
|
|
|
|
fs);
|
|
|
|
|
|
|
|
model = gtk_list_store_new(3, G_TYPE_STRING, G_TYPE_INT, G_TYPE_INT);
|
|
|
|
w = gtk_tree_view_new_with_model(GTK_TREE_MODEL(model));
|
|
|
|
gtk_tree_view_set_headers_visible(GTK_TREE_VIEW(w), FALSE);
|
|
|
|
gtk_widget_show(w);
|
|
|
|
column = gtk_tree_view_column_new_with_attributes
|
|
|
|
("Size", gtk_cell_renderer_text_new(),
|
|
|
|
"text", 0, (char *)NULL);
|
|
|
|
gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_AUTOSIZE);
|
|
|
|
gtk_tree_view_append_column(GTK_TREE_VIEW(w), column);
|
|
|
|
g_signal_connect(G_OBJECT(gtk_tree_view_get_selection(GTK_TREE_VIEW(w))),
|
|
|
|
"changed", G_CALLBACK(size_changed), fs);
|
|
|
|
|
|
|
|
scroll = gtk_scrolled_window_new(NULL, NULL);
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_scrolled_window_set_shadow_type(GTK_SCROLLED_WINDOW(scroll),
|
|
|
|
GTK_SHADOW_IN);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_container_add(GTK_CONTAINER(scroll), w);
|
|
|
|
gtk_widget_show(scroll);
|
|
|
|
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scroll),
|
|
|
|
GTK_POLICY_AUTOMATIC, GTK_POLICY_ALWAYS);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), scroll, 2, 2, 1, 1);
|
|
|
|
g_object_set(G_OBJECT(scroll), "expand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), scroll, 2, 3, 2, 3, GTK_FILL,
|
|
|
|
GTK_EXPAND | GTK_FILL, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
fs->size_model = model;
|
|
|
|
fs->size_list = w;
|
|
|
|
|
2008-03-29 17:54:55 +03:00
|
|
|
/*
|
|
|
|
* Preview widget.
|
|
|
|
*/
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_area = gtk_drawing_area_new();
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_pixmap = NULL;
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
fs->preview_width = 0;
|
|
|
|
fs->preview_height = 0;
|
|
|
|
fs->preview_fg.pixel = fs->preview_bg.pixel = 0;
|
|
|
|
fs->preview_fg.red = fs->preview_fg.green = fs->preview_fg.blue = 0x0000;
|
|
|
|
fs->preview_bg.red = fs->preview_bg.green = fs->preview_bg.blue = 0xFFFF;
|
2015-08-16 16:22:14 +03:00
|
|
|
#if !GTK_CHECK_VERSION(3,0,0)
|
2008-03-27 22:41:08 +03:00
|
|
|
gdk_colormap_alloc_color(gdk_colormap_get_system(), &fs->preview_fg,
|
|
|
|
FALSE, FALSE);
|
|
|
|
gdk_colormap_alloc_color(gdk_colormap_get_system(), &fs->preview_bg,
|
|
|
|
FALSE, FALSE);
|
2015-08-16 16:22:14 +03:00
|
|
|
#endif
|
2015-08-16 16:34:19 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
g_signal_connect(G_OBJECT(fs->preview_area), "draw",
|
|
|
|
G_CALLBACK(unifontsel_draw_area), fs);
|
|
|
|
#else
|
2015-08-08 19:29:02 +03:00
|
|
|
g_signal_connect(G_OBJECT(fs->preview_area), "expose_event",
|
|
|
|
G_CALLBACK(unifontsel_expose_area), fs);
|
2015-08-16 16:34:19 +03:00
|
|
|
#endif
|
2015-08-08 19:29:02 +03:00
|
|
|
g_signal_connect(G_OBJECT(fs->preview_area), "configure_event",
|
|
|
|
G_CALLBACK(unifontsel_configure_area), fs);
|
2008-03-27 22:41:08 +03:00
|
|
|
gtk_widget_set_size_request(fs->preview_area, 1, preview_height);
|
|
|
|
gtk_widget_show(fs->preview_area);
|
2008-03-29 16:55:40 +03:00
|
|
|
ww = fs->preview_area;
|
|
|
|
w = gtk_frame_new(NULL);
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), ww);
|
|
|
|
gtk_widget_show(w);
|
2008-05-31 23:23:45 +04:00
|
|
|
#if GTK_CHECK_VERSION(2,4,0)
|
2008-03-29 16:55:40 +03:00
|
|
|
ww = w;
|
|
|
|
/* GtkAlignment seems to be the simplest way to put padding round things */
|
|
|
|
w = gtk_alignment_new(0, 0, 1, 1);
|
|
|
|
gtk_alignment_set_padding(GTK_ALIGNMENT(w), 8, 8, 8, 8);
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), ww);
|
|
|
|
gtk_widget_show(w);
|
2008-05-31 23:23:45 +04:00
|
|
|
#endif
|
2008-03-29 16:55:40 +03:00
|
|
|
ww = w;
|
|
|
|
w = gtk_frame_new("Preview of font");
|
|
|
|
gtk_container_add(GTK_CONTAINER(w), ww);
|
|
|
|
gtk_widget_show(w);
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 3, 3, 1);
|
|
|
|
g_object_set(G_OBJECT(w), "expand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-29 16:55:40 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 3, 4,
|
|
|
|
GTK_EXPAND | GTK_FILL, GTK_EXPAND | GTK_FILL, 0, 8);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
/*
|
|
|
|
* We only provide the checkboxes for client- and server-side
|
|
|
|
* fonts if we have the X11 back end available, because that's the
|
|
|
|
* only situation in which more than one class of font is
|
|
|
|
* available anyway.
|
|
|
|
*/
|
|
|
|
fs->n_filter_buttons = 0;
|
|
|
|
#ifndef NOT_X_WINDOWS
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show client-side fonts");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_CLIENTSIDE));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 4, 3, 1);
|
|
|
|
g_object_set(G_OBJECT(w), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 4, 5, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show server-side fonts");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_SERVERSIDE));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 5, 3, 1);
|
|
|
|
g_object_set(G_OBJECT(w), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 5, 6, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show server-side font aliases");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_SERVERALIAS));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 6, 3, 1);
|
|
|
|
g_object_set(G_OBJECT(w), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 6, 7, GTK_FILL, 0, 0, 0);
|
2015-08-08 18:35:19 +03:00
|
|
|
#endif
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif /* NOT_X_WINDOWS */
|
2008-03-26 00:49:14 +03:00
|
|
|
w = gtk_check_button_new_with_label("Show non-monospaced fonts");
|
2015-08-08 19:29:02 +03:00
|
|
|
g_object_set_data(G_OBJECT(w), "user-data",
|
|
|
|
GINT_TO_POINTER(FONTFLAG_NONMONOSPACED));
|
|
|
|
g_signal_connect(G_OBJECT(w), "toggled",
|
|
|
|
G_CALLBACK(unifontsel_button_toggled), fs);
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_widget_show(w);
|
2015-08-08 18:35:19 +03:00
|
|
|
fs->filter_buttons[fs->n_filter_buttons++] = w;
|
2015-08-22 16:28:04 +03:00
|
|
|
#if GTK_CHECK_VERSION(3,0,0)
|
|
|
|
gtk_grid_attach(GTK_GRID(table), w, 0, 7, 3, 1);
|
|
|
|
g_object_set(G_OBJECT(w), "hexpand", TRUE, (const char *)NULL);
|
|
|
|
#else
|
2008-03-26 00:49:14 +03:00
|
|
|
gtk_table_attach(GTK_TABLE(table), w, 0, 3, 7, 8, GTK_FILL, 0, 0, 0);
|
2015-08-22 16:28:04 +03:00
|
|
|
#endif
|
2008-03-26 00:49:14 +03:00
|
|
|
|
2015-08-08 18:35:19 +03:00
|
|
|
assert(fs->n_filter_buttons <= lenof(fs->filter_buttons));
|
2008-04-02 18:50:47 +04:00
|
|
|
fs->filter_flags = FONTFLAG_CLIENTSIDE | FONTFLAG_SERVERSIDE |
|
|
|
|
FONTFLAG_SERVERALIAS;
|
2008-03-26 00:49:14 +03:00
|
|
|
unifontsel_set_filter_buttons(fs);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Go and find all the font names, and set up our master font
|
|
|
|
* list.
|
|
|
|
*/
|
|
|
|
fs->fonts_by_realname = newtree234(fontinfo_realname_compare);
|
|
|
|
fs->fonts_by_selorder = newtree234(fontinfo_selorder_compare);
|
|
|
|
for (i = 0; i < lenof(unifont_types); i++)
|
|
|
|
unifont_types[i]->enum_fonts(GTK_WIDGET(fs->u.window),
|
|
|
|
unifontsel_add_entry, fs);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And set up the initial font names list.
|
|
|
|
*/
|
|
|
|
unifontsel_setup_familylist(fs);
|
|
|
|
|
2008-03-29 17:21:25 +03:00
|
|
|
fs->selsize = fs->intendedsize = 13; /* random default */
|
|
|
|
gtk_widget_set_sensitive(fs->u.ok_button, FALSE);
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
return (unifontsel *)fs;
|
|
|
|
}
|
|
|
|
|
|
|
|
void unifontsel_destroy(unifontsel *fontsel)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)fontsel;
|
|
|
|
fontinfo *info;
|
|
|
|
|
2015-08-16 11:02:31 +03:00
|
|
|
#ifndef NO_BACKING_PIXMAPS
|
2008-03-27 22:41:08 +03:00
|
|
|
if (fs->preview_pixmap)
|
|
|
|
gdk_pixmap_unref(fs->preview_pixmap);
|
2015-08-16 11:02:31 +03:00
|
|
|
#endif
|
2008-03-27 22:41:08 +03:00
|
|
|
|
2008-03-26 00:49:14 +03:00
|
|
|
freetree234(fs->fonts_by_selorder);
|
|
|
|
while ((info = delpos234(fs->fonts_by_realname, 0)) != NULL)
|
|
|
|
sfree(info);
|
|
|
|
freetree234(fs->fonts_by_realname);
|
|
|
|
|
|
|
|
gtk_widget_destroy(GTK_WIDGET(fs->u.window));
|
|
|
|
sfree(fs);
|
|
|
|
}
|
|
|
|
|
|
|
|
void unifontsel_set_name(unifontsel *fontsel, const char *fontname)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)fontsel;
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
int i, start, end, size, flags;
|
2008-03-26 21:16:52 +03:00
|
|
|
const char *fontname2 = NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
fontinfo *info;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Provide a default if given an empty or null font name.
|
|
|
|
*/
|
|
|
|
if (!fontname || !*fontname)
|
2015-08-31 15:24:09 +03:00
|
|
|
fontname = DEFAULT_GTK_FONT;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Call the canonify_fontname function.
|
|
|
|
*/
|
|
|
|
fontname = unifont_do_prefix(fontname, &start, &end);
|
|
|
|
for (i = start; i < end; i++) {
|
|
|
|
fontname2 = unifont_types[i]->canonify_fontname
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
(GTK_WIDGET(fs->u.window), fontname, &size, &flags, FALSE);
|
2008-03-26 00:49:14 +03:00
|
|
|
if (fontname2)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (i == end)
|
|
|
|
return; /* font name not recognised */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now look up the canonified font name in our index.
|
|
|
|
*/
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
{
|
|
|
|
struct fontinfo_realname_find f;
|
|
|
|
f.realname = fontname2;
|
|
|
|
f.flags = flags;
|
|
|
|
info = find234(fs->fonts_by_realname, &f, fontinfo_realname_find);
|
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we've found the font, and its size field is either
|
|
|
|
* correct or zero (the latter indicating a scalable font),
|
|
|
|
* then we're done. Otherwise, try looking up the original
|
|
|
|
* font name instead.
|
|
|
|
*/
|
|
|
|
if (!info || (info->size != size && info->size != 0)) {
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
struct fontinfo_realname_find f;
|
|
|
|
f.realname = fontname;
|
|
|
|
f.flags = flags;
|
|
|
|
|
|
|
|
info = find234(fs->fonts_by_realname, &f, fontinfo_realname_find);
|
2008-03-26 00:49:14 +03:00
|
|
|
if (!info || info->size != size)
|
|
|
|
return; /* font name not in our index */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we've got a fontinfo structure and a font size, so we
|
|
|
|
* know everything we need to fill in all the fields in the
|
|
|
|
* dialog.
|
|
|
|
*/
|
2008-03-29 13:16:48 +03:00
|
|
|
unifontsel_select_font(fs, info, size, 0, TRUE);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
char *unifontsel_get_name(unifontsel *fontsel)
|
|
|
|
{
|
|
|
|
unifontsel_internal *fs = (unifontsel_internal *)fontsel;
|
|
|
|
char *name;
|
|
|
|
|
2008-03-29 17:21:25 +03:00
|
|
|
if (!fs->selected)
|
|
|
|
return NULL;
|
2008-03-26 00:49:14 +03:00
|
|
|
|
|
|
|
if (fs->selected->size == 0) {
|
|
|
|
name = fs->selected->fontclass->scale_fontname
|
|
|
|
(GTK_WIDGET(fs->u.window), fs->selected->realname, fs->selsize);
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
if (name) {
|
|
|
|
char *ret = dupcat(fs->selected->fontclass->prefix, ":",
|
|
|
|
name, NULL);
|
|
|
|
sfree(name);
|
|
|
|
return ret;
|
|
|
|
}
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
|
|
|
|
In the new unified font handling, my strategy so far for combining
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]
2008-04-05 17:37:20 +04:00
|
|
|
return dupcat(fs->selected->fontclass->prefix, ":",
|
|
|
|
fs->selected->realname, NULL);
|
2008-03-26 00:49:14 +03:00
|
|
|
}
|
2008-04-04 14:56:26 +04:00
|
|
|
|
|
|
|
#endif /* GTK_CHECK_VERSION(2,0,0) */
|