Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
X GUI Graphics Software

Figuring Out the Font System on Linux Desktops? 51

koreth asks: "Last year I switched to Debian sarge on my office desktop machine. For the most part it's been great, but I can't seem to wrap my brain around fonts. For example, my favorite programming font is Sheldon Narrow. After running it through a few conversion tools and copying it to various font directories, I was able to start using it in xterm. But no sign of it in Konsole, despite running it through KDE's font installer tool. A few times I've installed new fonts that appear in the font lists of GNOME apps but not KDE apps or vice versa, and it's unclear to me how either environment's fonts interact with what I see when I run 'xlsfonts'. I have yet to find any documentation describing how either GNOME or KDE decides which fonts it likes. And then there's Debian's 'defoma', which seems to interact with everything somehow. Are there any good resources out there for learning what's going on under the hood of a modern Linux desktop environment's font subsystem?"
This discussion has been archived. No new comments can be posted.

Figuring Out the Font System on Linux Desktops?

Comments Filter:
  • Its easy. (Score:5, Insightful)

    by Jukashi ( 240273 ) on Wednesday May 18, 2005 @06:19PM (#12571578) Homepage Journal
    Head - meet Wall
  • So I really can't help you. I like to worry about one thing at a time. When I first started using linux as a desktop machine in 1999, I worried about copy and paste. Fast forward 6 years, and I am still worrying about it.
  • by Dirus ( 592987 ) on Wednesday May 18, 2005 @06:38PM (#12571782)
    The Linux Documentation Project [] is a good place to start. Here is an article [] about the optimal use of fonts. It has a section called "Why Fonts on Linux Aren't Straight Forward?" [] and a section called "The Easy Steps to Enlighten Your Desktop" [] with KDE, Gnome,, and FireFox configuration examples.
  • by linguae ( 763922 ) on Wednesday May 18, 2005 @06:47PM (#12571856)

    One of the things that helped me install fonts is this paper []. Yes, it's from the FreeBSD handbook, but nearly all of it deals with just X11 and not FreeBSD-specific.

    A few little tips; you might want to install the Microsoft web fonts (they're free as in beer and pretty nice) as well as the Bitstream Vera fonts. If you have a Windows box, you can copy those fonts, put them on your *nix box, and update the fonts database by typing ttmkfdir > fonts.dir where the TrueType fonts are stored.

    Pretty much, my experience with fonts have been, for the most part, pretty good. I'm using FreeBSD with Window Maker, so no, I don't have all of the nice KDE/GNOME bells and whistles, so my fonts might not look as good. However, it is a great idea to get a nice understanding of how fonts work under X11. You never know when you need it....

    As for the Sheldon font, X11 comes with a program called xfontsel. (Yes, it's ugly and it comes from the bad old days of X, and its description of fonts is a stark departure from Windows/Mac, but it does the job). Anyways, look under the fmly menu and see if your font is located there.

    • You mean the one that tells me to go download the updated, converted version of ProFont and install it? Great advice, or it would be if ProFont were the font I wanted to install, which it isn't. Sadly, there is no such modified version of the Sheldon font I prefer, so that thread (which I'd already read, thanks) is of no use to me other than mentioning that there's "some kind of encoding messup."

      And in any event even if there were a version of the right font, that wouldn't help me know what to do the next

  • by reynaert ( 264437 ) on Wednesday May 18, 2005 @07:20PM (#12572186)
    There basically two font subsystems on X, the old X core fonts and the new fontconfig.

    X core fonts are the old standard X11 stuff, with FonthPaths, fonts.dir and fonts.scale files, and lots of other nastiness. It has trouble with scalable fonts, it can't deal at all with complex scripts (such as Syriac or Indic scripts), and it can't do anti-aliasing or sub-pixel rendering ("ClearType"). Also it's completely useless if you want to print something.

    The new way, with fontconfig, is completely seperate (and in fact independent from X) and basically fixes all these flaws (but it introduces the nastiness of XML config files). By now the only interesting application that hasn't been converted yet is Emacs.

    (I say "with fontconfig", but it actually consists of three parts: fontconfig, which keeps a database of fonts; freetype, which renders them; and xft, which connects it all with X.)

    Now defoma. Defoma is something Debian specific. It's used by Debian font packages to register themselves with every font-using thing installed. As you look at the list of limitations of X core fonts, you can imagine quite a lot of programs have grown their own font systems. I don't think anybody really understands how defoma works, and you can safely ignore it.

    To get a bit more concrete: you have successfully configured the X core fonts system to use your font, and discoverd pretty much nothing uses it anymore :)

    To install a font, the modern Linux way, drop it in the ~/.fonts directory (create the directory if it doesn't exist yet). Or, alternatively, add the directory where you put the font to /etc/fonts/local.xml.

    BTW, I think Windows .fon files are supported, so you don't even need to convert them.
    • by koreth ( 409849 ) on Wednesday May 18, 2005 @09:07PM (#12573067)
      Thanks for the informative message! That helps clarify things. Putting fonts in my ~/.fonts directory does seem like it works more often than not, but not 100% of the time. The example I linked to in the article is one of the failures. I've put it in my ~/.fonts directory (as well as in a couple of system fonts directories listed in the /etc/fonts config files) in PCF and BDF and FON formats and nothing seems to notice it. If it weren't for the fact that it works in xterm I would have just assumed the font file was corrupt in some way. (Which maybe it is, in some way that xterm doesn't mind.)

      My reason for posting the article is less about getting this particular font installed than about understanding why it's not working, of course. Are you aware of any diagnostics I can look at that might shed light on the matter?

      • by reynaert ( 264437 ) on Thursday May 19, 2005 @01:19AM (#12574716)
        Heh, I completely forgot about your font :)

        Fontconfig recognized the sheldon4.fon file, but when I tried to use the font, it just showed blank space -- no letters, not even substitutions from another font. I tried to convert it using FontForge and produced a variety of non-working versions. Eventually I found the key is to change the encoding in the Font Info dialog to Unicode, with that I created this working version []. (This is the first time I've used FontForge, so I might have been doing stupid things.)

        I guess this mess shows people just don't care for bitmap fonts anymore :) BDF/PCF is pretty much deprecated and it's not really a surprise Windows-specific formats like .FON are poorly supported. (Bitmap-only TrueType fonts should still work fine, however.)

        As for diagnostics, the only thing I know about is fc-list, which is fontconfig's version of xlsfonts. You could try asking the fontconfig mailing list [], it seems to be the most likely place to reach people who know more.

      • xlsfonts will list fonts available under the old X11 fonts system, and fc-list will list fonts available to Fontconfig.

        xfontsel also has a fontconfig equivalent: gtk2fontsel [].
    • I'd rather have XML config files...

      The worst part of Linux, in my view, is that there are so many different formats of configuration files. Just figuring out what the comment delimiters are is crazy! nevermind knowing if the file has .cfg, .conf, .config, .configure, or no special name designation

      hosts/xorg.conf/inetd.conf uses # for comments

      my fstab currently has no comments; don't know if they are allowed; and appears to be whitespace delimited.

      passwd/groups uses ':' as a delimiter

      named.conf uses wha
      • A diverse set of XML-ified configuration files could be more complicated than the current text file soup in /etc.

        XML configuration files would end up with very handy binary objects, and references to other parts of the XML file or other XML files, and other monstrosities yet to be conceived.

        And it is quite likely that the validity of many of the new XML configuration files could not be checked anyway. As an example, Ant [], touted as more sensical than make, uses a XML configuration file that cant be va []
        • Then check don't out []
          it's basicly the monstrosities you are talking about. (as-in-changing every file in /etc to an XML database format)
          • Elektra is trying to put each configuration value into a sepearte file, named by the key, which is the correct way to use a file system. Unfortunatley both Unix/Linux and Windows have file systems designed to assumme that the average file is much larger than 1K, this is the real reason that this was not done and we have monstrosities like the registry, gconf, and the larger /etc files. The ReiserFS attempts to address this by being designed to support very small files efficiently.

            Elektra is still screwed u
      • Actually, # is a pretty safe bet for comments in most Linux config files, including fstab. It's a legacy of unix, so the advantage is that unix hackers can get up to speed on Linux pretty quickly. There are lots of newer programs that use XML for their config files; OpenOffice and Gaim come to mind. The world is moving in that direction, but rather slowly.

        But contrast all this with what you have to put up with in Windows: the registry. While it's nice to have all configuration centralized (officially
  • by trevorcor ( 177535 ) on Wednesday May 18, 2005 @07:59PM (#12572469)

    dpkg-reconfigure fontconfig, and choose "yes" when asked about bitmapped fonts.

    It's a good idea to install the x-ttcidfont.conf (or whatever it's called) package and follow the directions in /usr/share/doc/x-ttcidfont-conf/README.Debian.

    Other than that, I recommend you don't try to understand the font mechanisms, but just try to forget they're there; it's easier that way.

  • Dots Per Inch... (Score:5, Informative)

    by netsharc ( 195805 ) on Wednesday May 18, 2005 @08:37PM (#12572814)
    Another problem I've noticed, the font size can suddenly change depending what window manager - KDE vs Gnome I was using. When I start a KDE program in Gnome, the fonts would get bigger. Looking at the Control Center, it still says 10 points, but the problem was Gnome and KDE had differing DPI settings. One way to fix this is to specify
    DisplaySize 400 300
    in the monitor section of xorg.conf so that the DPI can be properly determined. The sizes (in millimeters) doesn't have to be your monitor size, I preferred to have a round, square DPI number (96x96 DPI) than an actual calculation of how many DPI my monitor really has, because I think the font server does some funny calculation using them, and it'll probably be distorting if they're not square (though I'm not really sure).

    For a resolution of 1280x960, aiming for 96 DPI gets you 25.4*1280/96 = 339 mm and 25.4*960/96 = 254 mm (gee, that was a hard equation! :p), which are pretty close numbers to the real screen size of monitor advertised as 19".

    To see your current DPI settings, open an xterm and type "xdpyinfo|grep inch" (or is it "Inch"?)
    • Hey, thanks...!

      But I don't understand why this is supposed to help. If Gnome/KDE gets screenDPI from the X-server, why would they ever be different? It shouldn't matter whether X reads it from EDID from the monitor, or get the value from a configuration file, or whatever. They should always be either both wrong or both correct. There should never be any inconsistency.

      So which one is broken, in this case? Gnome? KDE? Or both?

    • Yes, setting your DisplaySize in xorg.conf is very important, but it seems like most people don't even know it exists. Not only does it help KDE/GNOME set their font sizes, it's used by GIMP for graphics and WINE for Windows fonts.

      I have a 15" flat panel on my laptop, which works out to be 12"x9". With my current resolution of 1600x1200, that gives a DPI of 133x133. I use the following line in my xorg.conf (you need to convert to millimeters):

      DisplaySize 304.8 228.6

    • Unfortunatly X (and Windows, which has the same problem) was designed by morons. They thought it was extremely important that font sizes be resolution-independent, measured in "points", yet all other graphics are measured in pixels. The end result is that the display is fucked up if the DPI is set differently than what the programmers expect, since they are drawing everything with what are effectively two different coordinate systems, but it is almost impossible to correctly plan for arbitrary scale changes
      • by thedave ( 79572 )

        I recommend that X do the exact same thing. The X server should act like DPI is 96 at all times. It would also help if the interfaces to select fonts by pixel size were not treated like second-class citizens.

        That would be an extraordinary step backwards!

        Correct pixel density is essential for almost everyone trying to do serious graphics or publishing work.

        Setting the pixel density correctly allows you to render things on-screen at the exact same size and proportioons as the printed work. This is cru

        • This has nothing to do with making resolution-independent graphics.

          Right now, I can draw a 1-inch square by querying the DPI and using that number to draw the square.

          What I want is the *same* mechanism for drawing fonts. Using a totally different coordinate system for font sizes from all the other graphics is insane.

          Unfortunatly due to the broken design and all the programs that are using it incorrectly, the only fix I can see is to make the existing API return 96 DPI always. There is no way to get all t
  • There's nothing going on under the hood. Or, there's everything. It's not likely anyone will ever figure it out, because it's a freaking MESS.
  • Like the above poster mentioned, this is the easiest way to add custom fonts to most modern linux systems.

    BTW, thanks for the link. I didn't see a link for Sheldon in TTF format, but ProFont looks quite nice in my Gnome Terminal!

  • Xorg's documentation (Score:4, Informative)

    by Wolfbone ( 668810 ) on Wednesday May 18, 2005 @11:14PM (#12573918)
    This may be of some use: ml []

    These may help with your next question ;-) [] []
  • I have toyed with an idea of a story, which starts from a keypress, goes on to keyboard driver, Unix tty subsystem and character coding. One story line branches to the handling of characters in the console subsystem and its fonts (in ROM or somewhere else?). The frame buffer and a graphical console are another avenue that needs to be handled. Finally the glorious or ("goreous") story line branches to X client, X primitives, X server, X character coding, X font files, X rendering, X color maps and resolution
    • by Anonymous Coward
      I recommend you read the Unix Haters Handbook. It partly explains the mess that you seem to be curious about.

      Read the chapters "Terminal Insanity" and "The X-Windows Disaster", although they doesn't really discuss fonts much, they give some insight into the *cough* design *cough* of Unix, and hopefully make you give up on your story idea like it did to me.

  • Just put your new fonts to ~/.fonts directory.
  • Answer: Use KDE (Score:4, Informative)

    by metamatic ( 202216 ) on Thursday May 19, 2005 @03:36PM (#12581730) Homepage Journal
    Use KDE's font installer to install and manage fonts, it just works. Handles TrueType and Type 1 fonts, just drag and drop to install.

    There's TeX and LaTeX and METAFONT... but for those, I suggest you use pdftex and pdflatex and use Type 1 fonts, rather than going through the whole "building multiple sizes of METAFONT-rendered bitmaps" thing. Ideally, use the native PDF fonts to keep your PDFs down in size.

    There are also various old bitmap X fonts hanging around on my system. I don't deliberately use any of them, but I leave 'em there in case there are applications I need that don't handle scaleable TTF/Type1 yet.
    • But no sign of it in Konsole, despite running it through KDE's font installer tool.

      ...taken from the question.

      If this is KDE's font installer "just working" as you say it does, I would hate to see it not working...

      • That font he was talking about was some crappy bitmap font, not a proper Type 1 or TrueType font. I wouldn't Windows bitmap fonts to work, and frankly I don't care...

        KDE works for Type 1 and TrueType. That's good enough for me.
    • KDE does not "just work" as you say. I've spent some time with current Suse and Mandrake distros and given up after being unable to get fonts properly recognized.

      One big problem is that KDE's font manager (whatever it's called) doesn't recognize font families and font relationships properly. So if I installed something with book, medium, bold, extra bold, italic, and so on, only one of those fonts (at random) would usually show up in an application. Gee, it's really great to be limited to the bold italic o
      • KDE "just works" for outline fonts in as much as Linux can be said to work with outline fonts. The brokenness you cite is brokenness of Linux, not KDE.

        I should also mention that Mandrake has a rather flaky KDE, in my experience. The menu editor in Mandrake 10 doesn't work reliably either. It works fine on Debian, however.

        And it's not like my Mac always deals with font families properly either...

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann