Information inside font.properties file applies directly to encoding, not to locale. But in searching algrothm, the priority of locale is higher than encoding. For example, for en_US.UTF-8 locale, the seqence is

font.properties.en_US_UTF8
font.properties.en_US
font.properties.en_UTF8
font.properties.en
font.properties.UTF8
font.properties

The problem is we have another 5 European UTF-8 locales (fr.UTF-8, de.UTF-8 ...), they are using same encoding like en_US.UTF-8, but due to above sequence, we have to create multiple files with same content. We have already done this for lt/lv, cs/hu/pl locales. And we will have to add more UTF-8 files for Simplified and Traditional Chinese which will have UTF-8 locale in Solaris 8.

The solution is changing the priority of locale and encoding, make searching sequence as

font.properties.en_US_UTF8
font.properties.en_UTF8
font.properties.UTF8
font.properties.en_US
font.properties.en
font.properties

That will make different locales which use same encoding share font.properties file. We can ship less font.properties file than we have now,

  font.properties.ISO8859_2 (cs, hu, pl)
  font.properties.ISO8859_4 (lt, lv - Solaris 7)
  font.properties.ISO8859_5 (ru)
  font.properties.ISO8859_7 (el)
  font.properties.ISO8859_9 (tr)
  font.properties.ISO8859_13 (lt, lv - Solaris 8)
  font.properties.ISO8859_15_FDIS (Euro)
  font.properties.UTF8 (all UTF-8)

khong@eng 1999/04/23

Fred Oliver is suggesting if we always use encoding name for all font.properties files, we don't have to change searching algrothm, current algrothm works fine, it will fall back to file with encoding-only extension if we don't have file with locale-only extension.