TECHNOTE

Gaiji Table

By Jeff Li

Chinese Developer Technical Support

CONTENTS

Introduction

Implementation of Gaiji Table

Other Links: Gaiji Linkage in Input Method

Introduction

Apple Asia R&D has developer a gaiji editor,with plans for more features,etc. In the future. Their original model for a gaiji solution in the Mac OS was to use such an editor to compose new glyphs from existing glyphs in a "base" font and add those glyphs to the base font at unused/safe character code points.

The editor solution is TrueType based (one version of the editor included a bitmap editor).

The problem with this scheme was that it wasn't possible to identify a font that contained gaiji from the original font. You could change the file name of the font, but the font name (and names in the name table) would remain the same as those of the original font. You could change all of the base font's names, but now documents written using the font would fail. The base font could be duplicated, but then you'd eat up disk space quickly. Plus if we added some gaiji to my copy of Font, and you added some to your copy, collaboration on a document would become humorous.

We discussed these problems some home ago,and decided that adding glyphs to an existing font would be technically hard anyway,beside the problems above. Instead,the editor should create a new font, with a unique name identifying it as "my gaiji Font", for example. Glyphs in the font would still composed from Glyphs in a selected base font with the idea that the gaiji font would be used in conjunction with the base font. The user could then use and distribute "his" font. The Kids mechanism was to be used, long term,to form a convenient link between the gaiji font and its original base font,so that the user could select the gaiji font and non-gaiji characters would be routed to the original base font. Multiple people's gaiji fonts, all based perhaps on the same base font,could thus coexist in a document.

Because the Kids table was not yet defined, and since it is not yet deployed,it would be necessary to somehow remember what base font was used to create the gaiji font. Also, it was desirable to remember enough information to permit the gaiji editor to continue to work on a gaiji font(i.e. add more gaijis later). Plus knowing that a font is a gaiji font was going to be important.

The 'gaij' table solves these problems. Its mere presence in the font indicates that the font is a gaiji font. It contains information about the editor that created it. It contains a link back to the original base font for use initially by the editor,and later by a program that wants to retrofit the correct Kids table for the font. The table also enumerates explicitly the base font(s) used, the gaiji character code points used with the corresponding gaiji font glyph ID and base font characters used.

The one hole in the design was the mechanism for referring to the base font. We had been assuming that the gaiji font would store the base font's unique name in its 'name' table, and would then refer to that name from within the gaiji table. We have learned that the unique name is not always unique enough, and so we've been looking at designing a more reliable mechanism (we call it the 'link' table).

For now, we can go ahead with the unique name scheme for System 7.x. Within the gaiji table data structures, there is a field called basFontLinkIndex. We could define this to be the "meaning" or "name type " to use when looking through the name table for the name string. If we introduce the 'link' table in our later MacOS release, this index would be the index into that table. The gaiji table's version number could be bumped at that point, or we could use negative numbers (or something just as nasty) to identify the name-table meaning in the meantime.


Implementation

Gaiji table is a newly designed sfnt table. The purpose of adding gaiji table into sfnt resource are:

  • Identify gaiji fonts from normal TrueType fonts.
  • Link the gaiji font with its base font.
  • Store glyph composing information of the gaiji characters.

For the details of gaiji table. Please refer to the related documentation.

To identify a Gaiji font,GaijiEditor will read sfnt data and search for gaiji table. If a 'gaij' table presents, the font will be recognized as a gaiji font.

When a gaiji font window is open,GaijiEditor will display the base font name of the gaiji font on the window. Unfortunately,the mechanism of linking a gaiji font to a base font through the gaiji table is not completely defined, we have to use an alternative way to implement it. When a gaiji font is created,we save two extra name strings in the 'name' table of the gaiji font. These two strings are the unique name and common name of the base font. On the gaiji font window,the common name of the base font will be displayed. The name identifiers for these two strings are

  1. const Uint16 NameID_BaseFontUnique = 1020
  2. const Unit16 NameID_BaseFontName = 1021

The reason to store two strings instead of the unique name only is that currently we don't have a standard and fast way to get a font name from its unique name, and there is even no guarantee that the unique name of a font is really unique.

The main part of the gaiji table is the glyph composing information. When a glyph is created, along with the glyph data stored in 'glyf' table, the glyph composing data is also stored into 'gaij' table. The composing data is consisted of a series of code points to tell the gaiji glyph is composed by these base font glyph.

The gaiji table design assume one gaiji glyph must be composed by only one base font. It seems not to be suitable to our GaijiEditor. To create a glyph, GaijiEditor allow users to import contour data from any fonts. Once the data are imported, they are treated as contours, users can conduct editing works on any individual contours.And an individual contour can be combined with other by using break and rejoin function of GaijiEditor. After such editing actions, sometimes it is hardly to say a new glyph is composed by any existing glyphs. This situation makes difficulty for us to manipulate the gaiji table data. Thus we decide to apply a simplified way to handle this issue. That is,

Whenever the user imports a glyph on a Character Editor window, we add the code point of it into the composing data of the window.

Unless the user choose 'Select All' and contours on a Character Editor window,we don't change the composing data for the window. That means if the user imported two glyphs into the window at first, then he/she deleted one of two glyph data by selecting individual contours, the code point of the deleted glyph is still in the composing data of the window.

When the user does cut and paste from one Character Editor window to another, the composing data on the destination window will not be changed.

Other editing actions on the Character Editor window will not affect the composing data.

Note that unless users themselves insist to use a single base font as data source,they can not get the correct composing data since only code points are stored. There is no place in the composing data or gaiji table to store multiple base font information for a single glyph.