Embedded Development: What font type should I use in an embedded GUI project?

In embedded development, fonts are a key component of embedded GUI development, and we see a lot of confusion when it comes to understanding fonts. What is the difference between bitmap images and rendered graphics? How does text rendering affect memory usage and the quality of the user experience?

How font rendering works

If you think about a string rendered on a computer screen, the string is just a collection of individual glyphs representing each character . They are essentially mini images, but they are encoded differently than what you see in PNG image files. For font files, only the data needed to render them as mini-images at runtime is required.

font file format

For regular images, there are a variety of formats, including PNG, JPEG, and bitmap. For fonts, there are a whole bunch of different formats. The two main types of embedded systems are: TrueType, developed by Apple, and OpenType, jointly developed by Microsoft and Adobe. Both font file formats contain only the data of the font - if the file also contains images of the glyphs, the font file will be very large.

From font file to screen

In embedded development, since font files only contain raw data, GUI applications usually require a font engine to render fonts. The font engine extracts the data from the file and constructs glyphs (mini images) in memory at runtime, which are then pushed to the display.

When the font is rendered for the first time, it is best to cache the result in memory so that the next time it is needed, the application It can be fetched from memory instead of having to calculate the glyph data from scratch.

Caching and pre-rendering fonts

The use of caching can be traced back to the similarity between images and fonts. In the same way we have to decode compressed image formats like PNG or JPEG, we need a local cache for font glyphs.

In embedded development, caching data uses RAM, but if your hardware doesn't have enough space, you can decide to run Glyph images are pre-rendered and stored in bitmap images contained within the application. This way your application can pull fonts directly from Flash or storage without taking up precious RAM cycles. In other words, font glyphs don't require any memory - the font engine fetches them directly from storage.

It should be noted that bitmap images are only alpha data, so if you want to colorize the font, you need to store the glyph The desired alpha value for the image or mini-image to render to the screen.

Pre-rendering has the advantage of saving RAM and the computational cost of decompressing and rendering font glyphs, but the disadvantage is the storage required for bitmaps space.

3 factors to consider when it comes to font quality

1. The type of embedded GUI that the embedded development team is creating

2. The font size being used

3. The type of font being used

For example, if your team is trying to save storage space by pre-rendering fonts, there will be a trade-off in quality. If you go from 8-bit to 4-bit alpha you probably won't see much of a compromise, but when you go from 2-bit to 1-bit there is a significant quality trade-off.

Tips to save space when pre-rendering fonts

1. Store less bits for alpha map

The number one way embedded development teams can save storage space during pre-rendering is by storing fewer bits for the alpha map. You can experiment with 4-bit, 2-bit and 1-bit alpha levels to see how much space is saved. However, lower levels reduce font clarity, so it's best to verify the results on an emulator or hardware to see which alpha works best for your user experience.

Comparison of alpha levels of different fonts

We compared the visual effects of different bit depths. The upper left corner is a TrueType font rendered by the font engine and stored in memory, no pre-rendering. Other results show 8-bit, 4-bit, 2-bit and 1-bit pre-rendered bitmap scenes.

With 1 bit depth you lose some clarity and introduce fonts around rounded characters like C, O or Q jaggedness. Essentially, this is the result of a 1-bit encoding that just gives you an "on or off switch" where you either draw that pixel or don't? This makes drawing rounded edges or circles very tricky.

In an 8bit scene you have 255 alpha values, allowing for nicely rounded corners in the overall result and smoothness.

What is the difference between TTF and 8-bit alpha?

There is no difference between TTF and 8-bit schemes. They are completely equivalent, since TTF generates 8-bit alpha maps. When a font engine reads data from a font file and creates a pictograph image, it is actually creating a specific 8-bit alpha image of the glyph, very similar to the pre-rendered version.

When it comes to smaller fonts or text, in some cases you will see loss or degradation of image quality . In embedded development, the quality loss depends on your embedded UI, the font sizes you use, and the type of fonts you use. It varies depending on what you want to happen in the GUI.

2. Minimize the number of characters to reduce space

The second way to reduce storage space is to minimize the number of characters. Fonts come with lots of glyphs, or lots of shorthand symbols used in astrology but your user interface may not actually need them.

If you have the thermostat as an embedded GUI item, you don't need to use all the characters - for example, just 0 to 9. This means you can strip the unused astrological shorthand symbols to pre-render and store only these ten characters.

Use open source tools, such as FontForge, that allow you to browse and modify fonts, create your own, and pull your unwanted content.

This only works if you know in advance exactly which characters are required. In embedded development, if you don't know what kind of text you're dealing with, or if you have a dynamic GUI where the text or point size changes frequently, you have to render ahead because the application doesn't know it needs to What.

Font optimization for embedded GUI development projects

When optimizing fonts at runtime, bitmap fonts are much faster than rendering through the engine because there is no precomputation stage. Load times and memory lookups are much faster.

A quick rule of thumb for choosing between runtime font rendering and pre-rendered bitmaps: Do you have more Flash or More RAM?

If you have more RAM: use the font engine to render the scene

If you have more Flash: use a pre-rendered bitmap scene

One thing to consider is overall UX design. Does it require a lot of dynamic fonts and sizes? If so, the font engine approach might be a better strategy for you.

If your embedded GUI project uses dynamic text throughout the user interface, such as using internationalized languages, various font types or dynamic behavior in general, it cannot be prerendered. If so, your best bet is to use a font engine. When using a font engine, you will want to use the cache attribute to limit the amount of RAM so that small embedded devices can still be accommodated.

Conclusion

Finally, in embedded development, fonts used for embedded GUI development are flexible and resemble images. Fonts are used not only for text, but also for graphic design elements in embedded GUIs.