OpenJDK: Font Scaler Replacement Project

Anencumbrance. This Project became inactive shortly after the featurewas delivered intoJDK 7 and wassubsequentlydissolved Oct 2023. Discussion about font rasterization may befound onclient-libs-dev.

At this time, the project is essentially complete, asfreetype has been implemented as a replacement. Soon we will removethis project and transfer bugs and improvements into the scope ofthe 2D group.

Java 2D incorporates technology that converts scalable outlinefonts to a specified size and fits this outline to a pixel grid toproduce a raster for subsequent blitting. Hence the terms fontscaling and rasterization.

The goal of thisproject is to create anopen source JDK text rasterization subsystem. The existingimplementation was licensed by Sun from a 3rd party and can not bereleased as open source.

This project is of a temporary nature and will be open until allmajor objectives are accomplished.

Background

The current font rasteriser is a native library licensed for use byJava 2D. The rasterizer works with Truetype and Type1 font formats,providing a means to obtain bitmap, outline and metrics for aparticular glyph in the particular rasterization mode. Supportedrasterization modes are: black&white, greyscale antialiasing,and subpixel antialiasing. The raterizer is also capable ofperforming arbitrary affine transforms and applying style tooutlines (e.g. bolding or italicizing). The proprietaryimplementation fully supports Truetype hinting and limited Type1hinting.

The rasterizer module has tight connections with several othermodules. In particular:

font management subsystem: Provides higher level API on top of rasterizer (i.e. rasterizerinterface is almost entirely defined by the needs of thissubsystem). Triggers creation of native state and keeps pointers tonative state in the java objects.
This also includes infrastructure such as bitmap caching andcommunication to the "blitting" code.

text layout engine: Directly uses rasterizer on the native layer to access sometruetype tables fromt the font file. Note that this is independentfrom rasterization of a glyph.

java2d disposer: This is an internal mechanism for disposing of graphics-relatedresources used by Java2D. The rasterizer relies on it to ensurethat native resources are properly released.

The current implementation has better support for Truetype in thejava layer. In particular, mapping from char codes to glyphs isperformed without access to the native library. For Type1 fontssome additional work is delegated to the native rasterizer library.

Note, that input data is not necessarily valid or well-formedand problems can be hard to detect beforehand. Given that therasterizer is largely native code, unexpected problems often leadsto a crash. Robustness is one of the important requirements, andthe current implementation is addresing it on several differentlevels:

Initial validity checks are performed by the font managementsubsystem. Malformed fonts are rejected.
If a problem is detected in the runtime then the font issubstituted by the default font. The malformed font is then removedfrom the list of known fonts.
This is tricky because removing fonts requires deleting nativestate, and some of the other subsystems may be keeping pointerspointers to it.

Requirements and objectives

The main objectives are:

Provide a reasonable alternative to the proprietary library(feature and quality wise)

Requirements for solution:

passes JCK
should allow usage of old rasterizer by commercial JDK.
should be cross platform
should be reasonably robust to be used on a variety of targetedplatforms

Also, it is desired to minimize the import of 3rd party code intothe OpenJDK workspace, i.e. link with external binary library(without any modification to this library).

Overall, we are trying to refactor the logic of working withproprietary code in the way which simplifies plugging anotherimplementation of the font rasterizer instead. But we want tominimize changes to other subsystems to avoid risk of introducingincompatibilities.

Approach

We identifiedfreetype as themost viable cross-platform alternative. It supports the requiredfont formats and rasterization modes. Moreover, it is already usedby the native desktops on Linux and OpenSolaris.

Technically, the native part of rasterizer-related code is splitbetween fontmanager and rasterizer specific library (t2k forproprietary rasterizer). As part of refactoring we separated JNIcalls to the rasterizer-specific and shared parts. Most of therasterizer-specific calls will are performed through implementationof the newly added FontScaler interface.

Note that there are some caveats. In particular, the native textlayout engine needs to obtain pointers to certain truetype tables.(There is no need to process these tables. The contract is toreturn the pointer to the table in the truetype format.)

The current implementation is based on two notions - FontScalerand FontStrike. FontScaler is specific to particular physical fontfile (or data stream). FontStrike is specific to not just the fontfile but also to a particular size, style and rasterization mode.There could be more than one strike per same scaler.

This additional context is available (as native object) on everycall to the rasterizer library and it is used to set parametersbefore processing particular request.

We expect that any scaler implementation will handle errorsinternally. It should throw an exception if the font (i.e. scaler)becomes unusable and make sure native resources are released.

The solution is to use freetype as a separate binary library(and probably use freetype library installed on the platform (ifavailable)). So, hopefully there will be only a fewfreetype-specific files in the OpenJDK workspace (native glue codeand java wrapper (implementation of FontScaler)).

Issues

We do not expect freetype to be identical in behaviour to theexisting rasterizer, Eg,

glyph images may differ
metrics may differ
set of displayable glyphs may differ

It is likely that resolving some of these may require changes inthe freetype library. Also, freetype's API is not frozen andtherefore different library versions might be incompatible. Havingsaid that, these differences are expected to be small insignificance, and few in number.

Status

How to contribute?

You can help by:

participating in the discussions on the mailing list(font-scaler-dev(at)openjdk.org)
testing and reporting bugs
suggesting code improvements.
improving or suggesting improvements tofreetype developers

Note that this project usesOpenJDKcontribution rules. Please see them for further details.

Community

Mailing lists
- font-scaler-dev

Movatterモバイル変換