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.
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.
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 |
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.
cmap
is usedUser 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.
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.
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 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.
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:
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
cmap
point to the new glyph.
If the glyph's metrics do change
cmap
pointing to the old glyph.
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.
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.
cmap
editorWhen the main window, listing all tables in the font, is active:
cmap
table to
the font
cmap
is selected,
this opens a window showing the cmap
subtables;
double-clicking the cmap will also work
cmap
table (between fonts, if desired)
cmap
table from the font; the delete key also works
When the window listing cmap
subtables is
active:
cmap
subtable
cmap
subtable (between
fonts, if desired)
cmap
subtable
without affecting Clipboard contents; useful for adding cmap
subtables which differ only in language and a few entries
cmap
subtable; the delete
key will also do this
cmap
subtable's encoding IDs
cmap
subtable. The "Add Entry" dialog box presents you with two
possible options:
cmap
subtable can be built from a CHMP
resource
cmap table
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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:
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.
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.
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.
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.
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).
Ideographic low
Hanging
Math
Vertical x 2
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...)
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:
If you set any baseline's
value to zero, it will not appear on the editor window. To change
it, double-click the editor window, and choose the baseline to
change from the dialog box.
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.
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.
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".
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.
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:
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.
If you choose "Edit Entry", while the "Glyph properties" window is open, you will get a slightly different set of functions:
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.
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.
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.
(none)
(none)
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.
(none)
CR (glyph 2)
(none)
space, option-space
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".
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.
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.
name
tableIn 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
ortrak
). 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.
name
editorWhen 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.
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.
The following is a list of the particular quirks and limitations of TrueEdit when dealing with specific script systems.
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.
head
table, make sure the 512 bit is set
in the "Flags" field.
prop
table, set right-to-left properties
for each of the alphabetic glyphs in the font (using the pop-up
menu at the top of the window).
mort
table, build all the features keeping
in mind that when TrueEdit says "left" and "right" it generally
means "first" and "second" in order, in the direction of the
script. Thus in ligature features, put the rightmost glyph in the
first column, the next in the next column, and the leftmost glyph
in the third column.
cmap
available for the
script you will be typing with.
Note that the cursive editor does not allow for non-connecting medial forms.