Fonts

Fonts

Font support on the various platform is varied. One issue is the the development system for the Builder may have Fonts that are not on the target run-time system, and the matching algorithm (dependent on the run-time program) may not select an acceptable substitute. It is best to limit fonts to family (e.g. serif vs. san-serif), or work with known target available fonts. Fonts are also not necessarily system transferrable, and there may be licensing issues with particular fonts. Also, with UNICODE support, some fonts may not be fully populated for all glyphs on the target system, resulting in inconsistent results.

The following outlines some known issues and implementation notes for Fonts on the target systems. Because there is no consistency or world standard on fonts, names, and support on a particular system, fonts can represent a challenge for implementers of cross-platform run-time targets.

Fonts on Windows

Because Windows fonts can typically be moved (or are available) for multiple Windows systems, the only real concern is matching the fonts on the development system (where the Builder is creating the board), and the run-time target system(s).

Fonts on Linux

Linux has a well designed font matching and labeling system, but due to licensing and varied support, not all fonts available on Windows may be available on a particular run-time Linux system. Also, full Unicode support for various glyphs can be limited, especially when mixing font styles and sizes. The default approach is to perform a match based on Linux font naming and try different sizes within that family. Trying different fonts, or working with more common fonts may yield thest best results when working on Linux run-times.

Fonts on Mac OS X

The font calling mechanism on Mac OS X is also different than Windows, although there is more font availability on Mac OS X. Trying different fonts, or working with more common fonts may yield thest best results when working on Mac OS X run-times.