Adding Language and Script Support


Introduction

Throughout the world, different scripts lay out and align text in radically different ways. Reading direction can be right to left, left to right, or vertical. Some scripts depend on specific contextual forms for each glyph, while others rearrange glyphs depending on the context. QuickDraw GX makes it easy to combine multiple scripts in the same line--even in the same font. Many of the features of TrueEdit are designed expressly to support these effects.

Some features are not new ideas with GX, but GX greatly expands on previous font capabilities.

First, every font must have a character map, describing how to get from characters to glyphs; under GX, fonts can have multiple maps, each keyed to a different platform, script, or language.

Vertically written GX fonts can contain vertical metrics information, equivalent to the horizontal metrics information used for scripts such as Roman.

Embedded bitmaps can relieve the difficulty of creating instructions for very complex glyph designs.

New script features in GX include baselines, which govern the alignment of adjacent text in different scripts, and glyph properties, which Line Layout uses to resolve cases where two or more scripts run in different directions on a single line.

So that a font may be used anywhere in the world on a GX system, localized names can be provided in any script or language available on the Macintosh.

These script and language features combine with glyph and position effects to support virtually any writing system. Which features are relevant to a particular font depends on the script or scripts it represents. For vertical scripts such as Mongolian, vertical metrics are essential. Arabic fonts require both right-to-left glyph properties and glyph effects for ligatures and contextual forms. For Hindi, a font can use glyph effects to reorder certain sequences. And for the Taliq script, which is written on rising diagonals, cross-stream kerning is necessary. Roman fonts can also use these capabilities to create useful and original effects.

Non-Roman Script Support

Currently this area of TrueEdit is very weak. The following QuickDraw GX glyph effects are not supported in this version of TrueEdit:

TrueEdit also has difficulty with aspects of right-to-left scripts, such as Arabic and Hebrew. Some aspects of the tool are confusing or awkward to use with such fonts, while others do not operate properly in this version.

The first step if you're serious about using TrueEdit to do non-Roman effects is to find an engineer. This is not to say that these things are impossible, or that TrueEdit is not useful. You can make fonts that are outside of TrueEdit's strengths, but you should understand that this is a task for an engineer, working together with a font designer.

Tables covered in this chapter

Table Tag

Contents

bdat

Bitmap data

acnt

Accent attachment

bloc

Bitmap locations

cmap

Character map

name

Names

bsln

Baseline

vmtx

Vertical Metrics

vhea

Vertical header

hhea

Horizontal Header

head

Header

prop

Glyph Properties

Character maps

The new GX cmap's are different those of "ordinary" TrueType. The format has been redefined slightly. The editor lets you get at all the features of the new format, including a much wider variety of languages.

How cmap is used

User types a character and the font outputs a preliminary glyph, which gets fed into the mort machinery where all sorts of wierd and wonderful things happen to it.

The cmap table is responsible for translating character codes, as entered by the user, into glyph indices, as used by the mort machinery. Previously this table contained only one list of mappings - which translated the standard Macintosh character set codes into glyph indices for the particular font.

With the introduction of GX, multiple cmap tables can be included in a font to support different scripts (for example, a Hebrew font which also includes Roman glyphs) or language encodings (the various ISO 7- and 8-bit encoding schemes used for European languages). Under non-GX systems, only the first cmap will be available to the system software, and thus to the user. Thus it's a good idea to make the first cmap correspond the standard Macintosh Roman character set for Roman fonts, and in non-Roman fonts, to the most common enocoding system for that script. This will allow non-GX users to get some use from the font.

The choice of encoding for a particular font is dependent upon the conventions used by the intended platform. A font intended to run on multiple platforms with different encoding conventions requires multiple encoding tables; the cmap table may contain multiple subtables. The new cmap specification lets you define platform ID, specific (script) ID, and the new language ID for each cmap subtable.

Platform ID refers to the encoding system being used. Examples are "Macintosh", "OS/2", "Unicode".

The Platform-specific, or Script, ID refers to the type of script in use on the platform specified by Platform ID. Examples are "Roman", "Cyrillic", "Arabic", etc.

The Language ID is used to govern some language-specific features of a script system, such as glyph sorting and casing. Examples of Language IDs are: "Irish", "Finnish", "German", etc.

You should make sure there is a cmap available for the script you will be typing with.

Requirements

Each font must contain a cmap table. This table, in turn, must contain at least one subtable. Each subtable is specified by a set of encoding IDs -- platform ID, script ID, and language ID -- and contains a mapping of character codes (e.g. Macintosh or Unicode) to glyph indices (from the glyf table for the given font). Under QuickDraw GX, there may be as many subtables as the font designer desires. The cmap subtables are identified by a unique set of encoding IDs and must be sorted in ascending order of platform, script, and language IDs. The various cmap subtables may differ in one or more of the encoding IDs and may contain different character-to-glyph mappings.

Fonts should generally contain at least a Macintosh-Roman-English cmap subtable. Additional subtables can be included to provide support for multiple script systems and/or languages. At the discretion of the font designer, a font may contain a cmap subtable for every language available in QuickDraw GX. These cmap subtables will be used under the appropriate language systems.

Standard encodings

Apple's fonts now support an Extended Latin glyph set, which is also recommended to other font developers. Details are available from Apple Developer Services.

The minimum required glyph repertoire for Roman fonts has been upgraded from the Apple 226+32 glyphs that has been the standard for TrueType fonts in the past. Now there are more than 300 glyphs. This new standard applies to both GX and non-GX fonts, and provides additional glyphs for non-English language localization. This new standard is shown in appendix C.

The standard does not apply to ornament, dingbat or specialty glyph fonts. The character sets for the non-Roman languages can be found in the Guide to Macintosh Software Localization, chapter 13.

Nor does the standard apply to CJK fonts, which have their own minimum standards. There are a number of different national standards for CJK fonts. Consult the Unicode Standard, volume 2, for details on the requirements and glyph repertoires for the various CJK standards.

Unicode

Unicode is an extended character encoding system which has been designed to be able to represent every script system and language on Earth, both ancient and modern.

Like an ordinary cmap, a Unicode cmap converts character codes into glyph indices. However, because Unicode is a universal encoding system, one Unicode cmap can be used to access all available glyphs in the font - including all available script- and language-specific glyphs.

Quickdraw GX supports Unicode cmap tables.

It is possible, although a bit impractical, to make a font with a glyph for every defined Unicode code, and by attaching a Unicode-compatible cmap to it, produce a font that can be used for any language on Earth. And for Klingon too, if you're that way inclined...

Apple strongly recommends the use of Unicode cmaps.

Updating an existing font

As GX versions of shipping fonts are developed, guidelines are needed for what is acceptable to change in a new version of a font. So here are some rules for how to treat glyph changes:

Encoded Glyphs

If the glyph is pointed to by any cmap (including any that will ship before the revised font does), then the overriding goal is to not cause any existing document to reflow. You can even radically change the design (as long as it's still the same character!).

If the glyph's metrics don't change

If the glyph's metrics do change

Unencoded Glyphs

If the glyph to be changed is unencoded (e.g., the "1 2 3" superior-forms in the "extra 32" font), the goal is to make sure everyone uses the new version.

Note that in neither case can you get away with actually deleting the old glyph, because of backwards compatibility and doubts about tool and font source integrity. But you can make the old glyph inaccessible. If you find you're making a lot of glyphs inacssesible, it might be worth considering producing a completely new font.

Formats

The data in cmap subtables is stored in one of four formats: 0, 2, 4, or 6. Briefly, format 0 is for one continuous segment of 256 single-byte character codes, format 2 is a mixed single-byte and double-byte character code format designed specifically for Kanji fonts, format 4 is for multiple continuous segments of single- and/or double-byte character codes, and format 6 is for one continuous segment of single- and/or double-byte character codes which does not meet the stringent requirements of format 0.

Format 6 should be used when there is a single contiguous range of mapped characters; format 4 should be used if there are several ranges.

You can have 8-bit, mixed 8- and 16-bit, and pure 16-bit cmap's. Codes 0 through 32 in any cmap are reserved for special computer purposes and must be mapped to specific glyphs in the font. Character codes that do not correspond to any glyph in the font should be mapped to glyph index 0, the missing character glyph. There are various other requirements: characters that must be mapped to the null glyph (glyph ), characters that must be mapped to a glyph with a positive advance width, etc. - these rules are all covered in the TrueType Specifications.

Using the cmap editor

When the main window, listing all tables in the font, is active:

When the window listing cmap subtables is active:

TrueEdit ensures that cmap subtables are sorted by their encoding IDs and that no subtables share an identical set of encoding IDs. The latter is accomplished by requiring the user to change the encoding IDs of a pasted, duplicated, or edited subtable until a unique set of IDs is entered.

When a window displaying a format 0, 4, or 6 cmap subtable is active:

When a window displaying a format 2 cmap subtable is active:

You can double-click on an entry in the subtable to see the list of subheaders associated with the given subtable. With the subheader list active, you can choose Edit Entry from the Edit menu or double-click on an entry to edit the subheader values for the active subtable.

Special features of TrueEdit's cmap editor

TrueEdit automatically controls a cmap subtable's format. The format of a subtable may change if you add a new entry or edit/remove an existing entry. TrueEdit will display an alert indicating the need for a format change; which you can proceed with or cancel. The auto-formatting facility will always pick the best format for the data contained in the subtable. By adding and/or removing entries, however, you may change the format, if desired.

The "Build & Add" option available for adding a cmap subtable is useful because it allows you to add a complete subtable without having to specify any of the new subtable's entries. The entries in the new subtable are determined by the platform, script, and language IDs specified by the user. TrueEdit determines the format (0, 4, or 6) of the new subtable based on its contents. The new subtable is built by using a CHMP resource (from TrueEdit's resource file) in conjunction with an existing cmap subtable in the font. Details of this CHMP resource are in appendix C.

Vertical metrics

These are similar to horizontal metrics (see chapter 6).

Just as Roman scripts require horizontal metrics, so many Asian scripts require vertical metrics. Vertical metrics for vertical fonts are analogous to horizontal metrics for horizontal fonts. Each glyph must be placed in a horizontal position relative to a common centerline and a vertical placement relative to the previous glyph.

In order to provide vertical control over each glyph, two control points are included in the glyph's outline. One point is included at its vertical origin and one point is included at its vertical advance. This allows instructions to fine-tune each glyph's vertical device metrics.

Format details

Vertical metrics are provided for vertical fonts by including a vertical header table (vhea) and a vertical metrics table (vmtx) in the font. A font must have both a vhea and a vmtx table.

Vertical header

The vertical header table contains line spacing metrics analogous to the horizontal header table.

This table ('vhea') contains information needed for vertical fonts. The glyphs of vertical fonts are written either top to bottom or bottom to top. This table contains information that is general to the font as a whole. Information that pertains to specific glyphs is given in the vertical metrics table (see below).

Data in the vertical header table must be consistent with data in the vertical metrics table. The advance height and top side bearing values in the vertical metrics table must correspond with the maximum advance height and minimum bottom side bearing values in the vertical header table.

The vhea table also contains line gap (measured horizontally) and caret slope and offset.

Vertical metrics

The vertical metric table contains vertical side bearings and advances analogous to the horizontal metrics table.

The vmtx table allows you to specify the vertical spacing for each glyph in a full-featured vertical font. This table consists of either one or two arrays that contain metric information--the advance heights and top-side bearings--for the vertical layout of each of the glyphs in the font.

A font can save a lot of space if it is monospaced (vertical advance heights all equal), but the monospaced glyphs have to be together at the end of the font to produce this space saving.

Using the editor

If you try to ad a vmtx table without a font which has no vhea table, TrueEdit will report "No such table in SFNT" (referring to the vhea table) - to fix this, use "Add Table..." to add a vhea table to the font first.

To edit an existing vmtx table, or a newly-created one, either double-click its entry in the font's table list, or select its entry and select "Open Table..." from the File menu.

The vmtx List window is displayed:

This window lists each glyph in the font along with its Top Side Bearing (equivalent to left side bearing in horizontal fonts) and Vertical Advance Width (equivalent to horizontal advance in horizontal fonts).

To edit the values for a particular glyph, double-click its entry in this list window - TrueEdit will open a vertical metrics editor window for that glyph:

This is similar in operation to the horizontal metrics editor, except that everything has been turned on its side. You may visually set the glyph's side-bearing and advance width by dragging the two solid horizontal lines in the editor - the numeric values will be displayed in the window's information bar.

Alternatively, to set the values numerically, select "Edit Entry..." from the Edit menu, which produces the following dialog box:

You can use the "Prev" and "Next" buttons to step through each glyph in the font.

The "Mono..." button brings up the monospacing dialog:

From here you can specify a list of glyphs whose spacing will be set to a uniform value. There are two options available: "Compressed" format where all glyphs are set to monospaced from the selected glyph up to the end of the font, or "Mono Range" in which only a set range of glyphs are monospaced.

The "Compressed" form yields smaller metrics tables, but is currently unavailable in TrueEdit.

Bitmaps

TrueEdit has an integrated bitmap editor. Currently, this editor cannot create or import bitmaps, only edit those which already exist in the font's sfnt table.

GX supports both outline and bitmap descriptions of glyphs. Bitmaps are useful for very small sizes of glyphs that are difficult to produce using instructions.

Why use bitmaps?

The use of bitmaps is strongly discouraged for non-CJK fonts, and should be avoided in CJK fonts as well whenever possible. TrueType instructing is more than adequate to handle small sizes of non-CJK fonts.

However, when displaying complex glyphs, such as those of Chinese, Japanese or Korean fonts at small sizes, it becomes very difficult to keep the glyphs legible. Traditionally, typographers removed less significant strokes from the more complex glyphs when designing small-sized type. With scalable fonts, where all sizes are built from the same description, this was no longer possible, with the result that many CJK fonts degenerated to "black blobs" at small type sizes, or at low resolution. While instructing (hinting) such fonts would improve the situation, hinting ten to fifteen thousand complex glyphs down to 8pt would take literally years of effort.

To provide a quick way out, GX allows bitmaps to be used for certain sizes of a font instead of using the outline data. The designer can manually edit these bitmaps, removing and altering strokes as they see fit, to produce a legible set of glyphs in a fraction of the time it would take to hint the outlines.

To ensure that such bitmaps have the same metrics as the outline versions would have had, an Apple tool called Fissioner can be used to build bitmaps from outline fonts at a specified point size. This prevents the situation where a 20pt bitmap is actually smaller than the scaled 18pt outline for the same font.

Technical details

To create a bitmap font, you need to include a bitmap location table (bloc) and a bitmap data table (bdat).

The bloc table provides information about the availability of bitmaps at requested point sizes in the font. If a bitmap is included in the font, it also tells where the data is located in the bitmap data table. The bdat table is a collection of bitmaps for all of the bitmapped glyphs in the font.

The actual bitmap data, in bdat, can include pixel measurements of height, width, side bearings, advance, and (best of all) components and attachment info. Format 1 lets you do all that. Format 2, 4, and 6 don't support components; format 2 is for horizontal only, 4 for vertical only, and 6 for both.

The Apple tool Fissioner can be used to generate a set of bitmaps from an existing outline font, which can be embedded into an sfnt using the Apple tool Fuser.

The editor

The bdat editor allows bitmap information to be edited. When a bdat table is opened, the bdat editor is displayed:

The editor consists of fields for setting the metrics of the glyph and a rudimentary "paint package" with which the glyph bitmaps can be edited.

To select a glyph for editing, use the scroll bar underneath the bitmap display, or click the "Find..." button to bring up a numeric selector. The large glyph bitmap in the centre of the editor window can then be edited using the drawing tools at the right of the display.

At the left of the large glyph display, the metrics associated with the selected glyph are displayed. To change these values, click in the box and type in a new metric value.

Also, the version for this bitmap set is displayed above the large glyph bitmap, although a TrueEdit bug prevents this from being altered.

The Outline box should show the outline-generated equivalent for the bitmap being edited, but doesn't because of a TrueEdit bug.

The remaining options, on the right hand side of the editor, are only partially enabled. The working options are:

General info

The bloc table ("Bitmap LOCation") contains information about the location of bitmap images within the font, and also some general information about the font. When this table is opened, TrueEdit presents the following dialog:

This dialog shows the following information:

The "Bigger" and "Smaller" buttons are used to select the next bigger or next smaller strike (bitmap set) size for editing.

You can have a sparse set of bitmaps, containing images for just a few glyphs (such as those which are really hard to hint!), but TrueEdit does not currently support this feature of GX fonts.

Glyph image metrics

Currently the bitmaps use whatever metrics are embedded within the sbit. The tools creating the embedded bitmap data should in the future be able to get the metric information from the sfnt. This guarantees that the data will be the same, and will improve performance.

It is suggested that the fractional (unhinted) metrics be obtained from the hhea or vhea table and the device (hinted) metrics be obtained from the embedded bitmap data. Therefore, any tools that create embedded bitmap data should store the device metrics.

Accents

The accent attachment table (acnt) provides a space-efficient method of combining component glyphs into compound glyphs to form accents. Accented glyphs are a very restricted subclass of compound glyphs.

TrueEdit doesn't directly support the accent attachment table.

Accented glyphs share all properties (metrics, kerning, properties) with the primary base glyph. Each accented glyph must have a unique glyph index; they must be contiguous at the end of the font (after all regular glyphs). Accents are positioned by means of attachment points. No transformations (scaling or distortion) of primary or secondary components are allowed.

As a tradeoff (and it can be a significant one), this format is very compressed. If your font has a lot of accented glyphs, this method may be worth looking into. Because of such things as the standard glyph ordering for roman fonts, it is difficult to retrofit an acnt table.

The Apple tool GXifier can add all the Extended Latin accented glyphs to a font.

Baselines

In GX fonts, a baseline of a font is a line that defines the position of a glyph in a font relative to other glyphs in the font, or how they align to one another. In Roman-script fonts, glyphs generally sit on a baseline whose y-coordinate value in the em square equals zero, y=0. However, Line Layout supports scripts which descend from the baseline, such as Devanagari, and scripts which are centered on a baseline, such as Kanji. Roman script fonts can now align properly when set with text whose baseline is predominately non-Roman.

Baselines are also very useful for implementing drop capitals.

Baseline classes

To provide full-featured baseline controls in your font, you must include a baseline table, and define any of seven baselines (four of which are relevant to a Roman script font).

Roman
Defines the alignment used in most roman script languages, where most of the glyph is above the baseline, with portions (such as descenders) possibly below it. The baseline appears near the bottom of the entire line.

 

Ideographic centered
This defines the behavior used by Chinese, Japanese, and Korean ideographic scripts, which center themselves halfway through the line height.
 

Ideographic low

This also defines behavior used in CJK, but with the glyphs lowered slightly so that ideographs that appear adjacent to Roman glyphs appear to descend slightly below the Roman baseline.
 

Hanging

The alignment used in Devanagari and derived scripts, where most of the weight of the glyphs is below the baseline, with some portions possibly above it, and where the "baseline" itself appears near the top of the line. This value is also used for drop capitals.
 

Math

This defines the alignment used for setting mathematics, where operators like the minus sign need to be centered.
 

Vertical x 2

These are used only for vertically-set text.

Table details

Only one value can be assigned to each baseline, and that value is shared by all glyphs in the font. You cannot create more than one of each type of baseline.

GX lets you give different glyphs in the font different dominant baselines, but TrueEdit doesn't support those formats. As a result, every glyph in the font must have the same dominant baseline.

The natural baseline is at y = 0 in font coordinates. In the absence of any other information, different sizes of this glyph render with this line in common--that is, the pen will always rest on this line. Note, however, that the natural, y=0 baseline is not necessarily the same as the default baseline. The default baseline is whatever you say it is in the bsln table.

Also need information on how to make the default baseline one other than the Roman (change the third byte of the table...)

How to Add Baselines to a Font

In TrueEdit's main window, create a new table.

Scroll down to the entry baseline and select it.

Click OK.

A dialog box, labeled Add Baseline Table, will then open, and require you to choose one of two formats:

Choose the Distance Format. The Distance Format will describe the baseline as the distance from the natural Roman baseline, as measured in Font Units. This format allows different glyphs to have different dominant baselines.

The Control Point Format requires that representative control points (whose purpose is specifying baselines) be added to one glyph. The control point-based format requires that this glyph then be selected as the "standard glyph" whose set of control points are used to define the baselines for all glyphs in the font, after TrueType instructing. Most instruction tools require that these control points be added prior to instructing the font.

The tag abbreviation for the baseline table is bsln: this will now be added to the list of tables in TrueEdit's main window.

Double-click on the tag 'bsln' in the main table window to open the Baseline Table editing window. The window will open up displaying a glyph in the font.

You can then use the scroll bar to scroll to any glyph in the font.

Once you have chosen a glyph, you can edit the its baseline entry in the Baseline Table window. To do this, double-click on the glyph. This calls up the Baseline Table Window.

In this window, you create a baseline or a control point that will define the line in the y-direction (the x-direction for vertical baselines). The window also provides relevant benchmarks: the ascent, descent and units-per-em values already defined for the font.

When resized, the window adjusts for size and aspect ratio, but because of a TrueEdit bug, the glyph size within the window adjusts incorrectly: If the window is low but very wide, the glyph is too small to fit vertically; if the window is narrow but very tall, the glyph becomes too large to fit within the display.

Negative values for the baseline are not handled properly. When a negative value is input, confirmed, and reopened to be checked, the number turns into a very large positive number in the 64k range. This is a TrueEdit bug. Range-checking is also not done which could cause problems if an unrealistically large number is accidentally input.

To choose the baseline and assign a value in x- or y-direction:

Baselines for roman fonts

The four baselines which pertain to a Roman script font are: Roman, Hanging, Math, Ideographic Centered, and (to accommodate inter-script alignment) Ideographic Low.

These values are suggested only as starting points for defining baselines for a Roman font, and are by no means binding:

Roman:
The y-coordinate value of zero
 

Ideographic Centered:

Half the x-height
Ideographic Low:
Equal to the Roman baseline value, or zero

There is currently no method for displaying the glyph-in-process between reference glyphs to verify ideographic baseline positions

 

Hanging:

The cap height of the upper case H
 

Math:

Vertical center of the plus sign

Roman fonts usually sit slightly below Arabic/Farsi when they're printed together, so there should be an "Arabic" baseline defined to make that alignment possible automatically. However, this is not currently implemented.

Character properties

There are essentially three different kinds of properties in the prop table: directionality; hangingness; and reordering pairs. A full description of properties and directionality can be found in The Unicode Standard: Worldwide Character Encoding.

Directionality classes

For Arabic and Farsi fonts, use the properties setting "Arabic letters", which Unicode has created especially for Arabic.

For other right-to-left scripts, use the setting "Strong right to left".

Hanging punctuation

The properties table is also responsible for defining which glyphs are allowed to overhang line-ends, a property used to implement "hanging punctuation". The subject of hanging punctuation is covered in Chapter 4.

Reordering pairs

The checkbox in the prop editor which specifies reordering pairs brings up a dialog whenever it's checked or unchecked:

The "Pair with glyph" field should be filled with the glyph used for the other end of the reordering pair (the close-bracket glyph for an open-bracket; and the open-bracket glyph for a close-bracket). There is a limit on how far apart the two glyphs can be in the font: any re-ordering (or "bracketing") glyph must be within 8 glyphs of its partner in the font's glyph table.

The "Pair when right to left" checkbox needs some explanation:

Using the editor

The font's 'prop' (Glyph Properties) table is edited using the editor below:

The top of the window shows the glyph's index. Below this, a set of checkboxes are used to set certain characteristics of the glyph: whether or not it floats over a line (ie., occupies no space on the line), its hanging characteristics (used for Hanging Punctuation), and whether the glyph is part of a reordering pair.

Below these checkboxes is a popup menu from which the glyph's directionality class can be set. These classes are described later.

Setting default properties

If you choose "Edit Entry", while the "Glyph properties" window is open, you will get a slightly different set of functions:

[Sticky!]

Use the "Apply standard Macintosh character set properties" button to apply the standard glyph properties to the font.

Note also that this only changes glyphs which were previously at the "default" property. there's no way to apply the same non-default properties to a set of glyphs.

The standard Unicode properties are only defined for Roman fonts in TrueEdit.

Directionality classes

The following is an incomplete list of the directionality classes found in a typical Roman font.

Alternate, superior, and other versions go in the same directionality class as the normal versions.

Strong Left-to-Rights

As a rule-of-thumb: If it's alphabetic, it goes here.

Unicode puts all non-spacing accents here, but only some of the spacing accents. All accents in Apple's Roman fonts are spacing accents; and they go here.

Incidentally, the ASCII circumflex and tilde (^ and ~) are classed as "Other Neutral", not accents.

Strong Right-to-Lefts

(none)

Arabic Letters

(none)

European Numbers

European Number Separators

European Number Terminators

This class includes only glyphs which would appear immediately next to a number. All currency signs go here. Hyphen and minus both go here, but multiplication and division don't.

Arabic Numbers

(none)

Common Number Separators

Block Separators

CR (glyph 2)

Segment Separators

(none)

Whitespace

space, option-space

Other Neutrals

Reordering pairs

Floaters

These are glyphs which "float" over other glyphs and thus do not have any directionality. Some accents go in this category, others are placed in "Strong Left-to-Right".

Hangers

These are glyphs which can hang over the ends of lines. In Roman typography, this class includes quotation marks and other small punctuation.

Hanging punctuation is covered in Chapter IV.

Localisation

GX fonts support far more features and effects than normal TrueType fonts. Because of this, the responsibility for putting names on these features has been moved from the application using the font to the font itself. As its name implies, the name table holds the name of the font, and also the names of all the font's features and effects.

The name table can contain many sets of name entries, each keyed to a specific Script and/or Language. Thus, the same font will identify its effects in French if used on a French-language system, in English if used on an English-language system, or even in Chinese if used on a Chinese-language system!

The name table is the vehicle by which you convey information about your font to applications and users. You should assume that your font may be used in virtually every part of the globe. As a result, your font should be localized for other languages and cultural environents. With TrueType GX, you can construct fonts from the outset with localization in mind, allowing you to easily adapt your font for any group of users in the world. For more information, see Guide to Macintosh Software Localization from Addison-Wesley.

If a font can be used to write a particular language, then it is worth considering localising the font to that language: an Arabic font whose feature names are all in English isn't a lot of use to someone who only understands Arabic.

To localise a font to a specific language, the names of the font's features need only be translated to that language, and the resulting set of names added to the font's name table with the appropriate Script and Language identifier.

The name table

In general, for non-GX fonts, Apple ships four styles of a font: regular, bold, italic and bold italic. If the fond is built correctly, these styles (the font subfamily name) will be added to the font family name appropriately, in parenthesis, after the font name, when looked at in the System or Fonts folder (e.g. "Times (bold, italic)"). Placing the font style into the font name manually will cause duplicate naming and/or confusion to the system and the user, as applications referring to these names will not be able to determine font family relationships.

For non-GX fonts, the family name is obtained from the fond, and the style is obtained from the style bit in the fond. Because of this, the styles for non-GX fonts are limited to the traditional four (regular, bold, bold italic, italic). If more styles exist, they must be placed into separate suitcases (such as Helvetica Black, which the system thinks of as a regular font, with a separate identity from the Helvetica family).

For GX fonts, the style naming conventions are different, because more style options are available, and the style choices are more flexible. The font name and style information are both obtained from the name table, from the family and sub-family name strings respectively. The sub-family name can be anything desired (italic, bold, black, ornaments, zany, etc.) However, to be backwards compatible with non-GX systems, all GX fonts should have the appropriate name and style bit set in the fond, so that the correct name and style (or best approximation of style) will display.

Family names for GX fonts should not differ from non-GX fonts. The use of any appendage to the font name, such as "GX" (e.g. "Helvetica GX") is strongly discouraged.

GX fonts must contain the following eight standard name strings in their name table, for as many languages as are desired. Including a "Macintosh/Roman/English" name set (the default name set for Roman fonts) is optional, but recommended:

Index

Name

Description

0

Copyright

Copyright information about the font. This should normally be visible only from a "Get Font Info..." command.

1

Family Name

The name of the font family to which this face belongs (examples are: "Helvetica", "Avant Garde", "Baghdad", "Apple Chancery")

This name normally appears in the "Font" menu.

2

Subfamily

The particular variant of the font in "Family Name" that this font is. Examples are: "Italic", "Regular", "Condensed", "Extra Black", "Demi", "Book".

This string is normally listed under the "Style" menu, or on a submenu of the font's Family entry on the "Font" menu.

3

Unique

A unique name for this font, often including a manufacuturer and/or version number. Examples are : "Apple Computer Apple Chancery", "Adobe Systems Inc. Tekton Plus Regular"

4

FullName

Full name of the font. Often just a concatenation of "Family Name" and "Subfamily". Examples are: "Apple Chancery", "Avant Garde Book", etc.

5

Version

A version identification for the font. Examples are: "1.0", "2.1", etc. These are text strings, not numeric values!

6

Postscript

A version of the font name which is used to identify it to PostScript devices. Often this is just an abbreviated version of FullName with spaces removed.

7

Trademark

This string is used to assert trademark ownership. Examples are: "Tekton is a trademark of Adobe Systems Incorporated", "Avant Garde is a registered trademark of International Typeface Corporation".

This string, like "Copyright", could be visible from a "Get Font Info..." command.


Names for glyph effects, position effects, etc. are assigned dynamically by TrueEdit, beginning at index 256. Thus, indices within the name table will not match from one font to another.

When you delete name strings, the surrounding strings are not renumbered.

There's no protection against deleting a name required by another table (e.g., feat or trak). And there's no good way to reconstruct it.

You can add an entry having an arbitrary index. It's not clear what good this might do you, but there it is.

If a string for a particular language is not found, the Macintosh Roman English version is used instead. This behaviour means that you don't need a Family Name entry for every European language: "Avant Garde" is still "Avant Garde", even in Finnish. Other standard strings, such as Subfamily, and the Trademark and Copyright strings, should be translated, however.

The name editor

When you double-click on the name table of a font, TrueEdit displays the name table information in a window as shown below:

When you select "Add Entry..." under the Edit menu, or when you double-click an entry in the name table, TrueEdit presents the name editor dialog, as shown below:

To add or edit the name entry, type the new text into the "Name String:" box, and select OK. TrueEdit automatically strips leading and trailing spaces from name strings entered in this dialog.

In TrueEdit, the name table is displayed using the default application font for the native script system. Thus, Kanji name strings will be displayed correctly on a Kanji system.

[Sticky!]

Each name record includes a platform ID, specific (or Script) ID, language ID, name ID, and the (localized) name string itself. Lists of the possible values are available in several books; with TrueEdit, all you need to know is that the add entry dialog has popups showing all the possibilities.

Apple will provide detailed information describing the different name strings, and copyright/trademark information, that are required for the name table.

Tips for specific scripts

The following is a list of the particular quirks and limitations of TrueEdit when dealing with specific script systems.

General

The following QuickDraw GX features are not supported by TrueEdit 1.0:

TrueEdit also has difficulty with some aspects of right-to-left fonts, such as Arabic and Hebrew. Some aspects of the tool are confusing or awkward to use with such fonts, while others do not operate properly.

This is not to say that these things are impossible, or that TrueEdit is not very useful. You can certainly make fonts that are outside of TrueEdit's strengths, but you should at least understand that this is a task for an engineer, working together with a font designer.

Arabic & Farsi

Hints

Problems

Note that the cursive editor does not allow for non-connecting medial forms.

Hebrew

Hints

Problems

CJK Scripts

[Sticky!]



Arleigh Movitz (movitz@apple.com)
Dave Opstad (opstad@apple.com)
Kristian Walsh (walsh.k@euro.apple.com)