Computers & Writing Systems
| SIL HOME | SIL SOFTWARE | SUPPORT | DONATE | PRIVACY POLICY |
You are here: General > WSI Guidelines
Short URL: https://scripts.sil.org/WSI_Guidelines_Sec_9_2
Guidelines for Writing System Support: Technical Details: Smart Rendering: Part 2
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: the opinions expressed in submitted contributions below do not necessarily reflect the opinions of our website.
© 2003-2024 SIL International, all rights reserved, unless otherwise noted elsewhere on this page.
Provided by SIL's Writing Systems Technology team (formerly known as NRSI). Read our Privacy Policy. Contact us here.