Internationalization for Embedded Systems (Part Three): Fonts

18 December 2013
| |
Reading time: 3 minutes

Having looked at character sets in part one and encoding methods in part two, let’s talk a bit about fonts, another important aspect of internationalization. And again, there are some issues which need a bit more attention than with non-embedded software development.

What is a font?

The Unicode consortium defines font as “A collection of glyphs used for the visual depiction of character data. A font is often associated with a set of parameters (for example, size, posture, weight, and serifness), which, when set to particular values, generate a collection of imagable glyphs.” (http://www.unicode.org/glossary/#font).

In short, a font defines how to display (or print) characters. While the selection of a typeface (the visual “style”) may only have a small technical impact and can be defined late in the project, there are at least two questions we should think about as early as possible:

1. Bitmap font or outline font?
2. Do we need/Can we afford to do anti-aliasing or not?

Bitmap font or outline font?

There are two basic ways of representing fonts in computers: bitmap fonts and outline fonts. They have very different properties and you should know the consequences of choosing either of them.

In a bitmap font, each glyph (visualization of a character) is stored as a matrix of pixels. Each pixel requires 1 bit (for monochrome glyphs without anti-aliasing) or more (for anti-aliased or colored glyphs). For high-quality output, the bitmap font must have exactly the same size as the characters should have on the screen. This is because scaling distorts the glyphs and costs performance. If the UI-design requires several font sizes, one font is needed for each size. This can lead to a dramatic increase in memory requirements, especially for large fonts (e.g. for Chinese). However, bitmap fonts are very easy to display. No complex rendering engine is required and the result on the screen is very predictable. This simplicity makes bitmap fonts very attractive for small and for safety-critical embedded systems. On PCs, bitmap fonts are hardly used anymore.


A bitmap font is basically a matrix of pixels

In an outline font, each glyph is described mathematically as a sequence of line segments, arcs, and curves. The resulting outline is scaled to the desired output size, filled with the drawing color, and rendered as a bitmap. Outline fonts can be displayed at high quality in practically arbitrary sizes and typically require less memory than bitmap fonts. However, a rendering engine (like the open-source FreeType) is required for displaying the glyphs. Rendering is complex and requires more processing power than displaying bitmap fonts. Often, the font renderers provide additional optimizations based on meta-data in the font like hinting or kerning. While they usually improve the quality, they can sometimes lead to surprising results. Particularly for small font sizes or low screen resolutions in combination with complex (e.g. Chinese) characters, the rendered glyphs can easily become ugly or even unreadable.

An outline font defines glyphs with lines and curves

An outline-font defines glyphs with lines and curves

Should I use anti-aliasing?

Anti-aliasing is a technique for making text appear smooth on a pixel display. This is achieved by allowing for transparent pixels at the edges of the glyphs. While anti-aliased text looks much better and is often more readable than non-anti-aliased text, this feature can be expensive to implement. For small systems it might be simply impossible. When using bitmap fonts, anti-aliasing requires considerably larger font files because the transparency levels are encoded in the font. Antialiasing requires computing the final output color of a pixel not only based on the font color but also based on the color of the background pixel (because of transparency). Unless the device provides special hardware support for this (e.g. hardware layers), it is necessary to read the current background color from the display memory (which may be slow), calculate the new color and then write the resulting color back to the display memory.

Be aware that clients often expect antialiased text without explicitly telling you so because they’re just so used to it from their PCs and mobile phones. It helps to have a prototype or PC simulation for demonstrating the effect of antialiasing.

That was the last part of this small series on internationalization for embedded systems. If you have any remarks, additions or if you feel an important aspect has been missed, please leave a comment.

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »