Fontconfig Problems and Learning to Use Gtk+

I have been having a problem with fonts and font selection in on my Debian GNU/Linux system. In particular, I am having problems with fontconfig not correctly organizing the fonts into typefaces and styles. Also I have some fonts where I have both Type 1 and TTF files of the font in the fontconfig path and things are getting mightily confused but this is actually just another aspect of the basic naming problem.

The basic naming problem is that fontconfig assumes that the font will present font names, typeface names and style names in a consistent and known way. There seems to be no problem with Type 1 fonts, except occasionally Book is replaced by Regular as the style but this is not really a problem at all. TTF fonts on the other hand seem very problematic. The scheme for naming fonts, typefaces and styles seems either not to exist or to be flouted for some reason. I have no idea if Micro$oft Windows gets round the problem as I do not use that system but fontconfig clearly does not. To investigate this I need a browser of the fonts on my system that can more carefully deconstruct information about and browse fonts.

I have in the past used gfontview. However this has a number of problems: it is a GTK1 application and I am using GTK2 and, more importantly, it only displays fonts for a given directory and does not assemble fonts into typefaces and styles. However, it has many of the features of the sort of display I want. Nautilus of course provides thumbnail previews of fonts and by double clicking gives the individual font viewer. This is nice in many ways but doesn't allow easy browsing since the thumbnails only display Aa and it is directory at a time. OK so it is possible to have multiple Nautilus windows up but you have to specify each and every directory and so you end up with 9 or 10 windows and there isn't enough screen space. Also this does not allow fontconfig driven browsing. There is of course the GTK font selection dialogue. This understands fontconfig but it doesn't give information about the source of the font -- if there was a way of finding the file name for the given style of a give typeface using this dialogue I probably would be using that and not writing this!

So I am looking for a font browser which must:

  • Be able to work by being given a list of directories to show the fonts for or use fontconfig to work with the set of fonts available to GTK applications. So two distinct modes of working.
  • Be a browser of a catalogue of fonts rather than a simple chooser, i.e. I want to be able to see all the fonts all at once -- OK not entirely possible but I do want to be able to make a selection of a set of fonts and see them all displayed together.

Asking around, the two most helpful comments I got were "Its a 20minute hack in PyGTK." and "There are lots of new font browsers being worked on." For all the searching of Google I cannot find mention of any new font browsers but this may just be my bad searching ability. If anyone knows of any work please email me. So it seemed to be time to think about doing it myself. I have masses of other things to do and don't really have the time but it has to be done.

The immediate question then is which language? Well GTK etc. are all C-based systems but C is basically assembler so we don't want to use that. GTKMM gives a binding for C++ so that is one possibility. Python has PyGTK. Ruby has Ruby- Gnome. Java has Java-Gnome. Groovy is also a possibility since it can use Java-Gnome. So I did a little experiment: I wrote a program in each of these languages to put up the GTK font selection dialogue box just to see how painful each of the languages were. The idea being that if the project ended up being half-way useful then it would probably need to be written in C but for prototyping use the easiest language possible. So here are the various versions:

  • C++
  • Python
  • Ruby
  • Java
  • Groovy This is not groovy Groovy. It needs rewriting to use closures but this may entail writing a complete GTK builder like the SwingBuilder and the SWTBuilder.

In many ways they are all much of a muchness. Java, Groovy and Ruby allow signal handlers to be defined at the connection call using either anonymous classes or closures and that is nice. Very nice. C++ and Python are much more mainstream for these sorts of application.

Decisions, decisions. Time for some more dithering.

Copyright © 2005–2020 Russel Winder - Creative Commons License BY-NC-ND 4.0