Customizing X Window: An Introductionby Frank Pohlmann
X Window, X11 or "X," as it is known for short, provides the programming framework and the underlying runtime system for most Unix and Linux-based network-transparent windowing implementations. It runs on a huge number of Linux and Unix flavors, including Mac OS X and with a bit of help, on several Windows varieties. Without X11 , there is no KDE, no GNOME, and no Linux-based window manager, unless one is prepared to accept an X replacement. They do exist, and many carry a proprietary license, while X comes with a GPL-compatible license.
Many Linux and Unix desktops and window managers should actually be called X Desktops, since they use the X Window framework to provide users with a full, bitmapped system GUI. Still, most Linux and Unix users would not actually see X Window directly, except when they run X applications, like the xterm and rxvt terminals or some fairly basic games. On its own, X Window requires, but does not provide software to manage and display flexible GUI elements, e.g., windows. It provides the primitives to display them, however, including the ability to draw graphical elements and, of course, strings of characters.
These days, X Window comes in the so-called X.Org variety: the X.Org Foundation provides the canonical X Window open source implementation. XFree86 used to be very common, but the coming of 64-bit processors and various other issues obsoleted XFree86 fairly quickly.
Most of the time, it is possible to leave standard X Window configurations alone, but there are occasions when X looms very large in the lives of system administrators and power users: if there are major input and output device issues, or when system-based applications refuse to display window decorations or fonts properly, a fairly deep knowledge of X configuration files—and not GUIfied X11 configuration tools—is of the essence.
What Needs to Be Localized?
Localization results in culturally specific visible effects. It is perhaps surprising that almost no localization resources residing on or attached to a computer are changed or used in a productive manner. X Window and of course, some window managers and desktop shells, give you this opportunity. X Window deals with visual input and output devices, whether software or hardware, including most graphics cards and monitors. X Window can deal with multiple monitors and provides the libraries to help render 2D and 3D primitives to the screen. Compositing all those elements in layout, collating fonts or even full 3D environments is also a task where X Window, and in particular its configuration files play an important role.
What Needs to Be Done
First of all, input devices, i.e., keyboards and mice need to be configured. Keyboards conform to technical as well as linguistic specifications. The number of keys, the layout of the keys and the way keys are mapped to the underlying character set as well as the available fonts are determined by X Window and font configuration files. In a localization context, mouse configuration is of course not as important as keyboard configuration, but we should not forget that the way copying and pasting is handled can effect particular text layout environments: cut-and-paste works differently for top-down and right-to-left scripts, like classical Chinese text layout and traditional Mongolian scripts.
Input methods sometimes have to be heavily modified using special input software and some of it is available with X11. It is, however, language and sometimes, script-specific what needs to be done, so we will not talk about it here.
X11, Fonts and Locales
Secondly, X Window makes available, and partly renders, all fonts used by windowing applications. Conversely, X Window does not care much about fonts available at Runlevel 2, or rather the level of the command line user: X11 uses its own fonts. Of course, if there is no window manager or desktop shell, or indeed, no X Window installation, localization and fonts is purely a matter of system locales and system fonts. X Window does care about character sets very much, though and derives its information about systems locales from the system or (g)libc locales. Please remember that X determines its own keyboard mappings and uses its own fonts.
It is always useful to check which locales are available by typing
$ locale -a
at the command line.
X11 needs system locale information as a localization starting point: Nothing is more embarrassing than having a fully localized terminal menu bar, while the shell running inside the terminal cannot display, say, French or Russian filenames. Here is, in short, what you need to do to make your system locale information available to X11:
First of all, you need to make sure that all possible character sets that could become part of your system locale are included by X11. There are three files you need to keep updated: the
compose.dir, and the
locale.dir files. You will find all of them in the
/usr/X11R6/lib/X11/locale location. Your system might prefer another path, so mileage may vary.
If you need a complete survey of the locales that have been tested under X11, you should go to http://webcvs.freedesktop.org/xorg/xc/nls/locale.alias and find the relevant locales. You can of course create your own locales if necessary, but this would go beyond the purview of this article.
A partial list for all varieties of German alphabets and its flavors would be (including some Austrian, Swiss, Luxemburgish, and Belgian flavors):
de: de_DE.ISO8859-1 de_AT: de_AT.ISO8859-1 de_AT@euro: de_AT.ISO8859-15 de_AT.iso88591: de_AT.ISO8859-1 de_AT.ISO-8859-1: de_AT.ISO8859-1 de_AT.ISO_8859-1: de_AT.ISO8859-1 de_AT.iso885915: de_AT.ISO8859-15 de_AT.ISO-8859-15: de_AT.ISO8859-15 de_AT.ISO-8859-15@euro: de_AT.ISO8859-1 de_AT.UTF-8@euro: de_AT.UTF-8 de_AT.utf8: de_AT.UTF-8 de_BE: de_BE.ISO8859-1 de_BE@euro: de_BE.ISO8859-15 de_DE.ISO_8859-15: de_DE.ISO8859-15 de_DE.8859-15: de_DE.ISO8859-15 de_DE.8859-15@euro: de_DE.ISO8859-15 de_DE.ISO-8859-15@euro: de_DE.ISO8859-15 de_LU.ISO-8859-15: de_LU.ISO8859-15 de_LU.ISO-8859-15@euro: de_LU.ISO8859-15 de_LU.UTF-8@euro: de_LU.UTF-8 de_LU.utf8: de_LU.UTF-8 GER_DE.8859: de_DE.ISO8859-1 GER_DE.8859.in: de_DE.ISO8859-1
This is necessary to make it possible for you to use short names for your system locales. Multiple permutations need to be reflected; you might realize that there are multiple spellings for each locale name. It might be a good idea to be careful about the placement of hyphens and underscores within each name.
You also need to update the
compose.dir file located in the same location to reflect the character sets you are actually using: The first name indicates the database file and the second name indicates the locale name used system wide. This is just a single example; you can add several locales, and if you are implementing several keyboard layouts for separate languages, you actually have to do so.
Finally, you need to update the locale.dir file in the same location indicate to X Window that it should use the locale the non-windowing systems use in the first place. The first name shows the local database filename name and the second entry, again, shows the full locale name.
This makes sure that you can use the character set adapted to Swiss German.
In this vein, we should also mention the issue of personal preferences: fonts and layout issues are to some extent a matter of personal taste and as such often shaped by cultural forces.
Font choice is based on technological possibilities, although little can be more annoying than having anti-aliasing enabled in your font configuration file, and your users complain about headaches because individual glyphs seem to fade into the presumably darkened terminal window background. This is, for instance, an X Window issue, not a KDE or GNOME issue, although desktop shell utilities may be of help in this matter.
Further, physical keyboards can be a matter of personal preference as well, when, for instance, the Dvorak keyboard layout can help avoid carpal-tunnel syndrome, since it stresses key press combination that are substantially different from the usual QWERTY keyboards.
The Dvorak layout has been adapted to other languages and scripts, but there are of course additional issues to be resolved, since the physical layout of the keyboard has to be changed in a different fashion if non-Latin scripts are involved. Still, X Window would need to be aware of both the keyboard layout (Dvorak) and the linguistic environment (say, English and Turkish) to avoid both health problems and enable keyboard switching while using the same keyboard hardware.
The main configuration files,
fonts.conf, are not very well documented. Both contain basically all information to configure and localize X Window as a whole. To perform some surgery on both needs some fairly detailed research, which this article will facilitate.
X 11 Architecture and Localization
X Window basically consists of a client-server core protocol for an X server and multiple X client the X server communicates with. X servers are written such that they can accommodate extensions. Clients can of course communicate with each other without taking X server into account to a great extent, but we do not need to deal with it here. We don't need to worry about protocol details, but we do need to pay attention to the way keyboards and fonts are managed.
Keyboards are managed by the Xorg server via the X keyboard extension, also known as xkb. The X Window core protocol contains keyboard control commands, but the xkb extension substantially improves upon X Window core-protocol based control of keyboards.
The keyboard extension is, strictly speaking, a part of the X Server, while font management, since the appearance of the first Xorg X Window implementation released in 2004, is very largely a client issue: a library called xft takes care of client-side font management. This is in contrast to XFree86, where font management was very much a server side issue and font servers were a separate entity exposed quite directly to users and system administrators.
It is possible to use the window manager to add and select existing fonts to be used system-wide, but please be aware that any window manager or desktop shell provides little more than a pretty interface to the client-side X Window xft library and the fontconfig utility to enable font management. KDE and GNOME provide some additional facilities, but neither goes much beyond X Window functionality. The Pango library is vital, however, for very sophisticated font drawing and layout management. X Window does not deal with text layout management at all, so additional help from other libraries is actually necessary.
Xorg.conf Surgery for Keyboards
First, you should make sure that you actually generated an
xorg.conf file. Look in
/etc/X11/xorg.conf or the directory in which your Linux distro or Unix flavor saves its xorg.conf. If it doesn't exist yet, run the following commmand, but make sure you run it as root or at least use sudo to run this command:
This command will do a good job of finding all your hardware and provide a basic xorg.conf for you.
The xorg.conf file consists of at least eight sections and at most 12 sections. All sections begin with
Section "section name" and end with
EndSection. You have to enter all entries between the those lines.
Every entry has to stand alone in a line, and is made up of a keyword, followed by one or more arguments. You can add either an integer in decimal, hex, or octal formats; the latter is important for geometry specifications or floating point numbers. You can also add a string within double quotations marks, something which the Section
"SectionName" line already demonstrated.
These days, keyboards and mice are defined in one xorg.conf section, but let us just look at the keyboard entry first.
Here we go:
Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc102" Option "XkbLayout" "us" EndSection
This won't do anything just yet, since this entry has to be referenced in another, namely the
ServerLayout section, which we will come to in a minute.
You can also add the keyboard option to an X Window startup command line.
$xorg -keyboard "Generic Keyboard"
You can activate the keyboard in this fashion, provided there is no
CoreKeyBoard option in your
InputDevice section. Otherwise, no matter whether you specify this option on the command line or not, the Generic Keyboard entry will activate at Xorg server startup.
You need both the
Identifier and the
Driver name value sequences, since otherwise your entry will by replaced by X defaults. We have used a run-of-the-mill keyboard without a very exciting physical layout, so the identifier and the driver can remain the way they are. You might want to use
kbd instead of
keyboard, but this wouldn't change much either.
Pages: 1, 2