fonts in gtk-2.0/pango
- From: Allin Cottrell <cottrell wfu edu>
- To: gtk-devel-list gnome org
- Subject: fonts in gtk-2.0/pango
- Date: Fri, 26 Jul 2002 23:34:09 -0400 (EDT)
I hope this is a suitable forum in which to raise this issue.
Summary: It seems to me that gtk-2.0/pango has some serious problems
with font handling that I have not seen addressed, and I'd very much
appreciate a response, whether it's "What are you talking about,
you've missed something obvious", or "It's on somebody's TODO list,
but not very high up", or "Hmm, nobody's noticed that before", or
whatever.
Preface: I'm strictly an app-developer, or in other words I've
contributed nothing to GTK itself and I'm greatly in debt to the GTK
developers. GTK rocks, and if it were not for GTK my app(s) would not
have developed very far, since I'm not about to program in raw Xlib,
raw win32, Qt, Motif, VB or similar.
I understand that there are some ambitious new things going on in
respect of fonts in gtk-2.0/pango (anti-aliasing, full
internationalization), and that's great. However, I'm concerned that
in the course of the changes from GTK 1.2 some rather basic things
have been inadvertently broken.
My primary concern is with font metrics, and with the related issue of
the distinction between monospaced and proportional fonts.
My first observation is that the handling of font metrics seems to be
broken in gtk-2.0/pango. I base this on two sorts of experiment.
(1) The pango font metrics apparatus fails to return correct metrics
for a known monospaced font (e.g. Lucida Typewriter). The only
function for getting the width of a character directly (i.e. short of
creating a pango layout and measuring its size in pixels) is the
"approximate" char_width function. In the Lucida Typewriter case,
where no "approximation" is called for since every glyph has the exact
same width, the value returned is out by 14 percent (8 instead of the
correct 7 pixel width on my system). This is just not good enough,
for purposes such as sizing windows that are to hold a given length of
line in monospaced characters. It is a marked regression from the old
GdkFont mechanism, which gave accurate metrics with a single function
call.
(2) GTK 2.0 seems to have trouble choosing a suitable default font for
menus, labels and so on. I have tried GTK 2.0 on three systems, and
on two out of three the default font has been unacceptable. On a
linux box running X at 800x600 resolution the default font was tiny
and unreadable. I was able to correct this by forcing the font to
"Sans 12" in ~/.gtkrc-2.0. On a Windows 98 box running at 1024x768
the default font was much too big and clunky. On another Linux box
running at 1024x768 the default was fine. But my point is that gtk
1.2 produced a consistent look on all three systems without any need
to fiddle with rc files. GTK 2.0 doesn't seem to understand the
relationship between font size and screen resolution / dpi.
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.
Third observation: I'm on less sure ground here -- I may have missed
something in the API -- but in the course of experimenting with fonts
I've tried adding a font selection dialog hooked up to a call to
gtk_widget_modify_font() on the main application window. I can verify
that the selection is working, in the sense that the chosen font is
correctly recorded in the application's config file (and correctly
printed to stdout in real time), but the gtk_widget_modify_font() call
accomplishes nothing: the font remains unchanged. (It is changeable
via a modification to ~/.gtkrc-2.0 and a restart of the app.)
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]