Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4978622

[1.4.2_05] cjk font.properties files for quicksilver needs to be updated



    • Subcomponent:
    • Resolved In Build:
    • CPU:
      generic, sparc
    • OS:
      linux_sun, solaris_8


      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.

      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

      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 ?



          Issue Links



              sherman Xueming Shen
              kurosaki Kenichi Kurosaki (Inactive)
              0 Vote for this issue
              0 Start watching this issue