Fonts in GNU Classpath

Classpath currently has almost no support for graphics, although this would be needed for many applications. An important part of any graphics API is text handling, which requires an infrastructure for fonts. This document is intended as a basis for discussion with other GNU Classpath developers.


Sascha Brawer, July 29, 2003

MotivationRequirementsImplementationMissing Parts
Dependencies (or: please help!)PatentsBackground Literature


GNU Classpath is currently far away from a serious implementation of anything related to graphics. This is rather unfortunate, since Java defines a rich and well-designed interface for programming graphics applications.

If Classpath had a working implementation of Java2D, developers could write graphics applications that run on GNU and other free operating systems. Because Java2D is part of Sun’s “Java 2 Standard Edition,” it will be needed for executing Java applications in free desktop environments. A good graphics library would also be important for some embedded systems, and it is an absolute necessity for any client-side OS based on Java. Finally, there are also server applications needing graphics.

A picture may say more than a thousand words, but graphics without text is almost useless. Fonts are at the core of text processing. Therefore, a reasonable infrastructure for fonts seems a good starting point for an implementation of Java2D.


A prospective font infrastructure for GNU Classpath should fulfill at least the following requirements:

New fonts at any time — A Java application can define fonts at any time by calling Font.createFont. — This must be supported.

Character set — Java uses the full 21-bit character set of Unicode, but encodes characters in UTF-16. Codepoints in the Basic Multilingual Plane are stored without modification, those above U+FFFF are squished into surrogate pairs (U+D800 – U+DFFF). — Support for the entire Unicode character set would be nice to have. Support for 16-bit characters is required.

Glyph selection — The mapping from a sequence of Unicode codepoints to the glyphs in a font is very complicated. — The initial version must support simple table-based lookup of glyphs, as required for Font.createGlyphVector. Support for contextual glyph selection (see Font.layoutGlyphVector) is not required for the initial version. This means that it will initially not be possible to correctly display e.g. Urdu, Hebrew, or Devanagari. Even some Latin accents will not be displayed correctly. However, this initial support would be sufficient for glyphs in “simple” writing systems, under the condition that only pre-composed codepoints are used for accented characters.

Printing — The font library should expose what is needed to embed some glyphs of a font into a stream sent to a printer. It should be possible to write a javax.print.StreamPrintService for PostScript or PDF.

Rasterization — OpenType supports three variants to specify the shape of a glyph: Straight line segments plus quadratic Bézier curves (TrueType), straigt line segments plus cubic Bézier curves (PostScript Type 1), and bitmaps. — For a first version, it seems acceptable to support only the “rasterization” of bitmaps. This would be sufficient for server and command line applications that use Java2D to generate PostScript or PDF, because these just need to measure and embed glyphs, but they do not need to rasterize them. It would also be sufficient for displaying a GUI, as long as the GUI uses a font with embedded bitmaps. One could produce a version of GNU Unifont in OpenType format, and the authors of Free UCS outline fonts could be asked to embed bitmaps. — Later, rasterization should be performed as well. A rasterizer could be written in Java, or one could call the rasterization code from FreeType. Either variant is a major project and needs to be coordinated with the scan-line conversion code for normal graphics.

Hinting — When rasterized for low resolution, vector fonts look ugly. Therefore, a process called Hinting moves the vector control points before rasterization. There exists an online demo which uses FreeType to show how (TrueType) glyphs look with and without hinting. For bitmaps, no hinting is needed.

Metrics — The geometric extent of glyphs must be determined for Font.getStringBounds and related methods. It would be nice to take into account the FontRenderContext, because the exact values depend on device resolution and other parameters, such as whether anti-aliasing is performed. However, this would mean that vector fonts need to be hinted. For an initial version, it seems acceptable to assume an ideal device with infinite resolution, and to assume that glyph metrics grow linearly with point size. This won’t be sufficient for high-end typography, but it should be enough for a start.

Localized Names — TrueType and OpenType Fonts can specify a variety of names in multiple languages. — This should be supported for Font.getFontName(Locale).

Thread safety — Fonts must be safe to access from multiple simulaneous threads. Otherwise, it would not be possible to e.g. prepare a picture in a background thread. Note that the performance-critical methods of java.awt.Font expect data in bulk amounts, for example for creating a GlyphVector. Therefore, the locking overhead should not be prohibitive.

Memory management — Some fonts can be quite large. There exist Kanji fonts whose size exceeds ten megabytes. — The font library should thus avoid reading data unless it is really needed. It should support font files that have been mapped into the virtual address space (java.nio.MappedByteBuffer).

License — To fit with the rest of Classpath, the font library must have same license: GPL with the compiler exception, copyright assigned to the Free Software Foundation.

Written in Java — Being platform independent, it would be good for Classpath to provide a Java implementation for almost everything. This would be a reference implementation and would be of great help when porting Classpath to a new platform. Then, according to the underlying system, an optimized version can be made using native methods written in C. Where Classpath is used in combination with a decent compiler, no native code would be needed at all. Therefore, only the absolute minimum, if anything at all, should be implemented in native code. — A possible candidate for native code would be the stack machine for interpreting TrueType bytecodes (which could be taken from the FreeType project; see the above section about rasterization). Not a good candidate for native code would be glyph selection, or extraction of font names.


Dandelis (i.e., Sascha) has implemented a first version of a library that could serve as the described font infrastructure for GNU Classpath. See the automatically generated documentation of the library.

There also is a test program which allows to show all glyphs in the font, to display some font names, to layout a glyph vector, and to perform other operations which test the library. To build the test program from its source, execute the following command on a GNU/Linux (or UNIX) machine which has at least JDK 1.4 installed:

% tar zxf fonts-July29.tar.gz ; make

To execute the test program (which can also be downloaded in pre-compiled form), execute the following:

% java -jar fonttest.jar SomeFontFile.[ttf|ttc|otf|dfont]

For each font that is embedded in SomeFontFile, a window will appear where example text can be entered. It is also possible to specify a point size. The test program will use the font library of GNU Classpath to create an instance of java.awt.font.GlyphVector, and to retrieve the outline of each glyph as a java.awt.geom.GeneralPath. That path is passed to a Graphics2D object for anti-aliased rendering. Because GNU Classpath does not yet support graphics, it is not (yet) possible to run the test program without the Sun JDK.

A screen shot of the main window

It should also be noted that the text field (the top line) is a normal Swing text field. The font library of GNU Classpath is only involved in the display of the bottom field. Actually, pure black-and-white text (without anti-aliasing) would be close to illegible without hinting, at least for small point sizes. See below for details.

A number of example texts are available from an option in the Edit menu. In the View menu, you can make the logical bounding box of each glyph visible (which gets painted in pink and blue). There, you can also display the visual bounding box of each glyph (which gets painted in green).

A screen shot of the main window with bounding boxes enabled

Please note the last character, which was obtained from the Unicode sequence U+0078 U+0303 U+031F (LATIN SMALL LETTER X; COMBINING TILDE; COMBINING PLUS SIGN BELOW). However, the font library currently does not move accents to attachment points, so a tilde on a capital X would not be placed at the right position. You are of course more than welcome to enhance the library!

Also in the View menu is a menu item which allows to display every glyph in the font, together with the glyph name. The latter would be important for embedding glyphs into PostScript or PDF.

A screen
shot of the glyph window

Finally, you can view the localized names and other information by selecting “Show Information” from the View menu. The screen shot below is from a different font (Helvetica Bold from MacOS X), because the Lucida fonts do not contain localized font names.

A screen
shot of the information window

Missing Parts

There are some missing parts. You would be very welcome to work on these; please contact Sascha Brawer.

Glyph positions — Some glyphs in the LucidaSans font get placed at weird positions, for example the closing parenthesis or bracket. Also, accents get placed at the wrong positions with some fonts. The latter affects composite glyphs that specify an attachment point in addition to a transformation matrix. An example would be all accented glyphs in the Helvetica font that comes with MacOS X. This needs fixing

Hinting — The class is currently able to execute arithmetic and control flow instructions, which is enough for font pre-programs. However, most geometric instructions (which move control points around) are currently not implemented.

CFF (PostScript) — The library understands the OpenType font file format, but is not able to retrieve outlines that are described in the PostScript CFF format.

Caching — Glyph bitmaps should be cached, but they are not right now. This might be best done at the same time when Classpath’s rasterizer gets implemented. Right now, it is not clear (to me) what format the cache should use.

Bitmaps — For the same reason, the library is currently not able to render embedded bitmaps.

Contextual glyph substitution, reordering — Complex script systems that require re-ordering glyphs, or substituting glyphs depending on context (using deterministic finite-state machines which can be part of the font data) are not yet supported. Neither is the more primitive OpenType mechanism supported. This means that is is currently not possible to render text in Arabic, Farsi, Hebrew, Hindi, Thai, Urdu, or in any other language that requires a non-trivial glyph selection/positioning.

TextLayout — A big missing part is java.awt.font.TextLayout. To implement it efficiently, it will probably be necessary to extend the interface

Glue code — Finally, some glue to java.awt.font is missing; for example, it is currently not possible to retrieve glyph justification information. It seems that the best time for doing this would be when java.awt.font.TextLayout gets implemented.

Dependencies (or: please help!)

The library depends on some parts that are not yet present in GNU Classpath. Some will require serious work, and this would be an area where your help would be greatly appreciated. The work would also be needed for other parts of Classpath, not just the font infrastructure described here.

java.nio — Make sure that java.nio works. It is heavily used by the font infrastructure, for reasons explained above. Especially tricky is to make direct buffers work, because it needs support from the virtual machine.

java.nio.charset.spi — Write a service provider for some charsets. The font infrastructure needs only decoders, most urgently MacRoman for extracting font names. This should not take more than a day for each character set, and it would be useful for much more than just font names.

java.awt.geom — Complete the implementation of QuadCurve2D.

java.text.Bidi — Implement the Unicode Bidirectional algorithm. This should take only a few days, but it would be helpful to be familiar with the algorithm. A speaker of Arabic, Hebrew, or some other language that is written right to left would be ideal for this task, although this is not strictly necessary. (The Bidi class is not yet used by the font library, but it will be needed to support OpenType fonts with bi-directional script systems).

If you think that one of these tasks would suit your interests, or if you would like to do something else for GNU Classpath, please contact the GNU Classpath mailing list, classpath at gnu dot org.


Apple Computer holds several patents on the algorithm that is needed to fully hint TrueType glyphs; see the FreeType patent page for further information.

There exist serveral possibilities to deal with the patent issue.

Background Literature

[Adobe, 2002] OpenType Specification v1.4
Specifies the format of OpenType fonts, including the TrueType and CFF outline formats. Only those font tables are described that are understood by the Microsoft and Adobe implementations.
Adobe Systems, Inc. Open Type Specification v1.4. Available online, last updated October 2002.
[Apple, 2002] TrueType Reference Manual
Specifies the format of TrueType fonts, including other tables like bitmaps. Only those font tables are desribed that are understood by the Apple implementation.
Apple Computer, Inc. TrueType Reference Manual. Available online, last updated December 18, 2002.
[Jenkins, 1999] The Unicode Character-Glyph Model: Case Studies
Compares how characters are mapped to glyphs in OpenType, in Apple’s ATSUI (formerly QuickDraw GX), in the Omega project (a Unicode version of TeX), and in the Newton OS.
John H. Jenkins. The Unicode Character-Glyph Model: Case Studies. 15th International Unicode Conference, San Jose, CA, USA. August/September 1999. 27 pages.
[Microsoft, 1997] The TrueType Instruction Set
Describes the virtual machine that interprets TrueType instructions. It is best to read both the Microsoft and the Apple documentation.
Microsoft Corporation. The TrueType Instruction Set. Available online, last updated November 14, 1997.
[Unicode 2003] The Unicode Standard: A Technical Introduction
Explains the principles that were followed in designing Unicode.
The Unicode Consortium. The Unicode Standard: A Technical Introduction. Available online, last updated April 23, 2003.