Shallow Thoughts

Two font mysteries solved

This has been a good week for fonts: two longstanding mysteries solved.

The first concerns the bitstream vera sans mono I've been using as a terminal font in apps like rxvt and xterm. I'd been specifying it in ~/.Xdefaults like this:
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso10646-1

The mystery is that I'd noticed that in xterm, the font looked slightly different -- slightly uglier -- than in rxvt (both apps use the same X class name of XTerm). It was hard to put my finger on what was different -- the shape of all the letters looked the same, but it just seemed a little more ragged, and a little less compact, in xterm. I figured it was just a minor difference in their drawing code, or something.

Well, I was fiddling with fonts (trying to get the new-to-me "Inconsolata" font working) and I noticed that iso10646 bit. I didn't know what 10646 was, but shouldn't it be 8859-1 or 8859-15, the codes for the Latin-1 alphabet? After finishing up my Inconsolata experiments, when I set the font back to Vera I changed the line to XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso8859-15 and moved on to other things.

Until the next morning, when I booted up to a surprise: my main terminal window no longer fit on the screen. It seems it had reverted to the other (uglier) version of Vera Sans Mono, which is also very slightly taller, so instead of being a couple of lines shorter than the screen height, it was a couple of lines too tall to fit.

I checked .Xdefaults -- yes, it was still Vera. What was going on? I finally remembered the one thing I had changed: the language setting on the font, from 10646-1 to 8858-15. I changed it back: sure enough, now the font was pretty again and the terminal was short enough to fit.

I fired up xfontsel and did some experimenting. It turned out the difference between the two almost-identical Vera sans mono bold roman fonts is a field xfontsel calls "spc". It can be either 'c' or 'm'. The 'c' version is the pretty, compact font; the 'm' is the uglier, taller one. For some reason, specifying 10646-1 makes "spc" default to 'c', while 8859-15 makes it default to 'm'. But specifying 'c' in the font specifier gets the good version regardless of which language is specified.

So this would work: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-*-*

But then I read up on 10646-1 and it turns out to mean "the whole unicode character set". That sounds like a good idea, so I kept it in my font specifier after all: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-iso10646-1

(For the moment I still didn't know what spc, c or n meant; read on if you're curious.)

The second insight concerned a longstanding mystery of Dave's. He has been complaining for quite a while about the way Ubuntu's modern pango-based apps all refuse to see bitmapped fonts. (It bothered me too, but less so, because the terminal and editor apps I use can see X fonts.)

Dave has an Ubuntu install on one machine that he's been upgrading release after release, which does see his bitmapped fonts. But any fresh Ubuntu installation fails to see the fonts. What was the difference?

We knew about the trick of going into /etc/fonts/conf.d, removing the symbolic link 70-yes-bitmaps.conf and replacing it with a link to /etc/fonts/conf.avail/70-yes-bitmaps.conf ... But doing that doesn't actually change anything, and bitmap fonts still don't show up.

The secret turned out to be that you need to run fc-cache -fv after changing the font/conf.d links. This apparently never happens on its own -- not on a reboot, not on installing or uninstalling font packages. Somehow it had happened once on Dave's good install, and that's why it worked there but nowhere else.

I'm not sure how anyone is supposed to find out about fc-cache -- there's no man fontconfig, and the /etc/fonts/conf.avail/README offers no clue, just misleadingly says "Fontconfig scans this directory". man fc-cache mentions /usr/share/doc/fontconfig/fontconfig-user.html, which doesn't exist; it turns out on Ubuntu it's actually /usr/share/doc/fontconfig-config/fontconfig-user.html. But wait, that's just an html-ized manual page for fonts-conf, so actually you could just run man fonts-conf ... your guess is as good as mine why the fc-cache man page sends you on a hunt for html files instead.

man fonts-conf is good reading -- it even solves the mystery of that spc parameter. It stands for spacing and can be proportional, dual-width, monospace or charcell. Aha! And there's lots more useful-looking information in that manual page as well.

Tags: linux, fonts, i18n
[ 14:58 May 02, 2008    More linux | permalink to this entry ]

Ubuntu "Hardy Heron"

On a lunchtime bird walk on Monday I saw one blue heron and at least five green herons (very unusuual to see so many of those). Maybe that helped prepare me for installing the latest Ubuntu beta, "Hardy Heron", Monday afternoon.

I was trying the beta primarily in the hope that it would fix a serious video out regression that appeared in Gutsy (the current Ubuntu) in January. My beloved old Vaio SR17 laptop can't switch video signals on the fly like some laptops can; I've always needed to boot it with an external monitor or projector connected. But as long as it saw a monitor at boot time, it would remember that state through many suspend cycles, so I could come out of suspend, plug in to a projector and be ready to go. But beginning some time in late January, somehow Gutsy started doing something that turned off the video signal when suspending. To talk to a projector, I could reboot with the projector connected (I hate making an audience watch that! and besides, it takes away the magic). I also discovered that switching to one of the alternate consoles, then back (ctl-alt-F2 ctl-alt-F7) got a signal going out on the video port -- but I found out the hard way, in front of an audience, that it was only a 640x480 signal, not the 1024x768 signal I expected. Not pretty! I could either go back to Feisty ... or try upgrading to Hardy.

I've already written about the handy debootstrap lightweight install process I used. (I did try the official Hardy "alternate installer" disk first, but after finishing package installation it got into a spin lock trying to configure kernel modules, so I had to pull the plug and try another approach.)

This left me with a system that was very minimal indeed, so I spent the next few hours installing packages, starting with tcsh, vim (Ubuntu's minimal install has something called vim, but it's not actually vim so you tend to get lots of errors about parsing your .vimrc until you install the real vim), acpi and acpi-support (for suspending), and the window system: xorg and friends. To get xorg, I started with:

apt-get install xserver-xorg-video-savage xbase-clients openbox xloadimage xterm

Then there was the usual exercise of aptitude search font and installing everything on that list that seemed relevant to European languages (I don't really need to scroll through dozens of Tamil, Thai, Devanagari and Bangla fonts every time I'm looking for a fancy cursive in GIMP).

But I hit a problem with that pretty early on: turns out most of the fonts I installed weren't actually showing up in xlsfonts, xfontsel, gtkfontsel, or, most important, the little xlib program I'm using for a talk I need to give in a couple weeks. I filed it as bug 212669, but kept working on it, and when a clever person on #ubuntu+1 ("redwhitewaldo") suggested I take a look at the x-ttcidfont-conf README, that gave me enough clue to get me the rest of the way. Turns out there's a Debian bug with the solution, and the workaround is easy until the Ubuntu folks pick up the update.

I hit a few other problems, like the PCMCIA/udev problem I've described elsewhere ... but mostly, my debootstrapped Hardy Heron is working quite well.

And in case you're wondering whether Hardy fixed the video signal problem, I'm happy to say it does. Video out is working just fine.

Tags: linux, ubuntu, install, fonts, vaio
[ 18:31 Apr 07, 2008    More linux/install | permalink to this entry ]

New Debian Font Weirdness

A recent change to the Debian font system has caused some odd font problems which Debian users might do well to know about.

The change has to do with the addition in /etc/fonts of a directory conf.d containing symbolic links to scripts, and the overwriting of some of the existing files in /etc/fonts.

The symptoms are varied and peculiar. On my sid system, on each boot, the system would toggle between two different font resolutions. I'd start xchat, and the fonts would be too teeny to read; so I'd call up the preferences dialog, see the font was at 9, and increase it to 12, at which point I'd see the font I was used to seeing (though the UI font in the tabs would still be teeny). Subsequent runs of xchat would be fine (except for the still-teeny tab fonts). But upon reboot, xchat would come up with the tab font correct and the channel font HUGE. Prefs dialog again: it's still at 12 where I set it last time, so now I reset it to 9, which makes it the right size. Until the next reboot, when everything became teeny again and I have to go back to 12.

The system resolution never changed, nor did the rendering of the bitmapped fonts I use in emacs and terminal clients; only the rendering of freetype scalable fonts changed with each reboot. Back in the days when all fonts were bitmapped, I would have guessed that the font system was alternating between 100dpi fonts and 72dpi fonts.

At a loss as to what might cause this strange behavior, I took a peek into /etc/fonts/conf.d, which Dave had discovered a few weeks ago when he updated his sarge system and all his bitmapped fonts disappeared. Though my problem didn't sound remotely similar to his: my bitmapped fonts were fine, it was the scalable ones which were flaky.

Turns out the symlink I'd aquired in the update, /etc/fonts/conf.d/30-debconf-no-bitmaps.conf, did indeed point to a file called no-bitmaps.conf, just as Dave's had. Just to see what would happen, I removed it, and made a new symlink, 30-debconf-yes-bitmaps.conf, pointing to yes-bitmaps.conf.

Voila! The size-toggling problem disappeared, and, even better, bitmapped fonts like "clean" now show up in gtkfontsel and in gtk font selection dialogs, which they never did before. I can use all my fonts now!

The moral is: if you've updated sarge or sid recently, and see any weirdness at all in fonts, go to /etc/fonts/conf.d and fiddle with the symlinks. Even if it doesn't seem directly related to your problem.

As to why no-bitmaps.conf causes the system to toggle between two different font scalings, that's still a mystery. The only difference between no-bitmaps.conf and yes-bitmaps.conf is that one rejects, and the other accepts, fonts that have "scalable" set to false. Why that would change the scale at which fonts are rendered is beyond me. I'll leave that up to someone who understands the new debian font system. If any such person exists.

Update 5/24/2005: turns out you can change this on a per-user basis too, with ~/.fonts.conf. man fonts.conf for details.

Tags: linux, debian, fonts
[ 21:45 Apr 12, 2005    More linux | permalink to this entry ]

Web pages with ugly fonts: Mozilla thinks they're Russian

For years I've been plagued by having web pages occasionally display in a really ugly font that looks like some kind of ancient OCR font blockily scaled up from a bitmap font.

For instance, look at West Valley College page, or this news page.

I finally discovered today that pages look like this because Mozilla thinks they're in Cyrillic! In the case of West Valley, their server is saying in the http headers:

Content-Type: text/html; charset=WINDOWS-1251

-- WINDOWS-1251 is Cyrillic -- but the page itself specifies a Western character set:

<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">

On my system, Mozilla believes the server instead of the page, and chooses a Cyrillic font to display the page in. Unfortunately, the Cyrillic font it chooses is extremely bad -- I have good ones installed, and I can't figure out where this bad one is coming from, or I'd terminate it with extreme prejudice. It's not even readable for pages that really are Cyrillic.

The easy solution for a single page is to use Mozilla's View menu: View->Character Encoding->Western (ISO-8851-1). Unfortunately, that has to be done again for each new link I click on the site; there seems to be no way to say "Ignore this server's bogus charset claims".

The harder way: I sent mail to the contact address on the server page, and filed bug 278326 on Mozilla's ignoring the page's meta tag (which you'd think would override the server's default), but it was closed with the claim that the standard requires that Mozilla give precedence to the server. (I wonder what IE does?)

At least that finally inspired me to install Mozilla 1.8a6, which I'd downloaded a few days ago but hadn't installed yet, to verify that it saw the same charset. It did, but almost immediately I hit a worse bug: now mozilla -remote always opens a new window, even if new-tab or no directive at all is specified. The release notes have nothing matching "remote, but someone had already filed bug 276808.

Tags: tech, web, fonts, linux
[ 19:15 Jan 13, 2005    More tech/web | permalink to this entry ]

Why do packages install yucky fonts?

This evening, thanks to Rob Weir's Debian Font Guide and some suggestions from Rob himself, I finally got rid of that ugly oversized scaled-bitmap helvetica (or similar) font that has plagued all my Debian installs since I first started using Debian. It turns out that it comes from the gsfonts-x11 (ghostscript and gv). Remove gsfonts-x11, and gtk windows now use a much much smaller, clean, truetype helvetica font. Alternately, keeping gsfonts-x11 installed, but removing /usr/lib/X11/fonts/Type1 from the font path, gives me a medium sized, cleanly rendered helvetica in gtk windows. I may have trouble viewing postscript documents in gv; we'll see. But having all my other windows use clean fonts makes it worth risking some gv breakage.

Other things I had to do: install x-ttcidfont-conf (defoma was already installed); disable the font server (comment out the unix/:7100 line from XF86Config-4, plus update-rc.d -f xfs remove); reorder the FontPath lines in XF86Config-4 as suggested in the font guide, and remove (comment out) the /var/lib/defoma/x-ttcidfont-conf.d/dirs/CID line.

Strangely, even if I list the Type1 directory after all the others in XF86Config-4, it still takes precedence over all the other helveticas. Neither Rob nor I could figure out why.

Why do packages include fonts like that? Abiword used to have a font like that on Redhat. It's almost always for helvetica (which has a gazillion other implementations anyway, so it's not as though they have to worry that they won't be able to find a helvetica on the system if they don't install theirs).

Tags: linux, fonts
[ 18:00 Jul 09, 2004    More linux | permalink to this entry ]