Developing OpenType Fonts for Odia Script

Consonant syllable:

• {C+[N]+<H+[<ZWNJ|ZWJ>]|<ZWNJ|ZWJ>+H>} +
• C+[N]+[A] + [< H+[<ZWNJ|ZWJ>] | {M}+[N]+[H]>]+[SM]+[(VD)]

Vowel-based syllable:

• [Ra+H]+V+[N]+[<[<ZWJ|ZWNJ>]+H+C|ZWJ+C>]+[{M}+[N]+[H]]+[SM]+[(VD)]

Stand Alone cluster (at the start of the word only):

• [Ra+H]+NBSP+[N]+[<[<ZWJ|ZWNJ>]+H+C>]+[{M}+[N]+[H]]+[SM]+[(VD)]

Where

{ }	zero or more occurrences
[ ]	optional occurrence
<|>	"one of"
( )	one or two occurrences
C	consonant
V	independent vowel
N	nukta
H	halant/virama
ZWNJ	zero width non-joiner
ZWJ	zero width joiner
M	matra (up to one of each type: pre-, above-, below- or post- base)
SM	syllable modifier signs
VD	vedic
A	anudatta (U+0952)
NBSP	NO-BREAK SPACE

Identify key positions inside syllable

Syllable structure consists of the following parts:

Reph + HalfConsonant(s) + MainConsonant(s) + BelowBaseConsonant(s) + PostBaseConsonant(s) + PreBaseReorderingRa + MatrasAndSigns

The consonant parts include all associated halants and nuktas. (For example, an instance of BelowBaseConsonant consists of a sequence of Halant + Below-base-forming Consonant.) All parts are optional, except the main consonant.

All parts are shown in the order they would occur within a syllable, with one qualification: depending on a font implementation, PreBaseReorderingRa may occur before all BelowBaseConsonants, after BelowBaseConsonants and before PostBaseConsonants, or after PostBaseConsonants. Also, a font may be implemented to re-order a Ra to pre-base position only in certain syllables and display it as a below-base or post-base form otherwise. Thus, final determination of whether an occurrence of Ra in a specific syllable can be treated as a pre-base reordering Ra can be made only after the 'pref' feature has been applied to that syllable.

There could be several main consonants in the case where more than one consonant doesn't have a half-, below-base, post-base or pre-base form. In a case of a cluster where the first consonant does not have a half form, the shaping engine will recognize it as the 1st 'full form' and go on to identify the 2nd full form consonant, if there is one. This information will then be used to determine the reordering behavior of the reph or any matras, vowel modifiers or stress marks.

All other elements are classified by their position relative to the base: pre-base (half forms and reordering pre-base Ra forms), below-base, above-base and post-base.

Indic clusters are subject to the following constraints:

• Only one reph is allowed per syllable.
• Only one pre-base reordering Ra is allowed per syllable.
• A nukta can be placed on a consonant, matra or independent vowel. It cannot be placed on a pre-composed nukta character.
• One matra from each positioning class is permitted (exception in the Kannada script). A composite matra is treated as belonging to all the classes from which its components belong.
• One syllable modifier sign is allowed per cluster.
• Vedic signs are combining marks (used for Sanskrit) that should be included in all Indic scripts.
• Danda and Double Danda are punctuation marks that should be included in all Indic scripts.

Reorder characters

Once the Indic shaping engine has analyzed the cluster as described above, it creates and manages a buffer of appropriately reordered elements (glyphs) representing the cluster, according to several rules (described below).

The OpenType lookups in an Indic font must be written to match glyph sequences after re-ordering has occurred. OpenType fonts should not have substitutions that attempt to perform the re-ordering. If a font developer attempted to encode such reordering information in an OpenType font, they would need to add a huge number of many-to-many glyph mappings to cover the general algorithms that a shaping engine will use.

1. Find base consonant: The shaping engine finds the base consonant of the syllable, using the following algorithm: starting from the end of the syllable, move backwards until a consonant is found that does not have a below-base or post-base form (post-base forms have to follow below-base forms), or that is not a pre-base reordering Ra, or arrive at the first consonant. The consonant stopped at will be the base.

   • If the syllable starts with Ra + Halant (in a script that has Reph) and has more than one consonant, Ra is excluded from candidates for base consonants.

2. Decompose and reorder Matras: Each matra and any syllable modifier sign in the cluster are moved to the appropriate position relative to the consonant(s) in the cluster. The shaping engine decomposes two- or three-part matras into their constituent parts before any repositioning. Matra characters are classified by which consonant in a conjunct they have affinity for and are reordered to the following positions:

   • Before first half form in the syllable
   • After subjoined consonants
   • After post-form consonant
   • After main consonant (for above marks)

3. Reorder marks to canonical order: Adjacent nukta and halant or nukta and vedic sign are always repositioned if necessary, so that the nukta is first.

4. Final reordering: After the localized forms and basic shaping forms GSUB features have been applied (see below), the shaping engine performs some final glyph reordering before applying all the remaining font features to the entire cluster.

   • Reorder matras: If a pre-base matra character had been reordered before applying basic features, the glyph can be moved closer to the main consonant based on whether half-forms had been formed. Actual position for the matra is defined as 'after last standalone halant glyph, after initial matra position and before the main consonant'. If ZWJ or ZWNJ follow this halant, position is moved after it.
   • Reorder reph: Reph's original position is always at the beginning of the syllable, (i.e. it is not reordered at the character reordering stage). However, it will be reordered according to the basic-forms shaping results. Possible positions for reph, depending on the script, are; after main, before post-base consonant forms, and after post-base consonant forms.
     1. If reph should be positioned after post-base consonant forms, proceed to step 5.
     2. If the reph repositioning class is not after post-base: target position is after the first explicit halant glyph between the first post-reph consonant and last main consonant. If ZWJ or ZWNJ are following this halant, position is moved after it. If such position is found, this is the target position. Otherwise, proceed to the next step.
     3. If reph should be repositioned after the main consonant: from the first consonant not ligated with main, or find the first consonant that is not a potential pre-base reordering Ra.
     4. If reph should be positioned before post-base consonant, find first post-base classified consonant not ligated with main. If no consonant is found, the target position should be before the first matra, syllable modifier sign or vedic sign.
     5. If no consonant is found in steps 3 or 4, move reph to a position immediately before the first post-base matra, syllable modifier sign or vedic sign that has a reordering class after the intended reph position. For example, if the reordering position for reph is post-main, it will skip above-base matras that also have a post-main position.
     6. Otherwise, reorder reph to the end of the syllable.
   • Reorder pre-base reordering consonants: If a pre-base reordering consonant is found, reorder it according to the following rules:
     1. Only reorder a glyph produced by substitution during application of the 'pref' feature. (Note that a font may shape a Ra consonant with the 'pref' feature generally but block it in certain contexts.)
     2. Try to find a target position the same way as for pre-base matra. If it is found, reorder pre-base consonant glyph.
     3. If position is not found, reorder immediately before main consonant.

Character reordering Classes for Odia:

_Characters_	_Reorder Class_
0B30 (reph)	AfterMain
0B47	BeforeHalf
0B3F, 0B56	AfterMain
0B41-0B43	AfterSubscript
0B3E, 0B40	AfterPostscript
0B57	AfterPostscript
0B01	BeforeSub

Shape glyph sequences (GSUB processing)

All characters from a string are first mapped to their nominal glyphs using the cmap lookup. The shaping engine then proceeds to shape (substitute) the glyphs using GSUB lookups.

The features for localized forms and basic shaping forms are applied one at a time to the cluster or a relevant portion of the cluster.

The results after basic shaping forms features have been applied impact the final syllable analysis in terms of final designation of Ra as a pre-base reordering form and final reordering positions for reph and matras. Next, the features for presentation forms are applied to the entire cluster simultaneously.

• Note: Since the presentation form features are applied simultaneously over the entire cluster, several features are operationally equivalent to a single feature. Multiple features are provided as an aid for font developers to organize the lookups they implement.

• Note: Final reordering occurs after features for basic shaping forms have been applied and before features for presentation forms are applied. Font developers must consider the effects of initial reordering (before any features are applied) and final reordering (after basic shaping forms features have applied) when they create GSUB feature and lookup tables.

These predefined features are described and illustrated in the Features section and are applied in the order below.

Shaping features:

Localized forms

1. Apply feature 'locl' to select language-specific forms.

Basic Shaping forms

1. Apply feature 'nukt' to substitute nukta forms of consonants.
2. Apply feature 'akhn' to substitute required akhand ligatures, or to substitute forms that take precedence over forms produced by features applied later.
3. Apply feature 'rphf' to substitute the reph glyph (above-base form of 'Ra').
4. Apply feature blwf' to substitute below-base forms.
5. Apply feature 'pstf' to substitute post-base forms.
6. Apply feature 'cjct' to substitute conjunct forms. (This is needed particularly for ligature conjuct forms when the pre-base consonant does not have a half form).

Presentation forms

1. Apply feature 'pres' to substitute pre-base consonant conjuncts and pre-base matra conjuncts. (ie. consonant and matra conjuncts to the left of the base glyph).
2. Apply feature 'abvs' to substitute above-base matra conjuncts, reph conjuncts, above-base vowel modifiers and above-base stress and tone marks.
3. Apply feature 'blws' to substitute below-base consonant conjuncts, below-base matra conjuncts, below-base vowel modifier forms and below-base stress and tone mark forms.
4. Apply feature 'psts' to substitute post-base consonant conjuncts, post-base matra conjuncts and post-base vowel modifiers.
5. Apply feature 'haln' to substitute the halant form of base (or conjunct base) glyph in syllables ending with a halant.
6. Apply feature 'calt' to substitute the contextual alternate of a consonant.

Position glyph sequences (GPOS processing)

The shaping engine next processes the GPOS (glyph positioning) table, applying features concerned with positioning. All features are applied simultaneously to the entire cluster.

The font developer must consider the effects of re-ordering when creating the GPOS feature and lookup tables (i.e., the glyphs will be in the order they were in after the GSUB presentation forms features were applied).

Positioning features:

Kerning

1. Apply feature 'kern' to adjust distances (e.g., to provide kerning between post- or pre-base elements and the base glyph).
2. Apply feature 'dist' to adjust distances. (NOTE - the feature 'dist' can be used in the same way as the 'kern' feature. The advantage of using the 'dist' feature is that it does not rely on the application to enable kerning. Therefore, if you want to make sure certain spacing adjustments will always be displayed, you should use the 'dist' feature).

Above-base marks

1. Apply feature 'abvm' to position above-base marks (above-base consonant forms, matras, vowel modifiers or stress/tone marks) on base glyphs or post-base matra).

Below-base marks

1. Apply feature 'blwm' to position below-base marks (below-base consonant forms, matras, vowel modifiers or stress/tone marks) on base glyphs or post-base matra).

Base elements

Commonly, a feature is required for dealing with the base glyph and one of the post-base, pre-base, above-base or below-base elements. Since it is not possible to reorder ALL of these elements next to the base glyph, we need to skip over the elements "in the middle" (reordering-wise).

The solution is to assign different mark attachment classes to different elements of the syllable and positional forms, and in any given lookup work with one mark type only. For example, in above-base substitutions we need only consider above-base elements most of the time.

Generally, it is good practice to label as "mark" any glyphs that are denoted as combining marks in the Unicode Standard as well as below-base/above-base forms of consonants. Then, different attachment classes should be assigned to different marks depending on their position with respect to the base.

For example, after the shaping engine has re-ordered elements within the cluster, matras will always occur before syllable modifier sign such as the candrabindu. In an actual sequence, though, potentially some other mark glyph, such as nukta, may occur between the matra and the candrabindu. Thus, when processing the matra and candrabindu, you may need to allow for the possibility that some other mark glyph(s) may occur between them. Using lookup flags, you can specify that a lookup should process only a certain class of marks, such as 'above-base marks', and ignore all other marks. In that way, a match will occur whether or not a mark from another class is present. Otherwise, the lookup would fail to apply.

Using Microsoft VOLT, you can assign glyphs to attachment classes.
In the example below this 'abvm' feature was set to process only TopMarks, therefore the presence of another mark class would be ignored. If Process ALL was used and another mark glyph followed the matra, this positioning lookup would fail to apply. This example comes from the Devanagari font Mangal.

Invalid combining marks

Combining marks and signs that do not occur in conjunction with a valid base are considered invalid. Shaping engine implementations may adopt different strategies for how invalid marks are handled. For example, a shaping engine implementation might treat an invalid mark as a separate cluster and display the stand-alone mark positioned on some default base glyph, such as a dotted circle. (See Fallback Rendering in section 5.13 of the Unicode Standard 4.0.) Shaping engine implementations may vary somewhat with regard to what sequences are or are not considered valid. For instance, some implementations may impose a limit of at most one above-base vowel mark while others may not.

To allow for shaping engine implementations that expect to position an invalid mark on a dotted circle, it is recommended that Odia OT fonts contain a glyph for the dotted circle character, U+25CC. If this character is not supported in the font, such implementations will display invalid signs on the missing glyph shape (white box).

In addition to the 'dotted circle' other Unicode code points that are recommended for inclusion in any Odia font are the ZWJ (zero width non-joiner; U+200C), the ZWNJ (zero width joiner; U+200D) and the ZWSP (zero width space; U+200B). For more information see the Suggested glyphs section of the OpenType Font Development document.

Effect of ZWJ, ZWNJ and NBSP on Consonant Shaping

Unicode defines specific behaviors for ZWJ and ZWNJ in relation to Indic scripts. The Indic-specific behavior retains the general behavior that ZWJ requests connection between text elements while ZWNJ inhibits connection between text elements.

1. The main intent of using ZWJ in this context is to prevent a ligature-conjunct from forming (and in Devanagari or Gujuarati, to request a half form, below-base form or post-base form instead). The Indic engine does not need to take any action to prevent ligature-conjuct formation: the presence of ZWJ will prevent GSUB substitution lookups from matching the input glyph sequence. If the first consonant does not have a half form, an overt-halant form should result, which would also happen with no particular action by the engine.
2. A secondary intent of using ZWJ in this context is to prevent the display of reph in the case that the first consonant is RA. If a cluster begins with RA H (halant) ZWJ, the engine must ensure that the 'rphf' feature is not applied, and that re-ordering for reph does not take place. Note that use of either joiner in this context should prevent formation and re-ordering of reph when RA is the first consonant.
3. The main intent of using ZWNJ is to prevent conjunct ligature or half forms from forming, and to display an explicit halant form instead. The shaping engine must take specific actions to prevent half forms for a sequence of Consonant + Halant + ZWNJ.

ZWJ can also be used to display a mark, sub- or post-base form in isolation however, sequences to display them must begin with a no-break space (NBSP). This is because marks, sub- and post-base forms have a 'zero-width' so must be placed on the NBSP. For example, to get a shape of E-matra without the dotted circle one should type NBSP + E-matra.

In the illustration below the E-matra is displayed without the dotted circle by using the NBSP.
The combination of NBSP and ZWJ is used to display the below-base form of Ra in isolation.

Features

The features listed below have been defined to create the basic forms for the languages that are supported on Devanagari systems. Regardless of the model an application chooses for supporting layout of complex scripts, the shaping engine requires a fixed order for executing features within a run of text to consistently obtain the proper basic form.

The features of the basic shaping forms are applied one at a time to the cluster or portion of the cluster. The result impacts the analysis in terms of the conjoining behavior and final reordering. The features of the presentation forms are applied next, to the entire cluster simultaneously. Mandatory features must always be applied; the discretionary presentation-forms features listed should be applied by default, but can be suppressed by a client (normally at the discretion of the user).

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.

OpenType features used for Odia scripts, applied in the following order:

**Feature**	**Feature function**	**Layout operation**
Localized forms:
locl	Localization form substitution	GSUB
Basic shaping forms:
nukt	Nukta form substitution	GSUB
akhn	Akhand ligature substitution	GSUB
rphf	Reph form substitution	GSUB
blwf	Below-base form substitution	GSUB
pstf	Post-base form substitution	GSUB
cjct	Conjunct form substitution	GSUB
Mandatory presentation forms:
pres	Pre-base substitution	GSUB
abvs	Above-base substitution	GSUB
blws	Below-base substitution	GSUB
psts	Post-base substitution	GSUB
haln	Halant form substitution	GSUB
Discretionary presentation forms:
calt	Contextual alternates	GSUB
Positioning features:
kern	Kerning	GPOS
dist	Distances	GPOS
abvm	Above-base mark positioning	GPOS
blwm	Below-base mark positioning	GPOS
[GSUB = glyph substitution, GPOS = glyph positioning]

Feature examples

Many of the registered features described and illustrated in this document are based on the Microsoft OpenType font Kalinga. 'Kalinga' contains layout information and glyphs to support all of the required features for the Malayalam script and language systems supported.

The illustrations in the following examples show the result of that particular feature being applied. Features must be written to match glyph sequences after re-ordering has occurred. Note that the input context for a feature may be the result of a previous feature having already been applied.

Localized forms

Feature Tag: "locl"

This feature is used in association with OpenType language system tags to trigger lookups that will select alternate glyphs needed for language-specific typographic conventions. The 'locl' should not be used in association with the default language system, but only used with other language system tags. See the Appendix of this document for language system tags associated with the Odia script.

Basic shaping forms

Nukta

Feature Tag: "nukt"

The nukta alters the way a preceding consonant or vowel is pronounced. The most common nukta forms have been defined as separate characters in Unicode with their own code points. All consonants, as well as akhand forms should have an associated nukta form.

• Note: Rather than using substitution, nukta forms can also be created by positioning the nukta as a below-base mark on the base glyph using the 'blwm' positioning feature

The input context for the nukt feature always consists of the full form of the consonant. The half form of nukta consonants will be substituted using the half feature.

Nukta feature applied substitutes Dda + nukta with a pre-composed glyph (Rra):

Akhand

Feature Tag: "akhn"

An akhand is a required consonant ligatures that may appear anywhere in the syllable, and may or may not involve the base glyph. Akhand ligatures have the highest priority and are formed first; some languages include them in their alphabets.

The input context for the akhand feature always consists of the full form of the consonant. The half forms of Akhand ligatures will be called later in the half feature.

Because the akhand feature is applied early in the sequence of features and is applied over the entire cluster, it can also be used to create certain forms that must take priority in particular contexts over forms that would be created during subsequent feature application.

Using the 'akhn' feature; Ja + halant + Nya is substituted with the ligature JaNya:

Reph

Feature Tag: "rphf"

Applying this feature substitutes the Reph glyph. If the first consonant of the cluster consists of the full form of Ra + Halant, this feature substitutes the combining-mark form of Reph. In addition, the position of the Reph glyph can be adjusted with the 'abvm' GPOS feature.

The input context for the Reph feature always consists of the full form of Ra + Halant.

The 'rphf' feature substitutes the mark glyph form of Ra, when Ra is the first consonant in a syllable:

Below form of consonant

Feature Tag: "blwf"

This feature substitutes the below-base form of consonants in Odia. The input context for the below-base feature consists of Halant + Consonant, preceded by a consonant. If the below-base consonant and the preceding consonant form a ligature, it will be substituted later using the feature 'blws'.

• Note: If the preceding consonant has a 'nukta' the resulting glyph will be in halant-form and not below-base form. See Example 3.

Example 1- Halant + Ra (following a consonant) is substituted with the below-base form of Ra (Ra-phala):

Example 2- The 'blwf' feature substitutes the below-base form of Ka in the sequence; Gha + Halant + Ka:

Example 3- If the Ka is followed by a nukta the below-form of Ka is NOT substituted. Instead the full-form Ka with nukta is displayed along with the Halant-form of Gha:

Post-base form of consonant

Feature Tag: "pstf"

Applying this feature substitutes post-base forms, such as the 'Odia Yya'.

The post-base form of the Yya is substituted, when it is the last consonant in a syllable:

Conjunct forms

Feature Tag: "cjct"

Apply feature 'cjct' to substitute conjunct forms where the first consonant in the consonant-cluster pair does not have a half form. This feature allows for control over re-ordering of reph and pre-pended matras in case of consonants that do not take half forms yet do form conjunct ligatures in combination with certain following consonants.

Presentation forms

After the glyphs have been reordered, the presentation lookups are applied to provide the best typographic rendering of the text. The features of the presentation forms are applied to the entire cluster simultaneously, executing lookups within each feature in the order that they are specified in the font.

The pres, abvs, blws, psts and haln features are all mandatory for software implementations: they are required for correct script behaviour and none should ever be treated as discretionary. Because of this and because they are all applied simultaneously over entire clusters, they are not functionally different: a set of lookups could be divided between these features or grouped together under one of them with no difference in effect. These multiple features are provided, however, as an aid to the font developer for organizing lookups based on the combinations of glyphs they apply to. There are no specific requirements on how each should be used; the examples provided below illustrate typical usage, however.

Pre-base substitutions

Feature Tag: "pres"

This feature is used to substitute pre-base consonant conjuncts made with half forms, the type most common in Devanagari. The resulting conjunct can be in full or half form. While there are no half-forms in Odia, this feature is made available to allow font developers options for typographic preferences

This feature can also be used to select variant forms of Matras, or pre-composed ligatures of Matras with certain bases.

Above-base substitutions

Feature Tag: "abvs"

This feature is used for glyph substitutions involving above-base marks. Such substitutions might be used to select contextual forms of marks, to create mark-mark ligatures, or to create mark-base ligatures. Specific context-dependent forms or below-base consonants are handled by this lookup as well.

Example 1- 'abvs' mark ligatures; ikaar + reph + candrabindu substituted with a conjunct:

Below-base substitutions

Feature Tag: "blws"

This feature is used for glyph substitutions involving below-base marks or consonants. Such substitutions can be used to create conjuncts of base glyphs with below-base consonants, below mark ligatures or below mark-base ligatures. Specific context-dependent forms are handled by this lookup as well.

Example 1- 'blws' substitution to create below-base consonant conjuncts (Ka + Ta-phala):

Example 2- 'blws' substitution to create below-base mark conjuncts (Ra-phala + Ukaar):

Example 3 - contextual 'blws' substitution; Using MS Volt, alternate below-base forms are substituted based on the context. Note; in this example 'glyph groups' are used for the context:

Post-base substitutions

Feature Tag: "psts"

This feature is used to substitute post-base consonants or matras. Such substitutions can be used to create conjuncts of base glyphs with post-base consonants or post-base matra ligatures. It can also be used to specify contextual alternates of post-base forms.

Example 1 - 'psts' substitution to create post-base conjuncts (Dha + Yya-phala):

Example 2 - 'psts' substitution to create post-base matra conjuncts (reph + candrabindu + Au-length mark):

Halant form of consonants

Feature Tag: "haln"

This feature is used to substitute the halant form of a base (or conjunct base) glyph in syllables ending with a halant. Halant forms can also be created by positioning the halant as a below-base mark on the base glyph using the 'blwm' positioning feature.

This feature is applied only on the base glyph if the syllable ends with a halant.

Example 1 - 'haln' feature used to substitute halant form of base glyph:

Contextual Alternates

Feature Tag: "calt"

Unlike the previous presentation lookups, the 'calt' feature is optional and is used to substitute discretionary contextual alternates. It is important to note that an application may allow users to turn off this feature, therefore should not be used for any obligatory Odia typography.

Positioning features

Distances

Feature Tag: "dist"

This feature covers positioning lookups that adjust distances between glyphs, such as kerning between pre- and post-base elements and the base glyph. Note; the feature 'dist' can be used in the same way as the 'kern' feature. The advantage of using the 'dist' feature is that it does not rely on the application to enable kerning.

Above-base marks

Feature Tag: "abvm"

This feature positions all above-base marks on the base glyph or the post-base matra. The best method for encoding this feature in an OpenType font is to use a chaining context positioning lookup that triggers mark-to-base and mark-to-mark attachments for above-base marks.

'abvm' lookup in MS Volt using 'Anchor Attachment' for adjusting positions of above-marks over bases:

Below-base marks

Feature Tag: "blwm"

This feature positions all below-base marks on the base glyph. The best method for encoding this feature in an OpenType font is to use a chaining context positioning lookup that triggers mark-to-base and mark-to-mark attachments for below-base marks.

Example 1 - 'blwm' lookup in MS Volt using 'Anchor Attachment' for positioning below-marks with bases:

Example 2 - - contextual 'blwm' positioning in MS Volt using 'Anchor Attachment' for positioning nukta when followed by certain below-base matras:

Examples of Odia syllables

Complex Odia syllable formation is possible using the wide range of features available in OpenType. The following examples show how the shaping engine applies the OpenType features, one at a time to the input string. These combinations do not necessarily represent actual syllables or words, but are meant to illustrate the various OpenType features in a Odia font.

Example #1:

Example #2:

Appendices

Appendix A: Writing System Tags

Features are encoded according to both a designated script and language system.

Currently most shaping engine implementations only support the "default" language system 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 table lists the registered tag names for script and language systems.

• Note: Odia script is supported only using new Indic shaping behavior, for which the script tag 'ory2' is used. The script tag “orya” was registered for use with the old Indic shaping behavior, but the old shaping behavior was incompatible with requirements of Odia script. Hence, the script tag “orya” is never used.

Registered tags for the Odia script		Registered tags for Odia language systems
**Script tag**	**Script**	**Language system tag**	**Language**
"ory2"	Odia	'dflt'	*default script handling
		'SAT '	Santali
		'KUI '	Kui
		'SAN '	Sanskrit

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).