JDK-4097028 : RFE: Multilingual font configuration and other font.properties enhancements
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version:
    2.1,1.1,1.2.1,1.2.1_003,1.2.2,1.3.0,1.4.0 2.1,1.1,1.2.1,1.2.1_003,1.2.2,1.3.0,1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,solaris_2.5,solaris_2.6,solaris_7,solaris_8,windows_95,windows_2000 generic,solaris_2.5,solaris_2.6,solaris_7,solaris_8,windows_95,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 1997-12-04
  • Updated: 2017-05-16
  • Resolved: 2003-06-24
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.
5.0 tigerFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  

Name: bb33257			Date: 12/04/97

The standard font.properties files should contain fonts
all the major character sets on the platform in question,
including Japanese, Chinese, Korean, and the 8859 series.

The only overriding font.properties_xx files should then
be for Chinese and Korean, to reorder their fonts ahead of
the Japanese.

A "universal" font, such as CyberBit should be at the very
end of the list to catch outlying characters.

Here are some bugs marked as duplicates of this bug:

4014956: RFE: font properties files should not use locale as a suffix
  The convention for properties files is that they use the suffix
  .properties.  Font properties files are named font.properties.<locale>.
   They should be changed to font.<locale>.properties.

4466575: add 'font options' in font.properties
  java version "1.2.2"

  some font are available only on specific platform,
  font.properties  should provides a mechanism that
  allows to choose the font depends on the
  platform that user has running.

  for example,
    "MS Sans Serif" for Sans Serif font in Windows 98,
    and "Microsoft Sans Serif" for Sans Serif font in Windows 2000.
   (both are use the same JVM - Win32)

4314494: font.properties file configured for largest character set
  Make the default font.properties file like the font.properties.x.utf8
  on Solaris so larger character sets can be supported.

Name: nt126004			Date: 02/13/2002

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

SunOS zaphod 5.8 Generic_108529-09 i86pc i386 i86pc


Any UNIX system

Japanese (for example) fonts are already installed on my
machine. the runtime should automatically use those fonts,
if a program tries to display a unicode character in that range.
It does not.

Prior long-standing bugid 4097028 claims on 2001-08-10

"Will address in next release".

It's the next release. The issue has not been addressed.

All you have to do is add the extra definitions to the
font.properties file. For example, take the


entries from font.properties.UTF8.5.7, and slap them into
the standard font.properties file.

Standard solaris installs HAVE the font

installed, regardless of locale... so USE it, please

Trivial test: I expected to be able to run

and see valid chars in the 3000-30c0 range.

All I see by default is the "unknown symbol" symbol for each

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See "Expected and actual results" .

( http://bolthole.com/java/unicode/unicode.class )

---------- END SOURCE ----------
(Review ID: 139267)

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b10

WORK AROUND Name: bb33257 Date: 12/04/97 ======================================================================

EVALUATION Will address in next release. xueming.shen@Eng 2001-08-10 I don't see how RFE 4014956 is related to this issue. It complains about the non-standard naming convention of our font.properties files. While this is a valid complaint, this naming convention has been in use for 5 years at this point. We'd risk compatability problems by changing it. The only reason to change the naming scheme was if we were completely re-doing the font.properties mechanism, in which case there'd probably be lots of incompatabilities anyway. ###@###.### 2001-12-10 We are completely redoing the font.properties mechanism for Tiger, although with a strong emphasis on keeping things compatible at an application level. There now are multilingual font configuration, at most one per OS version, and a fallback mechanism that lets us use fonts for all supported writing systems where the OS provides them. Fallback fonts have no impact on font metrics. ###@###.### 2003-06-18