Q: How can I make the InterMapper web server maps look like the maps in RemoteAccess?
A: Because of differences in the image rendering engines, the two displays will not be pixel-for-pixel identical. The major difference comes in the display of fonts. (Different fonts have different character metrics, which cause the labels and rectangle sizes to be different.)
You can minimize these differences by ensuring the same fonts are saved in the InterMapper server and in the machine running the RemoteAccess client.
There are two sets of fonts that are readily available to Java and most underlying operating systems: Lucida and DejaVu. Lucida is distributed with most Java JDK implementations. DejaVu is an open-source font available from http://dejavu-fonts.org/. The Tips below gives more information.
On the server, you can copy those fonts to the InterMapper Settings/Fonts directory. You may need to create the Fonts directory, and will have to restart the InterMapper server to make the fonts available. On the RemoteAccess machine, you should install those fonts so they're available to Java.
Tips for Fonts:
On Ubuntu systems, you can install the Lucida fonts with apt-get:
|apt-get install sun-java6-fonts
Fonts live in /usr/share/fonts/truetype/
Copy desired fonts from there to /var/local/InterMapper_Settings/Fonts/
Other systems have similar mechanisms to get the sun-java6-fonts.
With InterMapper versions before 5.4, open the font with the OS font-viewer first to verify that the "Style" is one of "Regular", "Bold", "Italic", or "BoldItalic"; InterMapper 5.4 can use fonts so long as they contain one of those words in the style name.
Sun/Oracle have a whole set of FAQs regarding fonts at:
Q. What font types does Java 2D support?
A. The primary and preferred font format is the TrueType font format. Java 2D also supports Opentype layout tables within TrueType fonts for complex text rendering (Arabic, Indic etc). In addition Java 2D supports Postscript Type1 fonts.
Q: Are any fonts bundled with Java 2D?
A: Yes, the Java SE SDK includes three Lucida TrueType font families: Lucida Sans (Sans Serif), Lucida Typewriter (Terminal/Monospaced) and Lucida Bright (Serif). However, only one font : Lucida Sans Regular is always distributed with the JRE that is installed with Java Plugin for running applets in web browsers to limit download size as TrueType fonts can be quite large. End users can elect to install the other fonts but only Lucida Sans Regular is guaranteed to be always available in any Java application. However since Lucida Sans Regular supports many character sets, such as Basic Latin, Latin 1, Latin Ext A, Greek, Cyrillic, Hebrew, Arabic, currency symbol, super subscripts, number forms, dingbats, it means applications have a guaranteed good base line of support. The font files are located in the $JAVAHOME/jre/lib/fonts directory.
Q: How can I make my custom font available to my Java application?
A: Since Java 2D can locate fonts installed in the O/S one option is to just install the font on your system in the usual platform manner - eg dragging it into the Windows font folder.
If you don't want other applications to use your font then there are two other options
• If you ship a private JRE with your application you can copy your fonts to $JAVAHOME/jre/lib/fonts since they will be available only to java applications executed by that JRE and will be visible via Java's font enumeration APIs.
• You may also load custom fonts dynamically - by using java.awt.Font.createFont() to instantiate your fonts from files or network streams.
Fonts instantiated via createFont() offer even more flexibility in limiting the visibility of the font. Font instances using such custom fonts cannot normally be constructed. Instead you must use Font.deriveFont() on the instance returned from the Font.createFont() method. Therefore only code to which you provide a references to the Font can use it. Note that each call to createFont from the same source (file) will create a new distinct Font which will be GC'd only when it is no longer referenced. So if you expect to need to use the created Font in many places simultaneously cache a single copy to derive from rather than re-creating from the source file.
As of Java SE 6, there is a method : GraphicsEnvironment.registerFont() which gives you the ability to make a "created" font available to Font constructors and to be listed via Font enumeration APIs. Font.createFont() and this method combine to provide a way to "install" a Font into the running JRE so it is available just as O/S installed fonts are. However this Font does not persist across JRE invocations.
Q: Why does (eg) a 10 pt font in Java applications appear to have a different size from the same font at 10pt in a native application?
A: Conversion from the size in points into device pixels depends on device resolution as reported by the platform APIs. Java 2D defaults to assuming 72 dpi. Platform defaults vary. Mac OS also uses 72 dpi. Linux desktops based on GTK (Gnome) or Qt (KDE) typically default to 96 dpi and let the end-user customise what they want to use. Windows defaults to 96 dpi (VGA resolution) and also offers 120 dpi (large fonts size) and lets users further specify a custom resolution. So a couple of things can now be seen
• The DPI reported by platform APIs likely has no correspondence to the true DPI
of the display device
• Its unlikely that Java 2D's default matches the platform default.
So a typical results is that for Window's default 96 DPI that a 10 pt font in a Java application is 72/96 of the size of the native counterpart.
Note that Swing's Windows and GTK L&Fs do scale fonts based on the system DPI to match the desktop. If you want to do the same in your application you can call java.awt.Toolkit.getScreenResolution() and use this to apply a simple scale to the size you specify for fonts.