The Openstreetmap applet expects java.awt.Font.getPSFontName() to return something non-null.
Of course I mean getPostScriptName() and not getPostScriptFontName().
Is the code that uses this available somewhere? Seeing how the result is used/parsed would help determine what format to return.
Sure: http://dev.processing.org/source/index.cgi/trunk/processing/core/PFont.java?view=markup Search for getPSName(). Though AFAICS it wouldn't hurt to return anything for a start.
This is the problematic code: // this font may or may not be installed font = new Font(name, Font.PLAIN, size); // if the ps name matches, then we're in fine shape if (!font.getPSName().equals(psname)) { // on osx java 1.4 (not 1.3.. ugh), you can specify the ps name // of the font, so try that in case this .vlw font was created on pc // and the name is different, but the ps name is found on the // java 1.4 mac that's currently running this sketch. font = new Font(psname, Font.PLAIN, size); } // check again, and if still bad, screw em if (!font.getPSName().equals(psname)) { font = null; } When getPSName() return null, the test throw NullPointerException.
And psname is read from the font file. It seems the code assumes this is equal to the font family name. So doing something like this might be a good idea as a start: diff -u -r1.8 GdkFontPeer.java --- gnu/java/awt/peer/gtk/GdkFontPeer.java 16 Mar 2006 20:21:09 -0000 1.8 +++ gnu/java/awt/peer/gtk/GdkFontPeer.java 19 Mar 2006 19:48:44 -0000 @@ -158,7 +158,7 @@ public String getPostScriptName(Font font) { - return null; + return this.familyName; } public boolean canDisplay (Font font, char c) BTW. We also have a (no unused) GtkFontPeer implementation that should be removed to avoid confusion.
Checked in the following as current workaround: 2006-03-19 Mark Wielaard <mark@klomp.org> * gnu/java/awt/peer/gtk/GdkFontPeer.java (getPostScriptName): Return familyName. * gnu/java/awt/peer/gtk/GtkFontPeer.java: Removed unused file.
A mapping .properties file is needed.
Isn't a PS name ususally stored in the TTF file?
Roman: Looking at the TT specification, it looks like you're right. Hacking together an implementation of this shouldn't be so hard.
Okidoki, I've got an implementation for this now.
Commited my implementation.