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

February 12, 2012

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.

Written on 12 February 2012.
« Understanding FVWM States, with better FVWM code for selecting terminal windows
The problem with long-term production support of things »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Feb 12 23:48:07 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.