Overview

This page describes the glyphs that must be present in a font for use with Symbian OS, and any special consideration that must be given to the metrics of the glyphs.

The main body of this document does not describe any features of supported languages in detail. See Appendix C - Description of Arabic and Hebrew scripts,
Appendix D - Description of the Thai script and Appendix E - Description of the Devanagari script for more details.

See Appendix G - Complete font repertoire for a complete list of all glyphs for all sets of characters described by this document.

Encoding

All fonts for general use in Symbian OS must use the Unicode 3.0 encoding.

Currently supplementary characters are not supported, so glyphs may only have code points below 10000 hex. Supplementary characters may be encoded in the Private Use Area, subject to the limitations described in the separate document. [PUA]

Basics

It is recommended that all the glyphs described by the Windows Glyph List Four (WGL4) are present in a font designed for Symbian OS, except those placed in the Private Use Area (U+F000, U+F001 and U+F002). These Private Use Area characters either are corporate logos or have official code points within Unicode.

Control codes

There is no need to define empty glyphs for control codes, with the exception of U+200C and U+200D, the "zero-width non-joiner" and "zero-width joiner" respectively. These two must be defined as empty glyphs.

Font metrics

To get the best results with Symbian OS, certain metrics values must be correctly defined within a font.

Bitmap fonts

For bitmap fonts, Symbian OS requires that fonts be provided in Adobe Bitmap Distribution Format (BDF). The mandatory SIZE and FONTBOUNDINGBOX metrics should be set accurately. In addition, Symbian OS makes use of a number of settings in the PROPERTIES section of a BDF font definition.

The following properties must appear:

The following properties should appear where appropriate:

For backwards compatibility reasons, some of these values do not actually have to be present because an attempt will be made to synthesize suitable values if they are not - but all new fonts should define all of them.

TrueType fonts

Symbian OS provides optional support by default for the TrueType font format by including a Symbian-created implementation of the FreeType rasterizer. Obviously it is recommended that fonts have all of their metrics correctly set but this implementation makes particular use of the following TrueType metrics and therefore requires that they be set correctly in TrueType fonts to be used with this rasterizer:

In the "head" table:
unitsPerEM
xMin
yMin
xMax
yMax

In the "hhea" table:
Ascender
Descender

In the "OS/2" table:
ulUnicodeRange1
ulUnicodeRange2
ulUnicodeRange3
ulUnicodeRange4
sTypoAscender
sTypoDescender
sTypoLineGap
usWinAscent
usWinDescent

Other TrueType-compatible rasterizers may be used instead of FreeType. If this is the case then the rasterizer/font combination is expected to provide the metrics specified by the interface by any means it cares to implement, although the use of the same TrueType internal metrics is encouraged.

OpenType fonts

See Appendix F - Brief description of OpenType
.
OpenType fonts come in two flavours depending on the format used for their glyph outlines: TrueType (TTF extension) or PostScript (OTF extension). From Symbian OS v9.2 the FreeType rasterizer supports both. The rasterizer also supports two extension interfaces: MOpenFontShapingExtension and MopenFontTrueTypeExtension. Any rasterizer supporting these extensions will automatically work with the Symbian-supplied "shaper" component for supporting OpenType glyph substitution and positioning.

Other shapers can be defined as plug-ins in order to support substitution and positioning for font formats other than OpenType.

Currently shapers are only invoked for Devanagari.

Other font formats

Symbian OS permits the use of other font formats but it is only able to make use of them if they are accompanied by a suitable rasterizer for that font format that complies with the Symbian OS Plug-In Rasterizer API. Any such rasterizer/font combination is required to provide the metrics specified by that interface.

Composite fonts

Composite fonts, fonts made up from ranges of other fonts stored separately, are currently not supported by Symbian OS.

System fonts

Fonts to be used as System fonts must cover all the languages supported by the target device, as currently system fonts are not locale specific.

"Missing character glyph"

The TrueType missing character glyph will be correctly rendered in appropriate cases. However, if this glyph is not present (or for bitmap fonts which do not have such a concept) the Private Use Area character U+F6DB will be displayed instead. See [PUA].

Supporting Western alphabets

Positioning of diacritics

Diacritics are placed by the rendering software according to the bounding boxes given in the fonts. The software will place a diacritic next to a base character so that their bounding boxes abut if and only if this diacritic is supposed to attach to its base according to the Unicode standard. If not, the software will leave a small gap between the bounding boxes.

Ligatures and kerning

Currently no ligatures are automatically produced for Western alphabets and no character pairs are kerned. Although "i" followed by a combining character will not currently remove the dot of the "i", it is recommended that the Turkish "dotless i" be always defined ready for when this is addressed.

Supporting Vietnamese

Vietnamese, supported much the same as Western alphabets, uses a character set listed in several non-contiguous Unicode ranges: Basic Latin (U+0000 toU+007F), Latin-1 Supplement (U+0080 to U+00FF), Latin Extended-[A|B] (U+0100 to U+024F), Latin Extended Additional (U+1E00 to U+1EFF), and Combining Diacritical Marks (U+0300 to U+036F). The Vietnamese currency symbol ("d?ng") is U+20AB. Latin glyphs are always pre-composed, so only the pre-composed forms are required, no special processing or rendering is necessary.

Supporting Chinese and Japanese

No special processing of Chinese and Japanese glyphs occurs (for example kerning of full width characters that only occupy half of the block such as brackets). Vertical text is not yet supported.

Supporting Korean

The "Hangul Jamo combining alphabet" at U+1100 to U+11F9 has no conjoining behaviour in the Symbian OS. There is no requirement from Symbian to supply glyphs at these code points. The need for glyphs in the conjoining block (U+1100 to U+11F9), compatibility block (U+3130 to 318E) and syllables block (U+AC00 to U+D7A3) are driven entirely from customer needs, including the needs of the Front End Processor (input method) to support intermediate forms.

Supporting Arabic and Hebrew scripts

Symbian OS supports Arabic and Hebrew scripts. Bi-directional text rendering is fully supported in the "Form" text-formatting component, and lower level utilities exist in the GDI component.

Arabic text supplied to the text rendering software is pre-processed to replace any medial, final or initial forms with the appropriate contextual variant as defined by Unicode.

The rendering for Arabic is suitable for the languages Arabic, Farsi, Persian, Sindhi and other languages that use the letters supported (see Appendix G - Complete font repertoire).

Urdu is also supported. The Urdu letters U+06C2 heh goal with hamza above and U+06C3 heh goal marbuta are not supported, but these are not in common usage. There is no support for nastaliq style (where each word is written on a sloping baseline).

Directionality

The font rendering software only supports the rendering of text from left to right. Other software is responsible for reversing right-to-left sequences ready for the font rendering software. Therefore, the advance of right-to-left glyphs must be positive, not negative.

Mirrored characters

All characters with mirrored versions defined within the Unicode standard have these substituted automatically during bi-directional reordering if applicable.

Characters with the mirrored property but without mirrored glyph variants are not substituted.

Contextual shaping and ligation for Arabic script

All characters that require contextual shaping in the range U+0600 to U+06FF have their correct contextual variants substituted, as of Unicode 3.0, as long as the contextual variants have codes in Unicode 3.0. See the table in Appendix G - Complete font repertoire for details.

The Lam-Alef ligature is substituted automatically, and then has contextual shaping applied.

The glyphs that result from ligation and contextual shaping are usually those described in the Unicode standard between code points U+FE70 and U+FEFE ("Arabic Presentation Forms-B") and U+FB50 to U+FBBF ("Arabic Presentation Forms-A: Glyphs for contextual forms of letters for Persian, Urdu, Sindhi, etc."). The more complicated substitutions suggested by the "Arabic Presentation Forms-A" after this first section are not applied. This means that the letters are positioned horizontally with respect to one another: a letter joining to the top of its succeeding letter is not supported.

However, the isolated forms of non-ligatures are represented by the glyphs found in the base U+0600 to U+06FF section. Therefore, Symbian does not insist that glyphs for the isolated forms within the U+FE70 to U+FEFE section be present.

Diacritics (points)

Symbian does not claim to support Arabic and Hebrew diacritics fully. If they are present in the text to be rendered, an attempt is made to render them in a sensible position. However, it may not be in a position that would be considered ideal for good typography.
The diacritic most likely to look wrong, rather than merely sub-optimal, is the Hebrew dagesh. This should be positioned inside its base character, and must therefore be positioned specially for each character. Although Symbian OS does not currently support this functionality, it is recommended that the glyphs U+FB2A to U+FB4F be present ready for such an implementation.

Arabic and Hebrew diacritics are not filtered out. If they are not present in the fonts, they will appear as the replacement glyph. Therefore, these diacritics must be present even if they are represented by empty glyphs.

Supporting Thai

The Symbian OS implements the font rendering output method defined in the WTT 2.0 specification. This specifies the rules the rendering software uses to work out valid and invalid base & combining character sequences. Rules are defined for all character combinations. This allows the software to avoid one glyph over-striking another. It also defines for each character the pen movement applicable.

Support for the rendering of Pali is included within the Thai rendering support.

Positioning of combining marks

Good Thai rendering requires that combining marks be rendered in a position appropriate to the surrounding characters, and certain base characters change form depending on the presence or absence of below vowels.

These different positions are not calculated by the software, each different position or form relevant to each character is given a different code point. One form or position for each character is given the official Unicode code point for that character. The other forms or positions are allocated Private Use Area code points.

Each Thai consonant is categorised in two ways: Firstly, whether or not it has a separate form appropriate for combination with below vowels and secondly, whether it has an "ascender in the above level" or an "ascender in the below level" or neither.

The different forms and their code points are specified in Appendix B - Thai code-point allocation and categorization.

Character font metrics are used to specify the positions of the combining marks. The origin of the combining mark is the pen position after the advance caused by the base character. This means that the combining mark will have negative X offset.

Invalid combining character sequences

Invalid combining character sequences (e.g. two dependent vowel characters in a row) are rendered as the correct first portion of the sequence followed by the Dotted Circle (U+25CC) character, to which is applied the incorrectly sequenced character. This is illustrated in Figure 1. Hence, it is essential that a glyph for the dotted circle be present in a Symbian OS font supporting Thai.

Pen advancement

The WTT 2.0 specification specifies which Thai characters are forward characters and which are dead characters.

Forward characters are characters with glyphs painted on the base line and occupy horizontal space. Thai characters in this category include consonants, leading & following vowels, digits and independent signs/symbols.

Dead characters are usually composed with a consonant. They have no horizontal advance relying on the consonants advance before being painted. Therefore, the metrics of these characters must ensure the glyph is drawn to the left of the pen origin by employing a negative offset to their bounding box.

Thai characters in this category include dependent vowels, tone marks and diacritics including their positional variants in the PUA.
See Appendix A - Example BDF segments for Thai characters. For example, BDF segments for forward characters and dead characters.

Supporting Indic scripts

Currently only Devanagari is supported amongst the Indic scripts. As discussed in OpenType fonts, Symbian OS v9.2 and onward supplies a shaper that implements OpenType support for Devanagari.

Baseline

OpenType allows the definition of multiple baselines. These are not invoked and there is no way to select a suitable baseline.

Nukta and eyelash Ra

Conversion of text from ISCII to Unicode is not as simple as most conversions. A sophisticated conversion framework would allow for the various multi-byte character strings defined in ISCII to be converted where possible to single Unicode characters. Symbian's CharConv framework is not so sophisticated. Therefore, decomposed versions of consonants containing nuktas should be expected.
Similarly, where Marathi is required, the sequence Ra+nukta+virama followed by a consonant (whether composed or decomposed) must form the eyelash Ra.

Appendix A - Example BDF segments for Thai characters

Appendix B - Thai code-point allocation and categorization

Appendix C - Description of Arabic and Hebrew scripts

Appendix D - Description of the Thai script

Appendix E - Description of the Devanagari script

Appendix F - Brief description of OpenType

Appendix G - Complete font repertoire