Wandering Thoughts archives

Some things about changing from old X fonts to modern TrueType fonts

Now that I've transitioned to using modern fonts in xterm, I've 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 'Sans:Bold:pixelsize=17'. This 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 visibly 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 commentary. 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 state number).

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 'State 2' 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.)