Customizing X Window: An Introduction
Pages: 1, 2
The next three entries need more circumspect treatment; let us start with the last one:
Option "XkbLayout" "us"
xkb represents one of the more complex X Window libraries; it functions as an intermediary between the X server and most possible keyboards. It uses a complex rules language which is useful if you want to produce your own keyboard mapping. We already know that it has been implemented as an X server extension.
Option entry included in the
InputDevice section is necessary to decide which locale- or purpose-specific keyboard layout you would like to start with. I am choosing those words advisedly, since it is possible to switch keyboards, not just their layout. The mechanisms for doing so can be set in the same entry. But be aware that you might have to add keyboard mappings; this adds considerable amount of work to X11 localization.
So, if you would like to start with a US-style layout, you need to choose the "
us" character-style combination. If you would prefer French-style keyboard mapping, choose "
fr". German is represented by "
de" etc. You can also choose the Dvorak layout, using the "
dvorak" keyword. The latter would also apply if you actually changed the physical keyboard, not just the layout.
This is an example of a xkb rule and we will hear about them a little more.
The next option will be:
Option "XkbModel" "pc102"
since we need to decide whether we need an international keyboard or just varieties of English. This entry refers to the keyboard geometry. The quick rule of thumb says we should use a bigger keyboard with more keys, particularly if we want to be able to switch keyboards while typing. So let's change it to:
Option "XkbModel" "pc105"
105 keys sounds a bit more roomy and it will accommodate languages with additional letters in the alphabet as well as Umlauts and compound characters if required.
The last entry we have to talk about isn't that exciting, since we have only two options to worry about:
Option "XkbRules" "xorg"
since we are using the Xorg X server, we don't need to worry about the
xfree86 option. Xfree86 is going rapidly the way of outdated technology.
In other words, we have changed only one entry so far, namely XkbModel.
More surgery is needed to enable the same keyboard to be the carrier of several keyboard layouts. Some keys will be mapped to glyphs different from standard QWERTY layouts, and on occasions key press combinations will result in characters composed of the character glyph with a diacritic sign on top, or other glyph combinations.
But first we have to make sure that keys that are not part of the original keyboard layout (e.g. "us") to become part of key press combinations. That is achieved by making sure that all keys are functional, even though some keys might only result in visible glyph combinations after they and another key have been pressed. So, ‡, ‰, and š will all be possible, once the following option has been enabled:
Option "XkbVariant" "nodeadkeys'
If you would like to create your own keyboard layout, you can of course do that, too, but this requires in-depth knowledge of xkb functionality and rules syntax. The files live in
/etc/X11/xkb/symbols/ or its subdirectories. This is a rather complex operation, which has been documented elsewhere.
Now we can finally switch between layouts by changing one and adding another option:
Option "XkbLayout" "us,fr,de" Option "XkbOptions" "grp:alt_shift_toggle'
The commas between the keyboard layout names are essential, and there are no spaces between the layout types. We have enabled a standard US, a German, and a French keyboard layout. We are able to switch between keyboard layout by pressing the ALT and the SHIFT key together.
Finally, the complete
Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbVariant" "nodeadkeys' Option "XkbLayout" "us,fr,de" Option "XkbOptions" "grp:alt_shift_toggle' EndSection
All text processing systems need to provide access to the software machinery that transforms keystrokes into glyphs. Multiple keystrokes, as we have seen, can result in a complex or rare glyph. This is often important for languages that do not rely on the Roman or Cyrillic alphabet, particularly, Arabic, and Indic scripts and their derivatives, as well as Chinese, Japanese, and Korean scripts and their historical predecessors.
Fonts come in a particular design, also known as a typeface. A particular design is prevalent within a group of fonts, making up a font family.
Digital as opposed to physical fonts have to provide the data to generate glyphs that adhere to a given typeface.
If the fonts do not have a fixed size, a scaling algorithm can be added to the font description, enabling the creation of glyphs of varying sizes. So-called Type 1, TrueType, and OpenType fonts are all scalable and available for X Window. In some cases and in particular with X Window, the data actually describe bitmaps and thus many fonts usable for X Window are collections of bitmapped data.
Ordering Font Names
Although fonts often seem to be designated by names that reach far back into human history, they are ordered according to very clear principles. Fonts have names, families, sometimes sizes, weights, and many other properties.
Digital glyphs are also indexed according to font file formats: TrueType fonts order glyphs by the integers given to them by a known encoding scheme, e.g., Unicode. Unicode itself maps character set members to a unique sequence number, and is used at times as a glyph encoding scheme.
Type 1 fonts give glyphs a glyph name, based on the font family, font name, and glyph position. Type 1 font description are usually not enough to create a font on the screen; they need to be supplemented by metric data, which is usually made available in separate files. The format and algorithms associated with Type 1 fonts have been open sourced quite a while ago and are freely available to anyone who cares to inspect them.
OpenType fonts can be considered supersets of most other fonts and should be installed if possible.
For X Window to find your fonts, you actually have to go back to xorg.conf first. The Xorg X server needs to know where the fonts are that it can use in any and all cases. This is largely due to the fact that there are still two fonts systems that can be accessed by X11. One group of fonts is known as the core fonts and the others as the xft fonts. The latter is a bit of a misnomer since it refers to a group of libraries necessary to maintain, add, and render new fonts in your X Window System;
The information necessary for X Window to find your core fonts is contained in the Files section of the
xorg.conf file. Remember that these are fonts that should also be used by xterm, and indeed most term implementations. Most "pure" X Window applications will find their fonts here. Please be aware that "pure" X11 implementations do not actually exist: they are called X apps, since they don't need more than a minimal window manager, like twm, to function.
If those applications should support xft, we will go about things a bit differently and the server font path is actually not necessary, since fonts will be available only client-side, not server-side.
A possible font path for standard X Window implementations, including FreeBSD, Mac OS X and some Linux distributions would look like this:
Section "Files" FontPath "/usr/local/lib/X11/fonts/ # further Section entries follow EndSection
Normally, the core fonts should be installed when your system has been installed. It might be advisable not to add too many non-xft fonts, even if you are tempted, since far fewer applications are likely to use them these days.
X11 Font Management
You can add fonts usable by xft and the fontconfig system under the directory above by just copying the font file directly to the /fonts directly.
First of all, though, you should check on the command line, which fonts are available:
$ fc-list ''
should list all fonts available to X Window. If you would like to check which installed font can be used to display a particular language, you can use the following flags for the fc-list command:
$ fc-list :lang=de
: flag means "all font faces with the following characteristics, if any."
lang=de restricts the search to font faces compatible with the German language, while
lang=fr would restrict the search to those compatible with French.
We need to make the fontconfig system aware of any font changes by typing
$ fc-cache -f
at the command line.
To make sure that you can render most fonts available for X Window, it would be a good idea to add the so-called Freetype module in the modules section of
Section "Modules" Load 'FreeType' # further Section entries follow EndSection
You can of course add other modules in this fashion, if necessary, but Freetype covers most types of fonts and processes them.
You also have to add the FontPath line in the xorg.conf to make freetype fonts accessible:
Section "Files" FontPath "/usr/local/lib/X11/fonts/Truetype # further Section entries follow EndSection
Under X11, Fonts are managed with the
fonts.conf, which sets X11-wide defaults, should not be changed by hand, unless really necessary. Any and all font configuration changes can also be entered in the
local.conf file which should be available in the
/etc/fonts/local.conf (Ubuntu) or similar locations.
Again, different Linux flavors and the BSDs have subtly different rules on this matter. The
local.conf file is an xml file, which should start with the following header:
<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig>
and end with the
Again,You could make your font path explicit in the
local.conf file, but that is not always required. Still, to stay within the pattern on font paths we have established in the
xorg.conf file, we are adding your font location or locations, this time just with XML tags. Please be aware that this is an arbitrary example, and you have to follow your system defaults to match your font locations:
How to Make Them Look Pretty
Finally, you will have to make sure that all fonts, regardless of font face or language have to display properly. One aspect is anti-aliasing, which in some cases might not work particularly well with small Arabic or Chinese fonts. You can switch off antialising for all fonts smaller than size 13 by using the following rules:
<match target="font"> <test name="size" compare="less"> <double>13</double> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> <match target="font"> <test name="pixelsize" compare="less" qual="any"> <double>13</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match>
In essence, this XML fragment looks for any fonts and figures out whether there are any fonts with sizes of less than 13. It allows for size by abstract measurement ('13') or pixel size.
It is of course much more interesting to do it for specific fonts and switch off anti-aliasing for, say, an Arabic font:
<match target="font"> <test name="family"> <string>Lateef</string> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match>
Font configuration can also be personalized: You don't need to centralize all details in fonts.conf, since you can also copy a
fonts.conf version to your home directory and fiddle with the details of the XML file until it comes out just right.
Frank Pohlmann is a full-time writer, technology analyst, and teacher. He runs Ostracode, a small consultancy company from Manila and the U.K., while thinking about logic, poetry, and computer security.
Return to ONLamp.