|
As of the switch over to X.org as GUI server, this information is obsolete. The newer fonts-config system is much better, and it's quite likely you'll be happy with the defaults provided with most newer distributions of Linux. You may apply the fixes below to systems using XFree86 prior to version 4.3. Note updated comments in the text below. |
There's been a lot of kvetching about how recent Linux distros process fonts for display, especially in KDE. In 2002, most distros introduced the strong reliance on the fonts-config system. Whatever their reasons, it works to deny the user some of the system fonts they have been used to seeing in the past. It's not that Xft can't render the .pcf fonts that come with the X-server, it's just that the system works to keep them from you. Here's how I force Xft and KDE to give me the old X core fonts.
First, go to /etc/fonts and make a backup of
fonts.conf, then open it in your favorite editor. It's
written in xml format, but is generally human readable. Near the top,
you'll see something like this starting at about line 17:
=================================[snip] --><!-- Font directory list configured on Sun Mar 2 05:32:31 UTC 2003 --> <dir>/usr/X11R6/lib/X11/fonts/truetype/</dir> <dir>/usr/X11R6/lib/X11/fonts/URW/</dir> <dir>/usr/X11R6/lib/X11/fonts/Type1/</dir> <!-- Enable sub-pixel rendering =================================[snip]
(Update: For X.org, it's sufficient to simply ensure the upper fonts directory itself is listed:
<dir>/usr/X11R6/lib/X11/fonts/</dir>
This newer method should allow Xft to find all the fonts in the subdirectories. Use this for all the font directories you wish to include.)
The older method is very similar to the FontPath section of your XF86Config file, and works the same way. To add the missing font directories, simply add two or three lines to fonts.conf to make it look like this:
=================================[snip] --><!-- Font directory list configured on Sun Mar 2 05:32:31 UTC 2003 --> <dir>/usr/X11R6/lib/X11/fonts/truetype/</dir> <dir>/usr/X11R6/lib/X11/fonts/URW/</dir> <dir>/usr/X11R6/lib/X11/fonts/Type1/</dir> <dir>/usr/X11R6/lib/X11/fonts/100dpi/</dir> <dir>/usr/X11R6/lib/X11/fonts/75dpi/</dir> <dir>/usr/X11R6/lib/X11/fonts/misc/</dir> <!-- =================================[snip]
Second, leaving nothing to chance, I make a similar adjustment in /usr/X11R6/lib/X11/XftConfig to look like this:
=================================[snip] dir "/usr/X11R6/lib/X11/fonts/truetype" dir "/usr/X11R6/lib/X11/fonts/Type1" dir "/usr/X11R6/lib/X11/fonts/URW" dir "/usr/X11R6/lib/X11/fonts/100dpi" dir "/usr/X11R6/lib/X11/fonts/75dpi" dir "/usr/X11R6/lib/X11/fonts/misc" =================================[snip]
Third, I go to the font directories themselves in /usr/X11R6/lib/X11 and make sure that each directory -- especially misc, 100dpi and 75dpi -- has a valid fonts.scale file. This is nothing more than a copy of fonts.dir. SuSEconfig wipes the fonts.scale files in these two directories, making them essentially empty, which makes the fonts unavailable to the X-server itself, even without anti-aliasing. Simply copy fonts.dir to fonts.scale, overwriting the empty fonts.scale files. (Note: This is no longer necessary under X.org.)
Finally, at the command line, run fc-cache, which will allow Xft to pickup the misc, 100dpi and 75dpi fonts. Add the "-v" flag if you want to see what the command is doing.
Logout to KDM, which restarts the X-server, then log back in. You should now be able to choose the older core X fonts in your KDE applications.
That third and final steps have to be repeated everytime SuSEconfig runs in SUSE, and may be similar with the config tool for other distros. That means every time you run the config tool to change packages or update, you may have to go back and make those two or three directories available. The short answer to avoid that is, after you are pretty sure you aren't adding any new fonts for awhile, edit the file /sbin/conf.d/SuSEconfig.fonts and comment out the last line like this:
#/usr/sbin/fonts-config --verbose --no-gs-fontmap
Other distros of Linux will hide their config scripts in similar ways. No one has been willing to tell me yet why they felt it necessary to cut out the core X fonts from KDE.
Update: The technique below fails with X.org,
especially on later monitors which can answer queries from the server
about screen dimensions. The best method now is to instruct your X
server via the graphics card driver itself. In your
xorg.conf file, add something like this in the section
labeled "Screen":
Option "DPI" "96 x 96"
This will work for some 17" and most 19" monitors, for example. It's
best to estimate the proper resolution based on what your resolution is
before you make this adjustment. I haven't found anything to contradict
the idea of taking the average of the numbers you do get when you run
xdpyinfo | grep resolution, rounding to the nearest whole
number. Please note while any balanced DPI value will probably work, the
values 96 x 96 and
72 x 72 are native to many fonts on your Linux
and Unix system.
Another method, especially where you do not have root access is to
make sure you have the line Xft.dpi: 96.0 (or 72.0 on
smaller screens) in your Xresources file. For example, on
RedHat-based distros, that would be /etc/X11/Xresources.
More details found here. Use
either of these methods and ignore what follows for any Linux distro
which incorporates X.org as the server.
There is one final issue that requires careful attention. Your X
server configuration offers one more pitfall that can distort fonts. If
the X server is configured such that the display pixels are not square,
it can cause errors in the alignment of vector and raster. To check, run
the command xdpyinfo | grep resolution. On mine, I got:
resolution: 94x98 dots per inch
Notice that it is not square; that is, the values are not the same. If the X and Y DPI values are not equal or out by even 1 then this may cause such oddball effects as one horizontal line of pixels disappearing when you display a document in your web browser. These DPI values are calculated from the size of the graphics window of your display (in pixels) and the computer's estimation of the actual monitor size. We can force the DPI values to be equal by overriding the display size values.
If you know the values claimed by the manufacturer of your monitor, that's a good place to start. If not, simply measure the viewable size of your monitor's face with a ruler. Convert to millimeters by multiplying the number of inches times 25.4. For example, my 19" monitor is reported by the manufacturer as 353x265. Actual physical measurements with a ruler it's 14.25x10.75:
14.25 inches x 25.4 = 361.95mm and 10.75 inches x 25.4 = 273.05mm
for an actual physical of 361.95x273.05. However, since we cannot have decimals in the X server config file, I round that to be 362x273. That is slightly larger, and gives me room to adjust and fudge until I get a resolution that gives me a square DPI.
The window and monitor size your server is using can be obtained from
the X server using xdpyinfo | grep dimensions:
dimensions: 1280x1024 pixels (330x250 millimeters)
for example.
We need to adjust the monitor size values so that the derived resolution values give us a square DPI. The easiest way to come up with corrected new values is to adjust the given monitor size values until they are in the same aspect ratio as the graphics window. That's a fancy way of saying that the dimensions are the same ratio as the display resolution. That display resolution for mine is 1280x1024, so let's find the ratio:
1280/1024 = 1.25
We need to adjust the screen face measurements until they yield that ratio. For some readers, that requires dredging up old and not-so-fond memories of Algebra. In general, it is a good idea to bump the height measurment by increments of one, and keep doing this until we get an even number for the width. The result is often a good bit lower for width than is actually measured. Using my example above, I will start with the manufacturer's height of 265, and compute for the ratio to produce a proposed width setting until it gives me a whole number, with no decimals.
1.25 x 265 = 331.25 < not a whole number; try again 1.25 x 266 = 332.5 < not a whole number; try again 1.25 x 267 = 333.75 < not a whole number; try again 1.25 x 268 = 335
That will work. While 335 is lot less than either the manufacturer's 352 and my measured 362, it won't matter that much. I now have a suitable monitor size of 335x268, which I now plug into my X server config (/etc/X11/XF86Config for Xfree86):
Section "Monitor"
Identifier "Monitor0"
Option "CalcAlgorithm" "CheckDesktopGeometry"
DisplaySize 335 268
I enter these values, save, then restart the X server. The result is no change in the actual dispaly on the screen, but the test results in a square DPI:
xdpyinfo | grep resolution
resolution: 97x97 dots per inch
In my case, there was an immediate change in the appearance of some fonts, such as in the menu of my window manager, but the big change was in my web browser, where the missing horizontal line of pixels did not reappear on any page I viewed.
By Ed Hurst, updated 11 September 2006
This document released into the Public Domain.