Some things about changing from old X fonts to modern TrueType fonts
Now that I've transitioned to using modern fonts in
decided to move into the 00s by changing to a UTF-8 based text encoding
(I've considered this some time, but only
once I had more or less Unicode-enabled fonts did it become actively
tempting). Making this shift provoked a small pile of complaints from
FVWM about my bitmap fonts not having all of the font charsets that
a true Unicode environment wants, which caused me to start switching
various other fonts to modern TrueType fonts.
One of my challenges in doing this was matching the size of my new fonts to the size of my old fonts, since I didn't want to significantly change the size of things in my desktop environment; shuffling fonts is bad enough without shuffling layouts as well. Fortunately there turns out to be a relatively easy trick for this that mostly works.
There are two ways to specify the sizes of old-style X fonts; you can
use either actual pixel size or a point size (or both at once, if you're
so inclined). If you only have the point size, you need to determine
the pixel size. The easy way to do this is to fire up
xfontsel like so:
xfontsel -pattern "-adobe-helvetica-bold-r-normal--*-120-100-100-*-*-*-*"
Now find the
pxlsz dropdown, and it should normally have exactly one
pixel size (in this case, 17 pixels).
Once you have the pixel size you can simply directly specify this in
an XFT font specification such as '
will give you a font that is either exactly or almost exactly the same
vertical size as your previous old X font. I don't know if there's a
magic XFT way to work out the correct (point) size that corresponds to a
specific pixel size; so far I haven't worried about it.
(The font rendition may not be the same, of course; in my case I found that I needed 'Condensed Bold' instead of plain 'Bold' in order to match reasonably well. You're going to have to experiment.)
The other thing I found out after some experimentation is that modern
TrueType fonts are not as good at small pixel sizes as the old X bitmap
fonts. After playing around with it I've stuck with my old X fonts for
small sized things (an example is the places where I'm using the classic
8x13), complaints from FVWM and all.
(It's possible that someday we'll have modern TrueType fonts that are very well hinted for such small sizes, but they don't seem to be there today. It's not glaringly bad by comparison, but my FvwmIconMan definitely felt less readable and clear when I was trying out 'Mono:pixelsize=13'.)
Sidebar: Xt and bad font rendering in UTF-8
One of the things that happens in some Xt-based applications, most
xclock, is that if you use a UTF-8 based text encoding things
suddenly insist on doubling the vertical space they use for rendering
each line of text. I don't know why they do this, but so far my only
solution is to turn off
LC_CTYPE when I start those applications
so that they revert to the default C locale.
Understanding FVWM States, with better FVWM code for selecting terminal windows
Every so often I make an epic mistake, where I drastically misunderstand something. A discussion with one of the people behind FVWM in response to yesterday's entry on selecting terminal windows from the keyboard revealed that I had made one of them about an FVWM feature called (window) 'States'; a correct understanding of the feature leads to a better version of the FVWM code from my last entry.
What FVWM States are is effectively user-controlled tags for windows, given numbers from 0 through 31 instead of (say) text labels. Crucially, States are completely independent from each other; a given window can be in multiple States at once, and individual States are manipulated independently. Windows default to having all States turned off but can have this changed by FVWM Style commands or on the fly. States can be used for at least two separate things. The first is to keep track of actual window states, such as whether or not a window has ever been iconified; the second is to aggregate windows together into some sort of abstract category such as 'all terminal windows'.
(My mistake was thinking that a window could only be in one State at a time, which meant that using States to identify terminal windows would preclude using States for anything else involving them, more or less. This is wrong.)
The second sort of use of States is the interesting one for what I
was doing in yesterday's entry, so here's revised FVWM code with
First, we mark all windows we consider 'terminal windows' with a
specific State through a
Style command. I've picked State 2 here, but
the choice is arbitrary (provided that you aren't already using the
Style "XTerm" State 2 Style "9term" State 2 Style "Gnome-terminal" State 2
Any time your FVWM configuration wants to specify 'this applies to
terminal windows' it can now simply use '
State 2' as the matching
condition. Specifically we can do this in my ToWindow function:
AddToFunc ToWindow + I Current (State 2, "$0") Break + I Next (State 2, "$0") ToWindow2 AddToFunc ToWindow2 + I Iconify False + I Focus + I Raise + I WarpToWindow 80 20
Using a State to identify terminal windows has the great advantage that
if you start using another form of terminal window, such as Konsole,
you don't have to go through your FVWM configuration to add additional
|Konsole' matching conditions to everything; you just add a single
Style declaration to identify Konsole as a terminal.
Style "Konsole" State 2
(If you actually want all terminal windows to have the same window
manager decorations and so on, you can do even better than this. FVWM
allows for abstract styles, so you can create a 'terminal' style that
decorates the window appropriately and also includes the '
setting, then simply say '
Style "Konsole" UseStyle terminal'.)
(I'd like to thank Thomas Adam for taking the time to patiently get enlightenment into my head.)