The kochi-sub fonts now defines in font.properties.ja.Sun as default Japanese
font but the RICOH fonts should be defined for quicksilver.

Here is the RICOH font package which will be integrated into quicksilver b06.
http://ministop.japan/Products/Java/J2SE/quicksilver/06/jafonts_ttf-1.0.0-1.noarch.rpm

This issue is a showstopper on JDS.


###@###.### 2004-02-02
(1)The scheduled/planed Korean font.properties files did not make into 1.4.2_04
   due to a putback mistake. Need to udpate in 1.4.2_05.
(2)Currently JDS is using an install-patch to update the Simp.Chinese and
   Trad.Chinese font.properties files to make the zh_CN and zh_TW locales
   work correctly, these files need to udpate in 1.4.2_05 as well.

So all Asia font.properties files for JDS will need udpate in 1.4.2_05.

===================================================================
Describing here and in comments another situation that need the next
full JDK, not JRE only, to have the font.properties.{ja,zh}.SUN.new, etc.
so we can support our products on jds quicksilver and beyond, which
need to use 1.4.2.*

Products of our group, the Sun Java Studio ide and netbeans, require
that a full jdk be used, both for installing the product and using the
product.

For using the product, a full jdk is needed since it is a developer tool
and uses the jdk for javac, rmic and other commands/tools found in the jdk
but not in the jre, like the default jre on jds.

But the current jdks do not have these additional font.properties files
so user running in zh (and I think ja) locales on jds, using the full
jdk, will not see characters of that locale properly, which means
that in effect we can't have a localized zh or ja release nor can
users of the en version run properly in ja or zh locales.

I've seen that workaround could be to have user copy the new font.properties
files to their jdk, but this means
- in effect doesnt it create a new, unsupported, untested jdk ?
- its can be confusing for users and is not a good out of box experience;
this is a UI product.

===> Can this be fixed in next full 1.4.2.<next> jdk and at least we could
direct users to that jdk when they use jds ?

###@###.###
02/04/2004