On Sun, Sep 01, 2002 at 04:26:36PM +0200, Olivier Abad wrote:
> > You might want to ask on the gtk-app-devel-list how you'd do that (and
> > point out that it *is* useful).
>
> I searched the archives and found this message :
> http://mail.gnome.org/archives/gtk-app-devel-list/2002-July/msg00078.html
> with no reply. I'll try asking again.
Sigh.
According to
http://mail.gnome.org/archives/gtk-devel-list/2002-July/msg00202.html
the problem is that Pango, and thus GTK+, has no idea whether a font is
monospaced or not:
From: Owen Taylor <otaylor redhat com>
To: Allin Cottrell <cottrell wfu edu>
Cc: gtk-devel-list gnome org
Subject: Re: fonts in gtk-2.0/pango
Date: Sat, 27 Jul 2002 10:06:52 -0400 (EDT)
...
> Second observation: Pango has an elaborate classification system for
> fonts, but this system has some serious blind spots. So far as I can
> tell, Pango maintains no record of whether a font is monospaced or
> proportional. (I believe the X11 backend to pango reads this
> information when it queries the X server for available fonts, but then
> throws it away.) I presume this has something to do with its failure
> to provide correct metrics for Lucida Typewriter. I presume, too,
> that it has something to do with the removal of the "filter" mechanism
> on the GTK font selection dialog between 1.2 and 2.0. That is, you
> used to be able to specify that the font selection should show only
> monospaced fonts (rather essential for terminal/console type
> applications) but you can't any more -- I guess, because pango has no
> notion of what's a monospaced font and what's not.
Give us code that can distinguish reliably between monospaced and
not-monospaced fonts for Type1 and TrueType fonts and at that
point it becomes reasonable to think about such an API. It's
not all that easy to do.
Even then, there are still problems - Pango by default will
draw characters not in the main font using fallback fonts --
whose metrics almost certainly don't match your grid. So,
you'd have to be able to turn this off.
so I guess we'll just have to show the user fonts that would cause the
display to suck, as well as fonts that wouldn't - and, if we ever go to
using UCS-4/Unicode or a UTF-8 encoding of same internally for strings,
it sounds (from the fallback font comment) as if we'd run the risk that,
for some packets, some machines might have *no* font that'll make the
display not suck.