» Sign in
  
Jump to HP Home Jump to Product & Services Jump to Support & Drivers Jump to Solutions Jump to How to buy
» Contact HP
 » Advanced Search
Jump to HP Home

How Java™ products for HP-UX display Asian fonts

Developer & Solution Partner Program (DSPP)


A site for HP Partners

 »  DSPP home

Benefits & Services
 »  Marketing & Sales
 »  Technical
 »  Collaboration

Resources & Downloads
 »  Technologies & Tools
 »  HP Products
 »  HP Solutions
 »  Software downloads

 »  Specialized programs

 »  Events
 »  Newsletters

Partner information
 »  Find a partner
 »  Find a partner solution

Shortcuts for
 »  Independent software vendors
 »  Integrators & Consultants

About DSPP
 »  Why join?
 »  Membership benefits

 »  Latest updates

 »  Contact us

 »  Site map

Irene Smith
Enterprise Java™ Lab
February 2002

Introduction

This article gives you useful information about how Java products for HP-UX display Asian fonts. If you are localizing your HP-UX Java application for Asian locales, read on to get details about the contents of the Asian font.properties files, and how the SDK for HP-UX works with the Asian TrueType font patches.

Java is a platform-independent language, but Asian fonts are delivered with your platform. In addition, font rendering is platform-dependent. For example, the native font rendering used by Microsoft Windows is quite different from the UNIX platforms. Solaris, Linux and HP-UX render images using the X11 Windows system. Java handles platform dependencies by using a layer of indirection.

Tip 1: sans or not sans?

The Java Logical Font Name is a mapping between a platform's native font name and Java. The Java Runtime defines five classes of fonts: sansserif, serif, monospaced, dialog and dialoginput. Peek at your font.properties files in JAVA_HOME/jre/lib to see these mappings. More on these mappings is described in the next tip. You can simplify the testing of localized Java applications by knowing that the five font classes map into just two categories: Serif and SansSerif. The data below is taken from the Japanese font.properties file (font.properties.ja):

Java Logical Font Name     Printer's Typeface         JA TrueType Family Name
=======================    =====================      =====================
serif                      Serif                      HPMinchoL
sanssserif                 SansSerif                  HGGothicB
monospaced                 SansSerif                  HGGothicB
dialog                     SansSerif                  HGGothicB
dialoginput                SansSerif                  HGGothicB

To test your application in the Japanese locale, start by testing a serif and a sansserif font. The styles (plain, bold, italic and bolditalic) are applied independently to each font, so you want to try each style, too.

Tip 2: your swing components search for true type fonts

Let's use Sun's documentation on font.properties files at http://java.sun.com/j2se/1.4/docs/guide/intl/fontprop.html to decode an HP-UX TrueType font.properties file. The lines below are from the Korean font.properties.ko file which is delivered when you install the HP-UX font patch PHSS_24933 for HP-UX 11.0, or patch PHSS_24934 for HP-UX 11i.

   monospaced.plain.0=-hy-hydotum-medium-r-normal--*-%d-*-*-m-*-ksc5636.1989-0
   monospaced.plain.1=-hy-hydotum-medium-r-normal--*-%d-*-*-m-*-ksc5601.1987-1
   monospaced.plain.2=-monotype-courier new-medium-r-normal--*-%d-*-*-m-*-iso8859-1

Each line is a name/value pair. On the left hand side is the Java Logical Font name "monospaced". On the right hand side of the equal sign is the "face name" or native font name. For HP-UX X11 Windowing platforms this very long name is in the form of an "xlfd" or X Logical Font Descriptor. The xlfd is used to look up the glyph.

These three lines together indicate the indexes for the three Korean monospaced fonts. The numbers (0, 1, and 2) that appear after the word monospaced indicate the order in which the font glyphs are searched for a corresponding match with the Unicode, or Java string encoding, codepoint. Thus, if monospaced.1 and monospaced.2 both have a glyph that corresponds to the same Unicode codepoint, then the glyph for monospaced.1 will be used.

A case in point is finding the Greek Omega glyph. If you switch the order of the monospaced.2 and monospaced.1 lines, you will see a change in the Omega character. The first image shows Omega when its codepoint is selected from the "courier" typefaces.

HP JDK 1.3.1 courier example

In the next image, Omega is found in the "hydotum" typeface family.

HP JDK 1.3.1 hydotum typeface family example

The font is specified, but we're not done yet. The font's encoder/decoder needs to be specified. For X11 Windowing platforms like HP-UX, the index of a font is not a Unicode index. The Java Runtime needs to convert the index before attempting to use the glyph for the font. Each monospaced.* entry must have a corresponding fontcharset entry, which indicates the Java class to use to convert the Unicode string to the actual glyph index.

In our example, monospaced.2 and monospaced.3 both have fontcharset entries in the font.properties.ko file, as follows:

   fontcharset.monospaced.0=sun.io.CharToByteEUC_KR
   fontcharset.monospaced.1=sun.io.CharToByteEUC_KR
   fontcharset.monospaced.2=sun.io.CharToByteISO8859_1

The monospaced.1 fontcharset entry indicates that, to draw the -hy-hydotum-medium-r-normal--*-%d-*-*-m-*-ksc5601.1987-1 glyph, Java runtime should use the "sun.io.CharToByteEUC_KR" converter to get the Unicode index. Recall that we have already established the font for monospaced.1 as hydotum. All monospaced.0 fonts, regardless of whether the type is plain (monospaced.plain.0), bold (monospaced.bold.0), italics (monospaced.italic.0), or bold and italics (monospaced.bolditalic.0), will be converted using this converter.

Be careful: if you switch a line such as we did in the Omega test, you must switch the corresponding fontcharset entry.

In a future release, character converters will be accessed through the new java.nio.charset API, which will enable the use of third-party character converters.

Tip 3: find that font

Java needs to find each physical font. If you've seen boxes instead of characters in your Swing application, you'll know what happens when Java cannot find the font.

Some physical fonts, called "Lucida", are shipped with Java. You can find them in $JAVA_HOME/jre/lib/fonts. Other physical fonts, such as HP's Zycjkhei Chinese, are shipped with the operating system and are installed outside of JAVA_HOME... so Java needs a way to find them.

With the SDK 1.3.1.02 Java support for HP-UX Asian TrueType fonts, the property "hp.fontpath" is introduced. Normally you will not need to change this property. If you look at its value for Simple Chinese, (font.properties.zh_EUC_CN) you will see that it includes the default installation location of the Simplified Chinese physical fonts (/usr/lib/X11/fonts/TrueType/chinese_s.st.typefaces).

With SDK HP-UX support for Asian TrueType fonts, the file fonts.dir.jre is read by Java. This maps the physical font file (such as zyhei.ttf) to the xlfd.

Tip 4: don't sweat the exclusion info

If you look at font.properties.ko, you will see an "exlusion info" section. This is useful when, for some reason, the Latin character set needs to be placed early in the search sequence, but some Latin characters should be taken from an Asian character set later in the search sequence. The Asian font.properties files exclude non-ASCII character sets from Latin fonts so that Signs, Symbols, Greeks and Cyrillic are always found from the Asian physical fonts.

Tip 5: your AWT components use bitmap fonts

If you use both Swing and AWT components, be aware that when you invoke an AWT application, you will be using bitmap fonts. AWT and Swing components render fonts differently: a bitmap font may have slightly different typeface styles, and a smaller set of characters than its corresponding TrueType font.

For AWT components like TextComponent, the Java runtime uses a property called XFontSet in the font.properties files. This property maps the Java logical font name to a set of AWT bitmap fonts. It is used when X11 creates the native font. In addition, a default XFontSet is defined.

Glossary

Glyphs and Chars: A character is a symbol that represents items like letters and numbers in a particular writing system. For example, lowercase-g is a character. When a particular character has been rendered, a shape now represents this character. This shape is called a glyph.

Encoding:Chararcter encoding is a conversion table that maps character codes to glyph codes in the font. The character encoding used in Java is Unicode. For more information on Unicode you can visit the site http://www.unicode.org.

Physical Fonts: A Physical Font is the actual font library containing glyph data and glyph-sequence-mapping data, using a font technology such as TrueType or PostScript Type 1. A TrueType Physical Font is just a file named with a ".TTF" suffix. A Physical Font Name is the name inside the local fonts.dir file.

Serif and SansSerif: A typeface designer's classification that describes the physical characteristics of each typeface. These are typographical terms.








Printable version

Privacy statement Using this site means you accept its terms Trademark acknowledgment Contact us
HP Confidential © 2009 Hewlett-Packard Development Company, L.P.