Click Here to Install Silverlight*
United StatesChange|All Microsoft Sites
Microsoft

Typography Home Typography Home

Developing fonts > Specifications

OpenType development (2 of 5):
Encoding

Much of the knowledge about laying out text and the semantics of languages is embodied in the system components. This model ensures consistency in the layout operations that are required to arrive at the basic form, and relieves a font developer from having to define generalized script rules within a font (as is the case with Apple TrueType GX fonts).

Some clients may introduce their own knowledge or preferences regarding script layout; and OpenType Layout fonts may contain layout features that duplicate or override those applied by OS services. The layered structure of OS services supporting text-layout allows a client to choose what layout information to use, and how to apply it. However, such architecture also presents the possibility that duplicate feature information and layout intelligence may exist in more than one place.

At a minimum, font developers should be able to expect that applications have knowledge of (or services for executing) script rules as defined in the Unicode Standard. Application developers should be able to expect that fonts have glyphs and positioning information representing layout features as defined by the Unicode Standard.

Features

All of the features described in each of the script or language documents are "registered" and supported by Uniscribe and clients of USP, such as RichEdit. Thus, they provide a means for applications to work with operating system services to layout complex scripts.

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. The feature order is different for each script or language system and is described within those documents.

Top of page

Ordering lookups

Following the OpenType specification, the font developer defines the lookup sequence in the lookup array to control the order a text processing client uses to apply lookup data to glyph substitution and positioning operations. The order of the lookup within the feature tag is critical for desired processing. The lookup you define first will take priority.

Ordering lookups
Example: If you had 2 ligatures AB + BC defined in your lookup table, with the BC listed first, and you typed ‘ABC’, you would only get the BC ligature, and not the AB, because the B was already converted into the BC ligature.

Top of page

Ordering ligatures and conjuncts

To ensure that ligatures and conjuncts are formed properly, substitutions must be ordered so those with higher priority take precedence. It is also important to form longer lookups before shorter ones.

When forming ligatures, lookups must be encoded as follows:

  • The first substitution in a lookup maps the longest string of component characters to the appropriate glyph. The next substitution provides the glyph corresponding to the next longest string of characters, and so on. This is very important because the search process through the lookups terminates with the first match.
  • For consonant conjuncts, full-form conjuncts must precede half forms.
Ordering ligatures
For fi & ffi ligatures, feature tag ‘liga’, if you ordered 'uni0066, uni0069 -> uniFB00' before 'uni0066, uni0066, uni0069 -> uniFB03' the ffi ligature would not be formed, because the search process stopped with the fi.
Ordering ligatures
When the longer lookup is listed first, the ffi ligature is formed correctly.

Next section:  client support

introduction | encoding | client support | suggested glyphs | tools


Last updated 21 December 2001.

Top of page


© 2017 Microsoft Corporation. All rights reserved. Contact Us |Terms of Use |Trademarks |Privacy & Cookies