JDK-5066464 : JDK 1.5 fontconfig.properties should not include abolute path to physical font
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-06-22
  • Updated: 2012-10-09
  • Resolved: 2004-12-18
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 JDK 6
5.0u1 01Fixed 6Fixed
Related Reports
Relates :  
JDK-5014112 - fontconfig.properties needed for Turbo 10
Relates :  
JDK-4890369 - Need updated OS version detection for SuSE
Description
a.)
To use several Asian Glyphs one has to register additional Fonts in the JDK 1.5 fontconfig.properties file (here as an example the fontconfig.RedHat.properties.src file from build 51a):

# Font File Names

filename.-arphic_technology_co.-ar_pl_mingti2l_big5-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/zh_TW/TrueType
/bsmi00lp.ttf
filename.-misc-baekmuk_batang-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/ko/TrueType/batang.ttf
filename.-misc-baekmuk_gulim-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/ko/TrueType/gulim.ttf
filename.-misc-kochi_gothic-medium-r-normal--*-%d-*-*-c-*-jisx0208.1983-0=/usr/share/fonts/ja/TrueType/kochi-gothic.ttf
filename.-misc-kochi_mincho-medium-r-normal--*-%d-*-*-c-*-jisx0208.1983-0=/usr/share/fonts/ja/TrueType/kochi-mincho.ttf
filename.-misc-zysong18030-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/zh_CN/TrueType/zysong.ttf

In addition, you have to register X11 fontpaths to java in the following section:

# AWT X11 font paths
awtfontpath.latin-1=/usr/X11R6/lib/X11/fonts/Type1
awtfontpath.chinese-big5=/usr/share/fonts/zh_TW/TrueType
awtfontpath.chinese-gb18030=/usr/share/fonts/zh_CN/TrueType
awtfontpath.japanese-x0208=/usr/share/fonts/ja/TrueType
awtfontpath.korean=/usr/share/fonts/ko/TrueType

Because the filepaths are absolute, this scheme will break except in the rare cases of a home user's out-of-the-box Linux Installation with a popular Distribution ( See 5014112, 4890369 for examples). 

The majority of business installations use fontservers, remote-boot with shared font directories or imaged installations with modified font locations. Common to all these installations is a non-default location of the fonts. The Tiger Documentation for Font Configuration states, that by modifying the fontconfig.properties file, the customer will loose his support for these installation. The customer will end up in the deadlock of an JDK supplied configuration which will not work, but cannot change without loosing support.

To our believe, this aproach is fundamentally flawed. You force yourself to qualify supported and unsupported Linux-Distros, which you will see seldom in the field and if you find them, you need to play cath-up with the actual locations of fonts in that distribution.

b.)
The fonts used for a given writing system on a given platform are not documented.
So it is not known which fonts have to be installed to get a fully functional system.
Comments
EVALUATION So far as I can tell this whole bug/RFE is based on some incorrect assumptions, so I'd be interested to hear if this was actually observed, or just supposed? JDK should not break if the fonts are moved, so long as they are still present and locatable. The "filename." absolute paths are primarily a "short-cut" so that JDK can find the fonts faster, as start-up time is important. If they are elsewhere (but still present and locatable) then JDK will still find them and all will be well. ie if the font isn't where it says it is JDK does already fall back to XGetFontPath, plus a number of well known directories, AND the list of directories known to the fontconfig library. That's as exhaustive as it gets and the font if it exists will be found. This will work even if the font file is named differently so long as the XLFD is correct. It just takes longer. The awtfontpath entries are a legacy thing, and aren't even used unless you specify a platform-specific property, and even then aren't important unless you build your app using the java.awt heavyweight components (ie don't use Swing or any other ssuch toolkit) so its not important. So the suggested fix would simply slow down start-up on most systems without adding any value. ###@###.### 2004-06-22 ============================ I'd like to hear the submitter's opinion about the above evaluation. ###@###.### 2004-06-23 ============================== I believe I know what the problem is and I've added a partial, untested, fix into the suggested fix field. The JRE code isn't verifying the file exists at the point that the mapping is read. It really needs to do a File.exists() call which will trigger the callback/search code as described above. The reason its not doing that is an optimisation to avoid touching the filesystem, but in this narrow case its better to do that. If this shows up in start-up costs (which I doubt) since it will probably just a very small number (1->3) of such queries, the suggested fix could be refined to be triggered only when the fontconfig file used is not an exact match on O/S and O/S version, which we can assume to be a configuration in which files will be where they are known to be installed. Another necessary refinement is to ensure this is triggered only for "core" fonts in a composite font, not fallbacks. Those are quite likely not to be present and we don't want to trigger the search in those cases. That part of the fix hasn't been included but the signature to getFileNameFromPlatformName() could be updated to include a boolean as in getFileNameFromPlatformName(platformFontName, f<numCoreFonts); ^^^^^^^^^^^^^^ ###@###.### 2004-06-23 ============================= Added information provided by the submitter. ###@###.### 2004-06-24 ============================== As it stands without changing code, if a filename is NOT specified in the fontconfig.properties, a search is automatically triggered. This is what the submitter wants to do, but for performance reasons on supported platforms its important that the files shipped with the JRE contain full path names. The submitter can still create his own and they should work. The issue really is then a side-effect of an optimisation to not touch the file system to verify that when a filename is specified that it exists. The fix is as indicated above to try to rectify that for Linux distros which are somewhat unstable in this regard, so that the JRE is robust if the filename is no longer valid ( ie the JRE will essentially ignore filenames which do not exist and behave as if there was no entry in the fontconfig file. The fix is a little more complex than originally supposed. The GraphicsEnviroment gets the filename from the FontConfiguration in a couple of places: in the array of platform names, as previously noted, but also in CompositeFontDescriptor(s). Both of these cases need to have a validation of the file existence, The fix thus needs to have the FontConfiguration check the existence of the file before passing its name to the GraphicsEnvironment. The validation also needs to be efficient : we don't want to go to the file system more than we have to. So the main parts of the fix are 1) A new method that can efficiently indicate whether a file exists. 2) A test in the GraphicsEnvironment which calls that existence test function and if it fails invokes existing code to build maps of all font files. 3) Calls to the existence test in the FontConfiguration class that ensure only validated file names are supplied to the GraphicsEnvironment. i.e., if it doesn't exist, it will ask the GraphicsEnvironment to look in its maps for a file that matches the platform name (XLFD). The difference in behaviour of the JRE with these changes is that on Linux, if a path is specified in the fontconfig.properties, and that path does not represent a file, that a search is triggered. There is also another factor adding complexity to the fix. Since fontconfig files are "per OS version", and fallback fonts are specified, it is very common that not all these fonts are installed. For example an English install of Redhat 9 may not include the Japanese fonts we would use as a fallback. In this case we have a choice 1) Search for the fonts, perhaps fruitlessly, and slowing start-up 2) Confine the existence tests to fonts that are part of the core set of fonts needed for the user's locale. (ie don't penalise English-speaking users who don't have Korean fonts installed). The latter is the preferred option. ###@###.### 2004-08-03 ============================ Fixed in the documentation. The necessary locale support information was already on the Supported System Configurations page, but just not very visible. http://java.sun.com/j2se/1.5.0/system-configurations.html After some discussion, we have made it more visible by changing this line from: Also see Supported Locales for this version. to: Check the Supported Locales document for the supported writing systems (languages) for each platform. The JRE does not support all writing systems on all platforms. ###@###.### 2005-1-20 19:43:20 GMT
20-01-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.5.0_01 mustang FIXED IN: 1.5.0_01 mustang INTEGRATED IN: 1.5.0_01 mustang
15-09-2004
SUGGESTED FIX a.) Don't specify a full qualified path for the font but only the name of the font file then use already defines font path (XGetFontPath()) to resolve the path to the font. filename.-misc-zysong18030-medium-r-normal--*-%d-*-*-c-*-iso10646-1=zysong.ttf Even this scheme is not fully foolproof since there are distributions not delivering the kochi fonts due to licensing problems but delivering something like kochi-mincho-subst.ttf and declare these fonts in the font directory (fonts.dir) so it would be even better NOT to define the XLFD <-> file name mapping but to let the system do this mapping and to properly specify the requirements for the font in the XLFD. This would lead to the situation that really all installed outline fonts could be used out of the box. b.) Add a list of required fonts / writing system for a given Platform to your documentation. ###@###.### 2004-06-22 ================== --- X11GraphicsEnvironment.java Wed Jun 23 09:54:53 2004 *** 338,346 **** */ Vector xVal = (Vector) xlfdMap.get(fileName); if (xVal == null) { ! xVal = new Vector(); ! xVal.add(platName); ! xlfdMap.put(fileName, xVal); } else { if (!xVal.contains(platName)) { xVal.add(platName); --- 338,357 ---- */ Vector xVal = (Vector) xlfdMap.get(fileName); if (xVal == null) { ! if (isLinux && !fileName.startsWith(jreLibDirName)) { ! /* Verify file exists. If it doesn't, set it to null ! * to trigger a search. ! */ ! File f = new File(fileName); ! if (!f.exists()) { ! fileName = null; ! } ! } ! if (fileName != null) { ! xVal = new Vector(); ! xVal.add(platName); ! xlfdMap.put(fileName, xVal); ! } } else { if (!xVal.contains(platName)) { xVal.add(platName); *************** *** 347,354 **** } } } ! fontNameMap.put(fontID, fileName); ! return fileName; } if (fontID != null) { --- 358,367 ---- } } } ! if (fileName != null) { ! fontNameMap.put(fontID, fileName); ! return fileName; ! } } if (fontID != null) { ###@###.### 2004-06-23 =============================
23-06-2004