Using JDK 1.2 under Hummingbird Exceed

Note: I'm still editing this document - it's not really written in English at this point...

You may wish to run Java applications under Solaris and display the X11 windows on a Windows PC running an X server. There are two main obstacles to this when using the current stable versions of the Solaris JDK (1.2.x) and Hummingbird Exceed (6.1.x).

(Note: The “Bug IDs” below are from JavaSoft bug database. You must be a member of JavaSoft's Java Developer Connection to browse their listings.)

Severe window manager misbehavior.

A user notes (under Bug ID 4131543):
[W]ith Exceed 6 and "Window Manager" set to "Default to Native", all my X clients lost their decoration and did not update properly. 1.1.6 did not seem to have this problem.
This occurs when Exceed is configured in Multiple Window Mode - if Exceed is configured in Single Window Mode, the root window is unmanaged by default and either hwm or a remote window manager must be started.

As a workaround, another user suggests:

Set "Window Manager" to "Native" under Exceed, or run an X window manager such as mwm or twm to manage all X clients.
The Exceed option to implement the first workaround is found in Configuration -> Screen Definition -> Window Manager and does seem to fix the problem.

The report in Bug ID 4112070 suggests that similar problems might be occurring under other commercial PC X servers.

This problem still exists as of: Exceed and JDK 1.2.2.

Missing fonts.

A user notes (under Bug ID 4072247):
The file shipped with jdk-1.1.1 includes fonts which are not universally available on X servers. In particular, several fonts are listed for the linotype foundry whereas the standard distribution of X11 (Rev 5 and 6) has no fonts with a foundry of linotype. The corresponding fonts use the adobe foundry.

The JDK wants a serif font (Times Roman), a sans-serif font (Arial/Helvetica), and some Symbol fonts (Symbol and ZapfDingbats/WingDings). The problem is that all of the fonts listed in .../jre/lib/ must be available to the X server, but Solaris includes many fonts that are not freely-redistributable (i.e., the fonts licensed from Monotype and URW++) and therefore not available in many non-Solaris X distributions. This results in error messages of the form:

Font specified in not found [-urw-itc zapfdingbats-medium-r-normal--*-%d-*-*-p-*-sun-fontspecific]

Sun's response is:

The binary reference releases of JDK are for Sun's Solaris OS, not for generic MIT/XC/TOG X Windows releases. All of the fonts used in the files are standard with Solaris. This is not a bug.
In other words, from Sun's point of view, you're only supposed to use the Solaris JDKs when you're actually sitting in front of a Sun workstation.

Sun is beginning to address the font heterogeneity issue; most importantly, a dynamic font loading mechanism will be introduced in JDK 1.3. However, the initial implementation only handles TrueType fonts. Unless Sun changes the fonts listed in .../jre/lib/ (which is unlikely for backward-compatibility reasons), the JDK 1.3 API changes will not fix the fundamental problem that the required fonts are simply not available in usable formats.

To run JDK applications on a Sun and display them on a PC, we need the right fonts and we need a way to access the fonts on the PC.

Font background

The major font file formats are (from the USENET comp.fonts FAQ):

X servers can usually access fonts in several of these formats. Some configuration is usually required to tell the X server which fonts to use and their location in the local file system.

The standard X11R6 X font server (xfs) provides remote access to fonts stored in various formats. We can run a font server on some UNIX machine that has the necessary fonts and allow the PC X server to download them. For example, the Solaris xfs implementation can serve Adobe Type 1 and Sun Folio fonts (as well as the standard X11 BDF/PCF bitmap fonts). The directories containing the font files are indexed using fonts.dir, fonts.scale and fonts.alias files. fonts.dir (which is usually identical to fonts.scale) maps font file names to font names; fonts.alias maps new font names to already-defined font names.

Obtaining fonts

There are several ways in which we might be able to get access (local, using files, or remote, using xfs) to the necessary font files.

  1. Exportable to Exceed using font importing. Sun's makebdf utility will convert the .f3b font files in /usr/openwin/lib/X11/fonts to BDF. It is then possible to import the BDF files into Exceed (which internally converts them into Windows .fon files). Since BDF (and .fon) fonts are not scalable, all desired font sizes must be generated using makebdf.

    Unfortunately, all of the .f3b fonts that are used by the Solaris JDK are copyright-protected. The .f3b font files are encrypted and makebdf will only export them at font sizes of 20 points or less. Since applications may request larger font sizes, this is not a very useful option in practice.

  2. Available under Exceed using font aliasing. Like xfs, Exceed has a mechanism for font aliasing - its .ali files have essentially the same format as fonts.alias. Some of the fonts required by the JDK (or close relatives) are distributed with Exceed.

    Unforunately, not all of the necessary fonts are distributed with Exceed; notably, Exceed is missing many bold-italic fonts. Therefore, this is not a very useful solution, either.

  3. Exportable from /usr/openwin using xfs. The Solaris /usr/openwin contains many fonts. One might consider using xfs with these fonts.

    Unforunately, the Solaris xfs will only export unprotected fonts. Therefore, the Solaris Type 1 fonts (Adobe Times, Helvetica, Courier and Symbol) can be exported but the contents of the .f3b font files (i.e., URW++ ZapfDingbats and Symbol) cannot.

  4. Exportable from freely-available font information using xfs. Free versions of ZapfDingbats and Symbol (as well as other fonts) have been donated by URW++ to the Ghostscript distribution. The Type 1 font files in this distribution can be exported directly using xfs.

    By elimination, we have to get ZapfDingbats this way. We may as well get Symbol this way, too, because the Solaris .f3b font file contains a URW++ font (whereas the Type 1 font exported by Solaris is an Adobe font).

You can download fonts from the Ghostscript distribution or via Unpack this distribution and produce the desired fonts.alias and fontserver.cfg. An example fonts.alias file can be found here.

You can start a new, supplementary instance of xfs or modify the default installation. Make sure that it will start automatically when the system reboots (the fsadmin command can be used for the default installation).

Add the font server to Exceed. Configuration -> Fonts -> Font Database -> Add; OK out. File -> Reload Database -> Font.

Perform a sanity check:

% xlsfonts -display my_exceed_pc:0 | grep -i zapf
-adobe-zapf chancery-medium-i-normal-medium-0-0-0-0-p-0-iso8859-1
-adobe-zapf dingbats-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
-urw-itc zapfdingbats-medium-r-normal--0-0-0-0-p-0-sun-fontspecific
-urw-zapf chancery-medium-i-normal-medium-0-0-0-0-p-0-iso8859-1
-urw-zapf dingbats-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
% xlsfonts -display my_exceed_pc:0 | egrep -i arial

This problem still exists as of: Exceed and JDK 1.2.2.

Last modified: $Date: 2003/01/02 04:06:38 $ by $Author: aoki $