Home

Contact Us

General

Initiative B@bel

WSI Guidelines

Encoding

Principles

Unicode

Training

Tutorials

PUA

Conversion

Resources

Utilities

TECkit

Maps

Resources

Input

Principles

Utilities

Tutorials

Resources

Type Design

Principles

Design Tools

Formats

Resources

Font Downloads

Gentium

Doulos

IPA

Rendering

Principles

Technologies

OpenType

Graphite

Resources

Font FAQ

Links

Glossary


NRSI: Computers & Writing Systems

SIL HOME | SIL SOFTWARE | SUPPORT | DONATE

You are here: General > WSI Guidelines
Short URL: http://scripts.sil.org/WSI_Guidelines_Sec_9_2

Guidelines for Writing System Support: Technical Details: Smart Rendering: Part 2

Martin Hosken, Victor Gaultney, 2003-09-05

Contents

9.2   Glyph processing—Dumb Fonts

Glyph processing is where the WSI developer can intervene. The traditional approach taken to glyph processing has been very simple:

  • For each glyph in the string, set its vertical position to be the same as the previous glyph, and set the horizontal position to be directly after the previous glyph in the string.

Notice that this does not imply any particular directionality. Thus if we are rendering left to right, the new glyph will be placed to the right of the previous one, while if we were rendering a right to left script, then it would be to the left. For dumb fonts, this directionality is fixed for each string.

Dumb fonts, therefore, can be said to have the following characteristics:

  • One-to-one codepoint to glyph association
  • Simple sequential positioning

As a result of these limitations, WSI developers have devised new encodings which work within the limitations and allow for the rendering of more complex scripts. For example, there may be different codepoints associated with different positions of the same glyph so that diacritics are positioned approximately correctly. Likewise, variant forms of glyphs will each have their own codepoint. The effect of creating such encodings has been a proliferation of encodings, often associated with a particular font or family of fonts. Thus the interpretation of data requires constant reference to its special encoding.

Another problem with such a scheme is that there can be no more glyphs than there are codepoints in the encoding. Most of these systems used older, 8-bit encodings which have a maximum of 256 codepoints, and were limited to 256 glyphs. This is particularly problematic for writing systems which require more than 256 glyphs. Ethiopic requires 600-1200 separate symbols. Devanagari has numerous conjunct forms that cannot fit within a 256 glyph limit. Both of these writing systems can be accurately encoded using less than 256 codes, but cannot be displayed correctly without the additional ligatures and separate forms needed for letter combinations.

You might think that 16-bit Unicode encoding would solve this problem. The reverse is true. Unicode does not follow the principle of one codepoint per glyph, but instead expects the rendering system to be able to do the necessary processing to render the text. This requires smart rendering systems.

Finally, changes to computer operating systems over the last few years have sometimes disabled these dumb font WSIs. Such WSIs heavily use tricks to work around operating system limitations, and when the OS changes, the open doors used by developers have been shut. The result is that a WSI may, at first, seem to work in a new version of an OS or an application, but have disabling problems, such as a range of letters that no longer display correctly, etc.

Copyright notice

(c) Copyright 2003 UNESCO and SIL International Inc.



Note: If you want to add a response to this article, you need to enable cookies in your browser, and then restart your browser.

Note: the opinions expressed in submitted contributions below do not necessarily reflect the opinions of our website.



© 2003-2017 SIL International, all rights reserved, unless otherwise noted elsewhere on this page.
Provided by SIL's Non-Roman Script Initiative. Contact us here.