Developing OpenType Fonts for Thaana Script

This document presents information that will help font developers create or support OpenType fonts for the Thaana script covered by the Unicode Standard. Thaana script is used to write the Dhivehi language and consists of base glyphs, vowels and a set of dotted letters used to transcribe Arabic.


Font developers will learn how to encode complex script features in their fonts, choose character sets, organize font information, and use existing tools to produce Thaana fonts. Registered features of the Thaana script are defined and illustrated, encodings are listed, and templates are included for compiling Thaana layout tables for OpenType fonts.

This document also presents information about the Thaana OpenType shaping engine of Uniscribe, the Windows component responsible for text layout.

In addition to being a primer and specification for the creation and support of Thaana fonts, this document is intended to more broadly illustrate the OpenType Layout architecture, feature schemes, and operating system support for shaping and positioning text.


The following terms are useful for understanding the layout features and script rules discussed in this document.

Base Glyph - Any glyph that can have a diacritic mark above or below it. Layout operations are defined in terms of a base glyph, not a base character, as a ligature may act as the base.

Character - Each character represents a Unicode character code point. For example, the 'haa' character is U+0780. A character may have multiple forms of glyphs.

Diacritic Mark (e.g. Fili) - A character that is positioned above or below a character to provide pronunciation guidance.

Glyph - A glyph represents a form of one or more characters.

Ligature - A combination of glyphs that join to form a single glyph. It is up to the font designer to create the ligatures appropriate for any particular font.

Shaping Engine

The Uniscribe Thaana shaping engine processes text in stages. The stages are:

  1. Analyze characters for valid diacritic (fili) combinations
  2. Shape (substitute) glyphs with OTLS (OpenType Library Services)
  3. Position glyphs with OTLS

The following descriptions will help font developers understand the rationale for the Thaana feature encoding model, and help application developers better understand how layout clients can divide responsibilities with operating system functions.

Analyze Characters

The unit that the shaping engine receives for the purpose of shaping is a string of Unicode characters, in a sequence. The contextual analysis engine verifies valid diacritic combinations. For additional information, see Invalid combining marks.

Shape Glyphs with OTLS

The first step Uniscribe takes in shaping the character string is to map all characters to their nominal form glyphs.

Next, Uniscribe calls OTLS to apply the features. All OTL processing is divided into a set of predefined features (described and illustrated in the Features section). Each feature is applied, one by one, to the appropriate glyphs in the syllable and OTLS processes them. Uniscribe makes as many calls to the OTL Services as there are features. This ensures that the features are executed in the desired order.

Position Glyphs with OTLS

Uniscribe next applies features concerned with positioning, calling functions of OTLS to position glyphs.

Positioning features:

  1. Kerning
    1. Apply feature 'kern' to provide pair kerning between base glyphs requiring adjustment for better typographical quality
  2. Mark to base
    1. Apply feature 'mark' to position diacritic glyphs to the base glyph

Invalid Combining Marks

Combining marks and signs that appear in text not in conjunction with a valid consonant base are considered invalid. Uniscribe displays these marks using the fallback rendering mechanism defined in the Unicode Standard (section 5.12, 'Rendering Non-Spacing Marks' of the Unicode Standard 3.1), i.e. positioned on a dotted circle.

For the fallback mechanism to work properly, a Thaana OTL font should contain a glyph for the dotted circle (U+25CC). In case this glyph is missing from the font, the invalid signs will be displayed on the missing glyph shape (white box).

In addition to the 'dotted circle', other Unicode code points recommended for inclusion in any Thaana font are LTR (left to right mark; U+200E) and RTL (right to left mark; U+200F).

Illustration that shows the dotted circle character, plus Unicode characters left to right mark and right to left mark with suggested glyphs.

If an invalid combination is found, like two 'aba filis' on the same base character, the diacritic that causes the invalid state is placed on a dotted circle to indicate to the user the invalid combination. The shaping engine for non-OpenType fonts will cause invalid mark combinations to overstrike. This is the problem that inserting the dotted circle for the invalid base solves. It should also be noted that the dotted circle is not inserted into the application's backing store. This is a run-time insertion into the glyph array that is returned from the ScriptShape function.

The invalid diacritic logic for Thaana is based on the rule that only one fili can be placed on a base glyph.


The features listed below have been defined to create the basic forms for the languages that are supported on Thaana systems. Regardless of the model an application chooses for supporting layout of complex scripts, Uniscribe requires a fixed order for executing features within a run of text to consistently obtain the proper basic form. This is achieved by calling features one-by-one in the standard order listed below.

The order of the lookups within each feature is also very important. For more information on lookups and defining features in OpenType fonts, see the Encoding section of the OpenType Font Development document.

The standard order for applying Thaana features encoded in OpenType fonts:

Feature Feature function Layout operation Required
Positioning features:
kern Pair kerning GPOS
mark Mark to base positioning GPOS X
[GSUB = glyph substitution, GPOS = glyph positioning]

Feature examples


Feature Tag: "kern"

The 'kern' feature is used to adjust amount of space between glyphs, generally to provide optically consistent spacing between glyphs. Although a well-designed typeface has consistent inter-glyph spacing overall, some glyph combinations require adjustment for improved legibility. Besides standard adjustment in either horizontal or vertical direction, this feature can supply size-dependent kerning data via device tables, "cross-stream" kerning in the Y text direction, and adjustment of glyph placement independent of the advance adjustment. Note that this feature would not be used in monospaced fonts.

The font stores a set of adjustments for pairs of glyphs (GPOS lookup type 2 or 8). These may be stored as one or more tables matching left and right classes, and/or as individual pairs. If both forms are used, the classes should be listed last, so as to provide a means to replace any non-ideal values that may result from the class tables. Additional adjustments may be provided for larger sets of glyphs (e.g., triplets, quadruplets, etc.) to overwrite the results of pair kerns in particular combinations. These should precede the pairs.

Screenshot of a Microsoft VOLT dialog for positioning adjustment. Pair adjustment is selected as the lookup type, and right to left display direction is selected. Several glyph pairs are specified using individual glyphs and glyph groups. The first glyphs in the pairs have their positions adjusted to the right.
Creating OTL kern feature with Microsoft VOLT

Mark to base positioning

Feature Tag: "mark"

The 'mark' feature positions mark glyphs in relation to a base glyph, or a ligature glyph. This feature may be implemented as a MarkToBase Attachment lookup (GPOS LookupType = 4) or a MarkToLigature Attachment lookup (GPOS LookupType = 5).

Screenshot of a dialog in Microsoft VOLT for specifying positioning adjustments. Anchor attachment is selected as the lookup type. A mark glyph is shown positioned above a base glyph using an anchor point.
Positioning mark to base using Microsoft VOLT


Appendix A: Writing System Tags

Features are encoded according to both a designated script and language system. The language system tag specifies a typographic convention associated with a language or linguistic subgroup.

Currently, the Uniscribe engine only supports the "default" language for each script. However, font developers may want to build language specific features which are supported in other applications and will be supported in future Microsoft OpenType implementations.

  • NOTE: It is strongly recommended to include the "dflt" language tag in all OpenType fonts because it defines the basic script handling for a font. The "dflt" language system is used as the default if no other language specific features are defined or if the application does not support that particular language. If the "dflt" tag is not present for the script being used, the font may not work in some applications.

The following tables list the registered tag names for scripts and language systems.

Registered tags for the Thaana script Registered tags for Thaana language systems
Script tag Script Language system tag Language
"thaa" Thaana "dflt" *default script handling
"DIV " Dhivehi

Note: both the script and language tags are case sensitive (script tags should be lowercase, language tags are all caps) and must contain four characters (ie. you must add a space to the three character language tags).

Appendix B: MVBoli.TTF (sample font)

The MVBoli font will be distributed with Microsoft Visual OpenType Layout Tool (VOLT) and is provided under the terms of the VOLT supplemental files end user license agreement. It is provided for illustration only, and may not be altered or redistributed.

MVBoli contains layout information and glyphs to support all of the required features for the languages supported. Each font should be designed as the font creator desires.

Some shaped glyph forms (such as ligatures) have no Unicode encoding. These glyphs have id's in the font, and applications can access these glyphs by "running" the layout features which depend on these glyphs. An application can also identify non-Unicode glyphs contained in the font by traversing the OpenType layout tables, or using the layout services for purely informational purposes.