JDK-4145297 : Java does not find all fonts on Windows NT
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1998-06-03
  • Updated: 1999-01-14
  • Resolved: 1999-01-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.2.0 1.2fcsFixed
Related Reports
Relates :  
JDK-4795932 - RFE: Java 2D should locate fonts by using the windows registry
Description

Name: rm29839			Date: 06/03/98


My NT machine is configured as follows (font-wise):

* TTF fonts stored on alternate drive.
* Bitmap (System) fonts stored in %SystemRoot%\Fonts
* Symbolic-links to my TTF fonts are also stored in %SystemRoot%\Fonts (this is legal and can also be achieved by installing fonts 
from Control-Panel and unchecking the 'Copy fonts to Fonts folder' checkbox.)

The VM doesn't seem to recognize this (i.e. the symbolic links) and exits with an error message of the type 'could not find fonts in 
c:\winnt\fonts.'

After some browsing through %JDKPath%\bin\classic\jvm.dll I stumbled over 'JAVA_FONTS', so I created an environment variable 
JAVA_FONTS with my TTF directory on the alternate drive, and everything worked.

Warning: I also saw the '\Fonts' string in jvm.dll
*IF* you are assuming that fonts (even symbolic links to fonts) are stored in %SystemRoot%\Fonts, you might be in for a big 
surprise.  There is a particular registry key which holds the Fonts directory location, and you should get that (which, 
indeed, is %SystemRoot%\Fonts by default but can always be changed!) instead of assuming a default location.
(Review ID: 32742)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2fcs FIXED IN: 1.2fcs INTEGRATED IN: 1.2fcs
14-06-2004
WORK AROUND Name: rm29839 Date: 06/03/98 Manually set JAVA_FONTS environment variable to point to the already 'installed' fonts. ======================================================================
11-06-2004
SUGGESTED FIX The correct fix is pretty involved and we may want to defer this for now. I need to totally bypass the fontpath and filtering method of enumerating available fonts (which is pretty much a pure shared code solution) and write windows only code that hits the registry to buid up this list. This involves both .java changes and .cpp changes.
11-06-2004
PUBLIC COMMENTS Looks like the two workarounds were acceptable to both testing and engineering. If someone can make a compelling reason to put the extra work and redesign into the code then reopen this. gstone@eng 1998-09-29
29-09-1998
EVALUATION new code needed paul.charlton@eng 1998-06-18 The bug reports that the Fonts directory is not always in the windows root directory. This is erroneous, it can only ever be in the %Windows%\Fonts. I've scoured all the Microsoft documentaion and found no indicators otherwise. If the submitter can find official docs to support this great, show me and I'll use the alleged registry entry that describes where the fonts dir is. The other assertion that the Fonts directory location is located in the registry is also incorrect. The problem is that Windows allows users to install fonts into the system without copying the actual font file to the \Fonts directory. To implement this they keep shortcuts(symbolic links or aliases) to the original file. However, this is not done, interestingly, in the classic way of making a typical shortcut. Doing a list of the \Fonts directory from a dos shell or programatically shows absolutely no trace of the font file or a shortcut. The shortcut only shows up in the explorer. I believe this is done by a slight-of-hand hack that forces explorer to go to the registry to pull out the fully resolved name and path of all installed fonts and then display what appears to be a standard explorer window. The correct fix is pretty involved and we may want to defer this for now. I need to totally bypass the fontpath and filtering method of enumerating available fonts (which is pretty much a pure shared code solution) and write windows only code that hits the registry to buid up this list. This involves both .java changes and .cpp changes. So question, do we want to mess with this now? or can it wai till 1.2.x? gstone@eng 1998-08-27
27-08-1998