The windows desktop properties implementation reads a number of
font names from the windows system registry via SystemParametersInfo calls.
The returned strings are as names used to instantiate java.awt.Font objects
However the names that windows uses in these cases are usually a windows
specific alias.
For example on my XP Pro SP 2 the following system desktop properties
and font names are returned.

win.ansiFixed.font : Courier
win.ansiVar.font : MS Sans Serif
win.deviceDefault.font : System
win.oemFixed.font : Terminal
win.system.font : System
win.systemFixed.font : Fixedsys

The only client of these APIs - ie which uses the java.awt.Font objects -
is the Swing Windows Look and Feel.
As it is, without some code to appropriately map these using registry
entries, or hard coded appropriate mappings, the majority of these will
not be found by the font system. The consequence is that the font system
incurs an expensive and fruitless search - ie loads all fonts only to
not find a font called "Courier" for example. That caused a particular
problem as win.ansiFixed.font is used by the Win L&F - the others may not be?

Currently a couple of places do some remapping already :
The Windows Look and Feel code remaps MS Sans Serif to Microsoft Sans Serif,
and - although not in the above list - awt_DesktopProperties.cpp resolves
MS Shell Dlg and MS Shell Dlg 2.

What this bug is requesting is that the code in awt_DesktopProperties.cpp
remap the above listed font names to some suitable value before creating
the java.awt.Font.
Determination of appropriate mappings probably requires some amount of
digging into either the registry, or may be something that varies by
windows release.
But hard coded mappings are better than nothing
for example :
Courier -> Monospaced
Fixedsys -> Monospaced



###@###.### 2005-04-15 16:44:21 GMT