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.)
[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 18.104.22.168 and JDK 1.2.2.
The font.properties 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/font.properties 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 font.properties 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 font.properties 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/font.properties (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.
The major font file formats are (from the USENET comp.fonts FAQ):
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.
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.
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.
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.
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.
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 blackdown.org. 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 -monotype-arial-bold-i-normal--0-0-0-0-p-0-iso8859-1 -monotype-arial-bold-r-normal--0-0-0-0-p-0-iso8859-1 -monotype-arial-regular-i-normal--0-0-0-0-p-0-iso8859-1 -monotype-arial-regular-r-normal--0-0-0-0-p-0-iso8859-1 %
This problem still exists as of: Exceed 22.214.171.124 and JDK 1.2.2.