This is an archive of the original site, preserved as a historical reference. Some of the content is outdated. Please consult our other sites for more current information:, ScriptSource, FDBP, and silfontdev


Contact Us


Initiative B@bel

WSI Guidelines


















Type Design


Design Tools



Font Downloads










Font FAQ



Computers & Writing Systems


You are here: General
Short URL:

NRSI Update #2 – September 1996

NRSI staff, 1996-09-01

Welcome to the second issue of the NRSI News Update!

In this issue:

TrueType Open - Update #3

by Bob Hallissy

In the previous TTO Update (#2), we indicated that the NRSI research into TTO is proceeding along 3 lines: Middle East Win95 subset, dialog with Microsoft on the “TTO APIs”, and our own TTO font compiler. Here are updates for each area, followed by a brief analysis of our understanding of (and concern about) Microsoft’s direction for TTO.

Middle East Windows 95 (MEW95) subset

MEW95 is due to be shipped in September. According to Microsoft, they have had their last beta cycle on this product, so we should see the real thing soon.

Based on experiments with beta releases, it appears that much of the Arabic script behavior is implemented as part of the MEW95 operating system rather than being imbedded into the TTO tables in the fonts. For example, the fact that certain letters have no initial or medial forms (and thus do not “join” with letters on their left) appears to be part of Win95. If Win95 simply looked at the TTO tables to determine this, then it would be feasible to change the behavior of such letters.

We often get requests from people who need a font “just like standard Arabic except these few differences.” It was my hope that MEW95 would have depended on TTO sufficiently that these kinds of requests would be easy to meet by simply modifying the TTO tables in the font. Instead, it looks like we are in the same games as Windows 3.1: If the extra letters you need behave just like some in the font that you don’t need, then we can replace the glyphs. We cannot change the behavior.

Please note that the above is based on yet-incomplete research using beta releases of MEW95. More research is needed on the final release in order to confirm these conclusions.

TrueType Open Services Library (formerly TTO API)

We have had a chance to review a draft specification of a new set of APIs being developed by Microsoft to enable application developers to take advantage of TrueType Open technology. The APIs, known collectively as the TTO Services Library, make it much easier for an application to read and process the TTO tables in a font. The APIs take care of the nitty gritty detail of decoding the tables and actually doing the glyph substitutions or repositioning or whatever that the tables call for.

While the API will make it easier for application developers to utilize TTO features, we continue to have concerns about the way Microsoft expects TTO technology to be used. See the note below about TTO Philosophy.

TrueType Open Font Compiler

Design work is still progressing on a Windows program to make creating and modifying TTO fonts easier than is possible with the current TTO Assembler from Microsoft. The TTO tables themselves, because of their hierarchical nature, lend themselves to an “Explorer-style” view, so this is the direction we are proceeding.

A note about TrueType Open philosophy

The following is an excerpt from Microsoft’s TrueType Open Specification, v1.0:

“As much as possible, the tables of TrueType Open define only the information that is specific to the font layout. The tables do not try to encode information that remains constant within the conventions of a particular language or the typography of a particular script. Such information that would be replicated across all fonts in a given language belongs in the text-processing application for that language, not in the fonts.”

This seems to imply that each application developer is responsible for learning and implementing the writing system behaviors of the languages that the app is supposed to handle.

Microsoft seems to be following their stated philosophy when, for example, they imbed the behavior of each Arabic letter in MEW95 instead of in the font (see above note on Middle East Windows 95). This sets the precedent that Arabic TTO fonts do not encode their complete writing system behavior. In this situation, adapting the system to a language that is similar to, but different than, Arabic becomes impossible.

Apple took exactly the opposite approach with its GX system, wherein the intent was to implement the writing system behaviors in the font so the application writers didn’t have to.

It was hoped that the TTO Services Library would signal a new direction, one more favorable to minority writing systems, but so far this does not seem to be the case. We are still attempting to make our case with Microsoft, and so the battle isn’t over yet.

TeXgX 1.1 Released!

by Dennis Drescher

The TeX typesetting system has been around for well over ten years now. During that time there have been many different implementations. Recently, TeX programs have become a little easier to use. Textures is a good example. However, TeXgX 1.1 on the Macintosh is probably one of the most universal of all implementations.

I have watched the development of this TeX program for a while now. Jonathan Kew has been careful to maintain the TeX standard. TeXgX is an interesting combination of TeX and the Apple GX font technology, that supports GX “smart” fonts as well as standard TrueType and PostScript fonts. This combination allows the user to typeset long documents in any script or even multiple scripts. In addition to this, TeXgX 1.1 is now compatible with standard TeX fonts such as Computer Modern. It has the ability to read TeX Font Metrics files and give identical results to documents typeset in other TeX implementations. TrueType versions of standard TeX fonts are freely available alongside the release.

Other improvements include a more robust Find command, better handling of right- to-left scripts and better performance in the edit windows. All this combines for the best TeXgX yet. Well done, Jonathan.

If you would like to know more about TeX, a good place to start would be the  TeX Users Group home page.


TeXgX is shareware - $40 U.S.

The release contains these files:

  • TeXGX11b2_sea.hqx [1.3Mb]
  • PlainTeXfonts_TrueType_sea.hqx [380K]
  • MoreCMfonts_TrueType_sea.hqx [1.4Mb]
  • AMSfonts_TrueType_sea.hqx [746K]

(1) To obtain them from the Web, go to this URL


(2) To obtain them using a command-line FTP client:

FTP to and log in as anonymous.

Do these commands:

get texgx11b2_sea.hqx
get PlainTeXfonts_TrueType_sea.hqx
get MoreCMfonts_TrueType_sea.hqx
get AMSfonts_TrueType_sea.hqx

(3) To get them by e-mail, send a message to containing these commands:


(4) TeXgX and the fonts are also available on diskette - contact:

User Support
SIL International Publishing Services
7500 W. Camp Wisdom Road, Dallas, TX 75236-5699, U.S.A.

Apple WorldScript and GX Compared

by Victor Gaultney

The last NRSI Update described Apple’s WorldScript technology and its potential use within SIL. A common question is how WorldScript (WS) and QuickDraw GX relate to one another. The table below summarizes some of the similarities and differences between the two technologies.

Distribution Extension to MacOS, part of current system software Extension to MacOS, part of current system software
Requirements System 7.1 or 7.5.x, 4 MB RAM, Application needs to be WorldScript-savvy (some limited features available in non-WS apps) System 7.1 or 7.5.x, 8 MB RAM, Application needs to support GX Typography
Rendering Capabilities Subset of GX capabilities, can meet 95% of non-Roman needs, including R-to-L scripts, large glyph sets, contextual forms and ligatures Provides full, flexible rendering that can meet all non-roman needs
Rendering Speed Slightly slower than non-WS rendering, but still quite fast Significantly slower than non-GX, benefits greatly from PowerPC speed
# of Glyphs Per Font Theoretically 1024, but practically limited to 768 (single-byte scripts, also supports double-byte) 65,000
Non-Rendering Capabilities Simple and complex sorting, word breaking, tokenizing, and other cultural preferences (date/time/numbers) Not addressed by GX, but provided by other parts of the OS
Unicode Support Coming in next release Ready now, but MacOS is not
User Control Behavior preset in script module, cannot normally be changed (although fonts can have custom behaviors) Font can provide multiple user options to support differing behaviors (such as alternate forms for glyphs, whether certain ligatures are active, etc.)
Development Tools ScriptWright (SIL) TypeWright (SIL) ResEdit (Apple) TypeWright (SIL) TrueEdit (Apple)
Ideal Use Word processing [WP] Database [DB] Ling. Analysis [LA] most scripts Publishing [PB] Graphics [GR] highly complex scripts
Current Application Support Nisus (partial) [WP] WorldWrite [WP] WinText [WP] HyperCard [DB, LA] 4th Dimension [DB] AllPage [PB] TextUtils [LA] Conc [LA] (many localized versions of WP, DB, GR & PB apps) TeXgX [PB] UniQorn [PB] Ready, Set, Go GX [PB] LightningDraw [GR]
Future App Support Shoebox/Mac (good chance) LinguaLinks (?) various WP apps (?)

The basic rule of thumb concerning WS and GX interaction is that they can coexist happily, and when both provide special rendering instructions, GX always has precedence. The result is that it is possible to have, for example, a customized Arabic WorldScript module that works for all Arabic fonts on the system, but also have a specialized Arabic GX font that provides different rendering behavior and would override the default WS behavior.

Circulation & Distribution Information

The purpose of this periodic e-mailing is to keep you in the picture about current NRSI research, development and application activities.

© 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.