Window Managers (2003-10)

Index

• Introduction
• TWM OK
• Blackbox Middle
• Openbox NG
• Fluxbox Middle
• IceWM Middle
• Enlightenment NG
• FVWM NG
• FVWM95 NG
• QVWM NG
• Amaterus OK
• Afterstep NG
• AfterStep Classic OK
• Window Maker NG
• Sawfish OK
• OLVWM NG

Introduction

Why window managers need i18n?

It is window managers' responsobility to display window title. If a window manager cannot chooose proper font, the title is written as a meaningless row of characters.

Window title is where the window manager has to deal with various characters and languages even if the window manager itself has no translated messages. This is because clients may want to display words in users' mother tongues. For example, Debian web page has many translated pages with translated titles. Some web browsers try to set the window title using the page title.

How window managers support i18n? - skelton code

It is very easy for a window manager to display native languages --- just use X11 functions related XFontSet (such as XCreateFontSet(), XmbDrawString() and XwcDrawString,XFreeFontSet(), and so on), which is introduced from X11R5, instead of XFontStruct functions. These functions can:

1. choose a proper font automatically for the current LC_CTYPE locale. For example, -*-koi8-r font is automatically chosen in ru_RU.KOI8-R locale.
2. use multiple fonts at one time when needed automatically. East Asian locales need multiple fonts to cover characters which are supported in the locale.
3. perform wildcard matching like "-*-medium-r-normal--16-*". The font name can be specified even using comma, like "-adobe-helvetica-*--12-*,-*--12-*,-*--16-*,*".

Of course the window manager must call setlocale() to enable I18N faculty, because the behavior of these XFontSet-related functions depend on the current locale.

How window managers support i18n? - font fallback mechanism

However, there is one more problem. Even if a software adopts XFontSet-related functions instead of XFontStruct-related functions, improper setting of fonts often prevent the proper choice of fonts. This is because names for available fonts are different from locales to locales. For example, fonts of "-*-iso8859-1" are apparently not suitable for non-ISO-8859-1 locales and "-*-helvetica-*" are not available for Asian fonts. There are several cases which are problematic:

1. a software may hard-code font names in the source code.
2. a default configuration file may have improper font names.
3. some window managers support styles or themes. Definition files of these styles or themes may have improper font names.

To solve this problem, softwares should have fallback mechanism. It is VERY easy. Just adding ",*" after given font name. "*" matches any installed fonts which match the current locale, when used for XCreateFontSet(). When the fallback is used, the screen might not be very beautiful. However, at least, Mojibake (the worst case) can be avoided. TWM is an example implementation of this fallback mechanism. This mechanism is implemented by me and you can read an explanation of TWM in my Introduction to I18N document. You can implement more deluxe fallback mechanism to try to choose similar fonts as far as possible. However, it is usually difficult to design universal algorithms.

Keeping i18n-ed state

One more problem around i18n is to keep the internationalized status. Internationalized softwares can be easily broken into un-i18n state by innocent developers and patches. In this test, Blackbox, IceWM, QVWM, Window Maker, and so on are found to be broken even though they once could display i18n text.

To avoid such change for the worse, developers are encouraged to test their softwares. This page explains how to test if your software can display various languages.

No configuration other than LANG variable should be needed

English speakers expect that their characters (ASCII or ISO-8859-1 characters) are displayed well without any manual configurations. Thus, non-English speakers can want their characters to be displayed without any manual configurations other than LANG variable.

There are softwares whose core-parts support i18n but their i18n feature is disabled by default. For example, Window Maker. However, I should say that such software is badly designed. The reasons are:

1. When a user set LANG variable, it is apparent from softwares' viewpoints that the user wants to handle the language given by the variable. If a software requires more configurations, such need of configurations is redundant.
2. A developer of such software may think that the additional manual configuration is very easy. However, a user wants to use various softwares, not only the software. Imagine each software requires an "easy" configuration. The pile of "easy" configurations won't be easy any more. This is the position exactly Japanese (and other Asian, I guess) users are located. Go to Japanese bookstore and you will find several books whose topics are "how to configure your Linux/BSD to handle (display/input/print/...) Japanese." It is nonsense that such "easy" configuration will pile up to fill books.

Following examples

The followings are examples for window title written in Japanese (ja_JP.eucJP locale) and Russian (ru_RU.KOI8-R locale). ja_JP.eucJP locale requires multiple fonts and cannot be supported by conventional XFontStruct-related functions, while ru_RU.KOI8-R locale is 8bit and can be supported by them. Both of them use a large amount of characters other than ASCII/ISO-8859-1.

1. Prepare "ja_JP.EUC-JP" locale when installing "locales" package.
2. Invoke twm under ja_JP.eucJP locale.
   LANG=ja_JP.eucJP ; export LANG ; twm &
3. Invoke mlterm under ja_JP.eucJP locale.
   LANG=ja_JP.eucJP ; export LANG ; mlterm &
4. Type the content of the screenshot within the mlterm. To input Japanese, you will need to set up XIM before invoking mlterm. It is too much to explain how to set up XIM here.... However, here is a way to do same thing without requiring Japanese input:
   echo -e "\x1b]0;abcde\xa4\xa2\xa4\xa4\xa4\xa6\xa4\xa8\xa4\xaa\xb4\xc1\xbb\xfa\x07"

1. Prepare "ru_RU.KOI8-R" locale when installing "locales" package.
2. Invoke blackbox under ru_RU.KOI8-R locale.
   LANG=ru_RU.KOI8-R ; export LANG ; blackbox &
3. Invoke mlterm under ru_RU.KOI8-R locale.
   LANG=ru_RU.KOI8-R ; export LANG ; mlterm &
4. Type the content of the screenshot within the mlterm.

However, Russian characters are not displayed well in ru_RU.KOI8-R locale.

Note that Russian was displayed well when I tested various window managers a few years ago.

This is because Blackbox disables i18n mode (using XFontSet instead of XFontStruct) when the locale is not multibyte. Since ru_RU.KOI8-R is not multibyte, Blackbox will use non-i18n mode. This is the reason why Blackbox fails to choose Russian font in ru_RU.KOI8-R mode.

Russian characters are also not displayed.

2003-10-11 I found the reason of this problem. Though the QVWM itself has no problems, default setting of Debian package (introduced since version 1:1.1.12-1) has a problem. It adopts "-*-helvetica-medium-r-normal-*-14-*" as (one of) default font. There are no Asian fonts which match it. Here is a patch for QVWM 1.1.12 to choose proper fonts even with such improper font configuration. I sent the patch to the developer of QVWM and received a reply that the next release will include my patch (with some modification).

2003-10-13 I received several reports that Window Maker can display Japanese and so on when configured properly, like invoking wsetfont. However, I think such configurations should be unneeded. I also think such configuration can be unneeded if the software is designed properly.