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.
Top of page
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.
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.
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 supportintroduction | encoding | client support | suggested glyphs | tools
Last updated 21 December 2001.
Top of page