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.







FULL PRODUCT VERSION :
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)

FULL OPERATING SYSTEM VERSION :
SunOS zaphod 5.8 Generic_108529-09 i86pc i386 i86pc

ADDITIONAL OPERATING SYSTEMS :

Any UNIX system


A DESCRIPTION OF THE PROBLEM :
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

fontcharset.dialog.8

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

Standard solaris installs HAVE the font
-misc-fixed-medium-r-normal--*-%d-*-*-c-*-jisx0208.1983-0

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



EXPECTED VERSUS ACTUAL BEHAVIOR :
Trivial test: I expected to be able to run
http://bolthole.com/java/unicode/unicode.class

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

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


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)
======================================================================

======================================================================

Will address in next release.
 xxxxx@xxxxx  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.
 xxxxx@xxxxx  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.
 xxxxx@xxxxx  2003-06-18