Developing fonts > Specifications OpenType development (2 of 5): 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. 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. 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. ![]()
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.
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:
![]()
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.
![]() When the longer lookup is listed first, the ffi ligature is formed correctly. Next section: client support introduction | encoding | client support | suggested glyphs | tools
|