Bitmap fonts (PCF/BDF) support with Pango - Desktop Customization & Workflow

Users browsing this thread: 1 Guest(s)
Hello nixers,
This is a tutorial thread on how to convert your bitmap fonts, be it PCF, BDF, and others to a format supported by Pango.

What we need to do is to put the bitmap inside a container format that Pango/Harfbuzz loader supports, namely SFNT, which is the format of both TTF, OTF, and other fonts.

First of all, go to your fontconfig conf directory, usually /etc/fonts/conf.d and make sure that the file filter 70-no-bitmaps.conf is not there. If it is, remove the symbolic link, and replace it with a symbolic link to ../conf.avail/70-yes-bitmaps.conf.
If you are so inclined also symlink 10-scale-bitmap-fonts.conf.

The next step consists of converting the bitmap font to OTB/SFNT.

If you have a PCF you can use the tool pcf2bdf to convert it to BDF, which is more workable.

After that there are multiple possibilities, either rely on fontconfig scripting to do the work, with a script similar to this:

while ( i<$argc )
    Generate($argv[i]:r + ".otb")
    i = i+1

Or convert the bitmap font to an outline using this script, but it doesn't give crisp results.

Or you can clone the latest version of fonttosfnt, which can be used as follows:

fonttosfnt -b -c -g 2 -m 2 -o lime.otb lime.pcf

Adjust the options as you see fit but when not adding scalability the font might not work with some programs.

Build fonttosfnt using:
autoreconf -v --install
configure should warn you of any missing dependencies such as libfreetype2 and libfontenc.

After that, you can either install the font locally in $HOME/.local/share/fonts/ or globally in /usr/share/fonts/.

Be sure to refresh your fontconfig cache: fc-cache
And test using
> fc-query lime.otb  | grep 'family: '
        family: "lime"(s)
> fc-match 'lime'
lime.otb: "lime" "Regular"
> fc-list | grep 'lime'
/home/user/.local/share/fonts/lime.otb: lime lime:style=Regular

I hope this help!
Long time nixers
I’m still getting spacing issues when bitmap fonts are embedded in OTB. I’m seeing this with qsqs, but also with popular fonts like Terminus.

Pango applications get it right: My 7x15 really is 7 pixels wide. But “older” applications, which use Xft directly, produce glyphs that are 8 pixels wide. One too many. Sadly, as soon as an OTB file is installed, it will be picked up by Xft applications, too, even though they could still handle BDF/PCF (as of September 2020).

I still haven’t figured out what exactly goes wrong. For the moment, a workaround is to fake the font’s width:

%.otb: %.bdf
    sed 's/^DWIDTH 7/DWIDTH 6/' < $< > temp.bdf
    fontforge -c 'open(argv[1]).generate(argv[2])' temp.bdf $@
    rm temp.bdf

This reduces the “device width” (i.e., pixels) from 7 to 6 for my font. It does not touch the “scalable width” (i.e., points). Pango appears to be using only SWIDTH and Xft uses only DWIDTH? I’m not sure. Either way, the same font file now shows up correctly in both GTK/Pango and Xft.

I hope to find a proper solution for this one day …
Long time nixers
(23-09-2020, 10:40 AM)movq Wrote: I hope to find a proper solution for this one day …

I have. Sort of. Actually, it’s worse now. Kind of.

fontforge introduces a “line gap” of 2 pixels. My BDF files do not have that, at least I don’t understand where it could come from. This line gap didn’t matter in the past, but VTE recently changed something ( and now my 7x15 font gets interpreted as 7x17. Gah.

So what I do now, is use Terminus’ BDF-to-OTB converter, because it appears to be the only one that doesn’t garble up my metrics. Yes, my own font now depends on Terminus. How great is that.

On the plus side, the DWIDTH hack above is no longer required.